IBM Cloud Pak for Data v4.7 Architect common mistakes
IBM Cloud Pak for Data v4.7 Architect · Understand the traps and how to avoid them.
Treating Cloud Pak for Data as a single monolithic install and describing one 'install the platform' step, instead of separating the IBM Cloud Pak for Data platform (operators, zen, control plane) from the services (Watson Studio, Watson Knowledge Catalog, DataStage, Db2 Warehouse) that are installed as separate operators and custom resources after the platform is up.
Candidates who have only used the SaaS or a pre-built cluster assume a single installer, and the exam's scenario questions about install order, prerequisites, and 'what must exist before service X' then get answered with a single-step model that cannot be right.
What to do instead
Memorize the two-layer model: platform operators and the zen/control-plane custom resource first, then per-service operators and their custom resources, then service instances. For any install-order question, ask 'is this a platform-level or service-level component?' and place it in that sequence. Practice describing a full install as an ordered list of operators and CRs.
Answering sizing and capacity questions by picking the largest available profile ('just use large') rather than reasoning from node count, vCPU/memory per node, storage class and IOPS, and the specific service's documented minimums and scaling behavior.
Sizing guidance is scattered across service documentation and the platform hardware requirements, and candidates memorize a single 'minimum cluster' number without the per-service deltas, so they cannot discriminate between plausible distractors.
What to do instead
Build a one-page sizing sheet per service you expect to see (minimum worker nodes, vCPU, RAM, storage type, whether it needs ReadWriteMany). For each scenario, derive the answer from the workload described (number of users, data volume, HA requirement) instead of recalling a headline number, and eliminate options that ignore storage class or HA replication overhead.
Confusing identity and access layers: mixing up the platform's identity provider integration (LDAP/OIDC/SAML), the Cloud Pak for Data user management and roles, and OpenShift RBAC, and assuming an OpenShift cluster-admin is automatically a platform administrator with all catalog and project rights.
The product stacks several authorization systems, and candidates who administer only one layer assume privileges propagate. Exam items deliberately place a user with the 'right' OpenShift role but the wrong platform role.
What to do instead
Draw the three layers explicitly: cluster authentication (IdP), OpenShift RBAC (cluster/namespace), and platform authorization (platform roles plus per-service roles such as catalog collaborator or project admin). For each access question, identify which layer the action belongs to and check that layer's role, not the others.
Treating governance as a single switch: describing Watson Knowledge Catalog governance without distinguishing catalog assets, data classes, business terms, governance rules, data protection rules, and the enforcement point (project, catalog, or connection), and assuming a rule applies everywhere once created.
Governance concepts sound similar in prose, and candidates skim the rule types, so they pick an option that names the right concept but the wrong scope or enforcement mechanism.
What to do instead
Make a table of governance artifact to scope to enforcement point: business term (glossary), data class (classification and masking), governance rule (catalog-level behavior), data protection rule (deny/mask at asset or column level). For each scenario, name the exact artifact and where it is attached before reading the options.
Conflating data virtualization with data replication: answering integration questions with DataStage or replication when the requirement is federated query through a virtualized connection, or vice versa, without checking whether data must move or stay in place.
Both are 'data integration' and both appear in the same service family, and candidates lock onto the tool name they know rather than the requirement's latency, data-movement, and freshness constraints.
What to do instead
Before answering, classify the requirement: data must remain at source and be queried in place (virtualization/federation), data must be transformed and persisted (ETL/ELT), or data must be continuously synchronized (replication/CDC). Then map that class to the service. Reject any option whose data-movement model contradicts the stated constraint.
Assuming a connection created in one project or catalog is automatically usable everywhere, and missing that connections, credentials, and personal vs. shared credentials are scoped, and that platform connections versus project connections behave differently.
The UI makes connections feel global, and candidates rarely test cross-project access, so scoping and credential-sharing questions feel ambiguous and they guess.
What to do instead
Learn the scoping rules: platform-level connections (shared, governed) versus project-scoped connections, and personal credentials versus shared credentials. For each question, ask 'who needs to use this connection and from where?' and choose the scope and credential type that matches, eliminating options that silently assume global visibility.
Describing upgrades as 'apply the new version' without addressing the ordered upgrade path: platform upgrade before or after service upgrade, operator channel and subscription changes, backup and rollback prerequisites, and compatibility between platform version and service versions.
Upgrade content is procedural and version-specific, so candidates memorize a version number rather than the sequence and prerequisites, and then cannot order the steps in a scenario.
What to do instead
Memorize the upgrade skeleton: verify platform-to-service version compatibility, back up, update the platform operator and platform CR, then update each service operator and CR in the supported order, then validate. Practice ordering these steps and identifying which prerequisite (backup, compatibility matrix, channel) a scenario is testing.
Ignoring the deployment topology dimension: answering availability and resilience questions without distinguishing single-node/single-zone from multi-zone worker layouts, and without accounting for which components need replication or shared storage to survive a node or zone loss.
Topology questions read like generic HA questions, and candidates apply textbook HA answers that do not match the platform's actual storage and scheduling behavior.
What to do instead
For every resilience question, first state the topology (nodes, zones, storage class and access mode), then ask which component fails and whether its data is replicated. Eliminate options that claim zone-failure tolerance while relying on a storage class or replica count that cannot provide it.
Reaching for a rebuild or reinstall when a service is unhealthy, instead of following a diagnostic order: check pod and operator status, custom resource status and conditions, events, then logs, then configuration (storage, resource quotas, pull secrets, certificates).
Troubleshooting items reward a methodical narrowing, but candidates jump to the remedy they remember from a past incident and pick a destructive fix for a configuration problem.
What to do instead
Adopt a fixed triage sequence for every troubleshooting scenario: CR status and conditions, then pods and events, then logs, then configuration and quotas, then storage and networking. Choose the option that gathers evidence at the earliest failing layer, and reject destructive options unless the evidence already proves corruption.
Designing a solution without stating the non-functional requirements: answering architecture scenarios purely on feature fit while ignoring scaling, HA, data residency, latency, cost, and operational ownership, and thus choosing a technically valid but operationally wrong design.
Feature-matching is faster and feels safer under time pressure, and candidates underuse the scenario's stated constraints, which are usually the discriminator between two plausible designs.
What to do instead
Before evaluating options, extract and write down the scenario's constraints (users, data volume, residency, uptime, team skills, budget). Score each option against those constraints and pick the one that satisfies all stated requirements, even if it is less feature-rich. If two options both fit, the tiebreaker is almost always an explicit constraint you skipped.