Platform installation, configuration, and upgrade
Installation questions test the cpd-cli workflow and the order of operations, not memorized YAML.
The managed install sequence
cpd-cli manage wraps oc and helm and drives CASE bundles. Typical order: configure the client (profiles, user), case-download for the release and component list, then apply-olm (catalog sources and subscriptions in the operator namespace), create-operator, and create-cr - the last three are also bundled in setup-instance. Every component needs --license_acceptance, and naming the wrong --cpd_instance_ns at any step is a common cause of a half-built instance. Check state with get-cr-status rather than inferring it from pod counts.
Configuration after install
Configuration is CR-driven: storage classes, node affinity and tolerations, scale settings, and service-specific parameters (Db2U block storage, for example) live in the CR. Post-install tasks include wiring the identity provider, adding users and groups, and creating platform connections to external systems. Changes are applied by patching the CR and letting the operator reconcile.
Upgrade
4.7 upgrades are in place and operator-driven: download the 4.7 CASE, refresh the operator and catalog, apply the CR with the upgrade flag, then upgrade services individually. Control plane first, services after. IBM publishes supported starting versions; do not assume any 4.x can jump straight to 4.7.
Worked example
A customer on 4.6.x moves to 4.7. Take a backup, download the 4.7 CASE, update the operator, apply the CR with the new release and upgrade flag, and wait until get-cr-status reports completion. Then upgrade Watson Studio and WKC one at a time, re-checking status after each. If a service CR fails, the rollback point is the backup, not the old CR.
Traps
Skipping case-download leaves stale component metadata; architecture-mismatched images fail at pull; upgrading services before the control plane produces version-skew errors.