IBM Cloud Professional Architect v6 common mistakes
IBM Cloud Professional Architect v6 · Understand the traps and how to avoid them.
Choosing a single-zone or single-region deployment for a workload whose stated requirement is high availability, then justifying it with 'IBM Cloud has redundant hardware inside a zone.'
Candidates conflate hardware redundancy within a data center with zone-level fault isolation, and they under-weight scenario keywords such as 'survive a data center outage' or 'RTO under 15 minutes.' IBM Cloud multi-zone regions (MZRs) and single-zone regions (SZRs) differ, and not every region offers three zones, so a reflexive 'spread across three zones' answer can also be wrong.
What to do instead
Before answering, extract the availability requirement and the target region from the stem. Map it explicitly: MZR with three zones for zone-fault tolerance, two regions plus Global Load Balancer or DNS-based failover for region fault tolerance, and SZR only when the requirement is modest or cost-driven. Memorize which IBM Cloud regions are MZR versus SZR (for example Dallas, Washington DC, London, Frankfurt, Tokyo, Sydney are MZR; Toronto, Sao Paulo, and Madrid are SZR) and check whether the stem constrains you to a specific region.
Treating VPC as if it were a classic infrastructure VLAN: assuming subnets are bound to a single zone, that security groups are stateful at the subnet level, or that a public gateway is required for all outbound traffic.
Candidates carry over mental models from Classic Infrastructure or from other clouds (AWS security groups versus NACLs, Azure NSGs). In IBM Cloud VPC, a subnet is bound to exactly one zone, security groups are stateful and attached to network interfaces, and there is no separate 'NACL' object; public gateways are per-zone and attach to a subnet.
What to do instead
Build a one-page comparison table of VPC primitives: VPC (regional), subnet (zonal, one zone), security group (stateful, instance/NIC-level), public gateway (per zone, attached to subnet), floating IP (per NIC), and routing table (per VPC). Re-read the VPC documentation sections on security groups and public gateways, and practice sketching a two-tier app across three zones in one VPC.
Designing a migration plan that lifts and shifts every workload without a wave plan, dependency map, or cutover/rollback strategy.
Candidates focus on the destination architecture and skip the migration method. Exam stems often include a legacy app with a database, middleware, and batch jobs, and the 'correct' answer is usually a phased approach with a pilot wave, dependency discovery, and a defined rollback, not a single big-bang move.
What to do instead
For every migration scenario, state the assessment output (portfolio segmentation: rehost, replatform, refactor, repurchase, retire, retain), the wave sequencing (pilot, then low-risk, then complex), the cutover pattern (DNS switch, replication catch-up, dual-run), and the rollback trigger. Practice writing a three-line migration runbook for a two-tier app moving to VPC.
Assuming a workload can be migrated to IBM Cloud as-is without checking OS, database, or middleware compatibility, and without an application dependency map.
Candidates treat 'rehost' as 'copy the VM.' In practice, rehosting to VPC requires checking whether the guest OS is supported on the target profile, whether the database version is supported as a managed service or must remain self-managed, and whether licensing (for example, per-core database licensing) changes the cost model.
What to do instead
For each migration question, list the compatibility checkpoints explicitly: OS version and architecture, database engine and version versus IBM Cloud Databases offerings, middleware and license portability, and network dependencies (DNS, LDAP, NTP, SMTP). If the stem mentions a version that is not offered as managed, choose self-managed on VPC or a replatform path.
Answering IAM questions with 'give the user the Administrator role' instead of scoping access to the specific resource and resource group.
Candidates default to the most permissive role because they are unsure of the role hierarchy. IBM Cloud IAM has platform roles (Viewer, Operator, Editor, Administrator) and service roles (Reader, Writer, Manager), and access is granted at account, resource group, or resource level. A common trap is that platform and service roles are separate and both may be needed.
What to do instead
Memorize the platform-versus-service role split and the scope levels (account, resource group, resource). For any access question, write the grant as 'principal + role + resource type + resource group/instance.' Practice identifying when a custom role or an access group with dynamic rules is the better answer.
Ignoring data residency and compliance constraints when selecting a region, or assuming that a global service stores data only where the workload runs.
Candidates optimize for latency or cost and forget that regulated data (PII, health, financial) may be required to stay in-country. IBM Cloud global services (for example, IAM, account management, and some platform services) have their own data handling, and some services are regional only.
What to do instead
For every architecture question, run a compliance gate: identify the data classification, the residency requirement, and the applicable framework (GDPR, HIPAA, PCI DSS, SOC 2, ISO 27001). Then confirm the chosen region and service tier support it. Use the IBM Cloud compliance and service data sheet pages to check whether a service is regional or global before committing.
Designing for cost by picking the smallest instance size everywhere, without considering reserved capacity, autoscaling, or the cost of cross-zone and egress traffic.
Candidates equate cost optimization with 'smallest SKU.' Real cost drivers in IBM Cloud include outbound bandwidth, cross-region replication, idle floating IPs, unbilled-but-charged storage tiers, and the difference between on-demand and reserved instance pricing.
What to do instead
For cost questions, enumerate the levers: right-sizing with monitoring data, autoscaling policies, reserved capacity for steady-state, lifecycle policies on Object Storage, deleting unattached floating IPs and volumes, and minimizing cross-region data transfer. Then pick the lever that matches the stem's constraint (for example, 'predictable steady load' points to reserved capacity, not autoscaling).
Treating observability as a single tool: assuming IBM Cloud Monitoring alone covers logs, traces, and metrics, or that Activity Tracker is a log store for application logs.
Candidates mix up the platform services. IBM Cloud Monitoring (Sysdig-based) handles metrics and some events; IBM Log Analysis handles logs; IBM Cloud Activity Tracker records account-level API audit events; and IBM Cloud Flow Logs for VPC captures network traffic. Using Activity Tracker for application logs, or Log Analysis for audit evidence, is a common error.
What to do instead
Memorize the four-way mapping: metrics to Monitoring, application and platform logs to Log Analysis, audit/API activity to Activity Tracker, network flow to VPC Flow Logs. For any reliability or security question, name the specific service that produces the evidence the stem asks for.
Skipping the shared responsibility model and assuming IBM Cloud secures everything above the hypervisor, including customer data, IAM policy, and encryption keys.
Candidates answer security questions with 'IBM encrypts data at rest' without distinguishing platform-managed keys from customer-managed keys (Hyper Protect Crypto Services or Key Protect) and without stating which controls the customer owns.
What to do instead
For each security question, split controls into IBM-managed (physical, hypervisor, managed service patching) and customer-managed (IAM, network ACLs and security groups, OS patching on VPC instances, key management, data classification). When the stem mentions regulatory key custody or 'customer must control keys,' choose Hyper Protect Crypto Services (FIPS 140-2 Level 4) over Key Protect.
Proposing a modernization path (containers, Kubernetes, serverless) for every workload without justifying it against the workload's characteristics and team maturity.
Candidates assume 'modernize' always means 'containerize.' Exam stems often describe a batch job, a monolith with a large stateful database, or a team with no Kubernetes experience, where replatforming to a managed service or retaining with minor optimization is the better answer.
What to do instead
Use a decision rubric: stateless 12-factor services and microservices point to IBM Cloud Kubernetes Service or Code Engine; event-driven short-lived functions point to Code Engine functions; stateful monoliths with tight DB coupling point to VPC VMs or VMware Solutions; and batch jobs point to Code Engine jobs or Batch. Justify the choice with the workload's scaling profile, state, and operational maturity, not with a preference for containers.