PCAM common mistakes
PCAM · Understand the traps and how to avoid them.
When a scenario describes a workload with regulatory data-residency requirements, candidates pick the single-region design that is cheapest or simplest and treat multi-region as over-engineering, instead of first deriving the compliance constraint (data cannot leave a jurisdiction) and letting it drive the region and replication topology.
Candidates default to cost or latency intuition from general cloud experience and skim the compliance sentence in the prompt. PCAM-style scenario questions deliberately bury the binding constraint in a requirement list, and the 'obvious' architecture answer is often the one that violates residency or sovereignty.
What to do instead
Before evaluating any option, extract and rank the hard constraints (residency, encryption, retention, latency SLO) into a short list. Eliminate any option that violates a hard constraint first, then optimize cost among survivors. Practice writing a one-line constraint ledger for every scenario you read.
Candidates design a flat network with a single large VPC/VNet and default route tables, then try to bolt on segmentation later, rather than planning a hub-and-spoke or landing-zone topology with explicit subnets, route domains, and inspection points up front.
It is easy to reason about one network and hard to visualize routing, peering transitivity, and inspection insertion. Candidates underestimate that peering is non-transitive and that shared services (DNS, inspection, egress) need a deliberate hub, so their answers fail on connectivity or blast-radius requirements.
What to do instead
Memorize the failure properties: peering/VNet-peering is non-transitive, overlapping CIDRs block peering, and centralized egress requires a hub with route propagation. For each scenario, draw the spoke-to-shared-service path and confirm every hop is explicitly routed before choosing an option.
Candidates equate 'encrypted at rest' with 'compliant' and skip key management design, choosing provider-managed keys by default even when the scenario requires customer-controlled keys, key rotation, or separation of duties between key administrators and data users.
Encryption is treated as a checkbox rather than a key-custody and access-control problem. Candidates do not distinguish provider-managed from customer-managed keys, or key policy from data-plane IAM policy, so they miss options that satisfy the stated governance requirement.
What to do instead
For every security scenario, ask three questions: who controls the key, who can use the key, and who can audit key use. Map those to customer-managed key services with explicit key policies and rotation. Reject options that collapse key administration and data access into one role when separation of duties is stated.
Candidates choose a storage class or database engine by habit (e.g., always relational, always hot tier) instead of deriving access pattern, consistency, and durability requirements from the scenario before selecting a service.
Service familiarity biases the answer. Candidates do not translate 'append-only audit logs read rarely' or 'multi-writer global low-latency' into the correct storage or consistency model, so they pick a technically valid but requirement-mismatched option.
What to do instead
Build a habit of stating the access pattern (read/write ratio, item size, query shape, consistency tolerance, retention) before looking at options. Then match: object lifecycle tiers for cold immutable data, key-value/document for high-scale simple lookups, relational for multi-entity transactions, and explicitly reason about consistency models.
Candidates treat 'lift and shift' as the default migration and stop there, failing to identify which components should be re-platformed or refactored, and they skip the dependency mapping and cutover/rollback plan that the scenario implicitly requires.
Lift-and-shift is the lowest-effort mental model, so it feels safe. Candidates also underestimate hidden coupling (shared databases, hard-coded endpoints, scheduled jobs) and therefore miss answers that require a phased migration with a coexistence period.
What to do instead
For migration scenarios, produce a disposition per component (retire, retain, rehost, replatform, refactor) with a one-line rationale, then map dependencies and define cutover, validation, and rollback. Choose the option that names the sequencing and rollback mechanism, not just the target state.
Candidates design for high availability but conflate it with disaster recovery, claiming a multi-AZ/multi-zone deployment satisfies an RPO/RTO requirement that actually demands cross-region replication and tested failover.
Multi-AZ is the first resilience pattern learned and sounds sufficient. Candidates do not separate the failure domain (zone vs region vs provider) from the recovery objective, so they accept an option whose blast radius still includes the stated disaster.
What to do instead
Always restate RPO and RTO numerically, then identify the failure domain the requirement targets. Match: zone failure to multi-AZ, region failure to cross-region replication plus failover runbook, and data corruption to point-in-time recovery and immutable backups. Verify the chosen option's blast radius excludes the stated failure.
Candidates optimize cost by downsizing instances or buying commitments before establishing a measurement baseline, and they ignore that the scenario's performance SLO or burst pattern makes the cheaper option infeasible.
Cost questions reward the cheapest-looking number, and candidates anchor on list price rather than total cost of ownership including egress, storage operations, idle capacity, and rework. They also skip right-sizing evidence, so the 'cheap' answer violates the stated latency or throughput target.
What to do instead
Compute a rough TCO per option: compute, storage, data transfer, and operational overhead. Check each option against the stated performance SLO and burst profile before ranking on cost. Prefer commitment or savings-plan answers only when the scenario states steady, predictable utilization.
Candidates propose manual operational steps or ad-hoc console changes for repeatable tasks (patching, key rotation, environment provisioning) instead of infrastructure-as-code and policy-as-code with drift detection and audit trails.
Manual steps are easy to describe and seem sufficient for a single scenario. Candidates underestimate that governance questions test repeatability, least privilege, and evidence of control, which manual processes cannot provide at scale.
What to do instead
For any operations or governance scenario, prefer declarative IaC with version control, automated policy evaluation in the pipeline, and drift detection. When an option offers manual review or console changes, reject it unless the scenario explicitly requires break-glass handling with logged approval.
Candidates grant broad roles (owner/admin, wildcard actions) to 'simplify' identity design, or they model only human users and forget workload identities, federation, and cross-account/cross-tenant trust boundaries.
Broad permissions remove friction in the candidate's mental model, and least privilege requires enumerating actions, which is effortful. Candidates also default to long-lived access keys because they are familiar, missing that the scenario tests short-lived credentials and role assumption.
What to do instead
Design identity around principals (human, workload, service) and trust relationships, then scope permissions to the minimum action set on specific resources. Prefer federation and short-lived role assumption over static keys, and explicitly verify that cross-account access is scoped by trust policy plus resource policy.
Candidates answer the question they wish were asked (e.g., 'what is the best architecture?') instead of the one asked (e.g., 'which change meets the requirement with least operational overhead?'), and they do not eliminate options that are technically correct but violate a stated qualifier.
Scenario stems contain qualifiers (least cost, least operational overhead, fastest to implement) that change the correct answer. Candidates evaluate options on general merit and pick the most sophisticated design, ignoring the optimization target the question names.
What to do instead
Underline the optimization qualifier in every stem and score each option against it explicitly. When two options are both valid, choose the one that satisfies the qualifier, and write one sentence justifying why the runner-up fails that specific criterion.