CCOA (IJCAHPO) common mistakes
CCOA · Understand the traps and how to avoid them.
Treating 'cloud architecture' questions as pure product-recall and picking the service with the most features rather than the one that satisfies the stated constraints (availability target, region count, latency, budget).
Candidates memorize service catalogs from marketing material and answer from familiarity, ignoring the design requirements embedded in the stem, so they choose over-engineered or single-region solutions when the prompt asked for multi-AZ resilience or cost control.
What to do instead
Before answering, extract the explicit constraints from the stem into a short list (RTO/RPO, AZ/region scope, throughput, spend ceiling) and eliminate any option that violates one. Practice writing one-sentence justifications for why each rejected option fails a stated constraint.
Confusing managed orchestration control planes with the data plane, and answering questions about worker capacity, node pools, or scheduler behavior as if the provider manages them automatically.
Provider documentation emphasizes 'fully managed' control planes, so candidates assume everything is handled, then misjudge questions about node autoscaling, pod scheduling, or cluster upgrades that remain the customer's responsibility.
What to do instead
Build a two-column mental model for each managed orchestrator: what the provider patches and scales versus what you must size, upgrade, and monitor. Review the shared-responsibility split for the specific service before answering node and scheduler questions.
Treating state files as an afterthought: assuming remote state is optional, storing state in the repo, or expecting a plan to be a no-op when resources were changed outside the tool.
Local tutorials use local state for simplicity, so candidates never internalize locking, drift, and secret exposure until exam questions probe collaboration and concurrency scenarios.
What to do instead
Memorize the standard remote-backend pattern (remote object storage plus locking plus encryption) and the consequences of drift. For any IaC scenario question, first ask where state lives and who can lock it, then evaluate the options.
Assuming a Pod is a durable unit and designing around pod IPs, local disk, or in-pod state instead of Services, persistent volumes, and controllers.
Hands-on practice often stops at running a single container, so candidates never see pods rescheduled with new IPs or ephemeral filesystems lost, and they pick answers that depend on pod identity.
What to do instead
Drill the lifecycle: pods are disposable, IPs change, local storage dies with the pod. When an option references a pod directly for discovery or persistence, treat it as a red flag unless the stem describes a deliberate, bounded use case.
Designing pipelines that rebuild and redeploy the same artifact for each environment, or that run database migrations and destructive steps without a gate, rather than promoting one immutable artifact through stages.
Candidates equate 'CI/CD' with 'run tests then deploy' and overlook artifact immutability, environment promotion, and rollback, which are the exact points release-engineering questions test.
What to do instead
Adopt the build-once-promote-everywhere rule as a default answer filter: if an option rebuilds per environment, it is usually wrong. Pair it with explicit approval gates and reversible migration steps, and be able to explain rollback for each stage.
Choosing logging and monitoring answers that maximize data collected (log everything at debug, keep all metrics forever) instead of matching signal type to purpose and defining retention and sampling.
Candidates conflate 'more observability' with 'better observability' and miss that the exam tests cost-aware, purpose-driven telemetry design and the three pillars distinction.
What to do instead
Map each question to the pillar it needs: metrics for alerting on aggregates, logs for discrete events, traces for request paths. Reject options with unbounded cardinality, infinite retention, or debug-level production logging unless the stem explicitly requires forensic depth.
Answering identity questions with long-lived access keys or broad roles because they are simpler, instead of least-privilege roles, short-lived credentials, and explicit trust boundaries.
Quick-start guides use static credentials, so candidates default to them and fail questions that hinge on credential rotation, cross-account trust, or separation of duties.
What to do instead
Make 'no static long-lived secrets' a default elimination rule. For each identity scenario, identify who assumes what role, for how long, and with which scoped permissions, and prefer options that scope by resource and condition rather than wildcard actions.
Optimizing cost by deleting or downsizing resources without checking the availability and performance requirements stated in the stem, or ignoring the pricing model (reserved, spot, on-demand) that fits the workload pattern.
Candidates treat cost questions as pure arithmetic and pick the cheapest line item, missing that the correct answer is the cheapest option that still meets the SLA and workload characteristics.
What to do instead
For cost items, restate the workload profile first (steady versus bursty, interruption-tolerant or not) and the SLA, then match pricing models to that profile. Eliminate any 'savings' option that breaks the stated availability or latency requirement.
Reading only the last sentence of a long scenario and answering the surface question, missing the qualifier ('least operational overhead', 'most cost-effective', 'highest availability') that determines which of several technically valid options is correct.
Exam stems are long and candidates skim under time pressure; the discriminating constraint is often buried mid-stem or in a trailing qualifier, so they pick a valid-but-suboptimal answer.
What to do instead
Practice a fixed reading routine: identify the qualifier first, then the constraints, then evaluate options. When two options both work, re-read the qualifier and choose the one that optimizes exactly that dimension.
Ignoring the blast radius of automation: writing scripts or pipeline steps that apply changes to all environments or accounts at once, with no dry-run, canary, or rollback path.
Candidates focus on getting automation to work once in a single environment and never consider failure propagation, so they choose options that maximize speed while ignoring staged rollout and reversibility.
What to do instead
For any automation or deployment question, check three things in order: is there a plan or dry-run step, is the rollout staged (canary or phased), and is there a tested rollback. Options missing all three are usually distractors.