PCCP - Professional Cloud Certified Professional common mistakes
PCCP · Understand the traps and how to avoid them.
Choosing a single-region design with no stated recovery objective whenever a scenario mentions cost pressure, then defending it as 'cheapest option'.
Candidates optimize for the line-item cost shown in the prompt and skip the availability requirement buried in the business narrative (RTO/RPO, SLA, seasonal peaks). The exam scores the requirement, not the cheapest bill.
What to do instead
Before selecting services, write down the implied RTO/RPO and availability target from the scenario text, then map each to a pattern (single zone, multi-zone, multi-region active-passive, active-active). Justify cost only after the reliability requirement is satisfied, and state the residual risk you accept.
Treating a hybrid connectivity question as a pure networking quiz and picking a VPN or Interconnect without discussing routing, BGP, or failover behavior.
The scenario reads like a bandwidth question, so candidates jump to the product name. The exam tests whether the design survives a link failure and how traffic is steered, which is where most points are lost.
What to do instead
For every hybrid question, answer four things explicitly: primary path, backup path, how routes are advertised (dynamic vs static), and what happens on failover. If a scenario requires deterministic latency or SLA, say why a dedicated interconnect beats a VPN and how you keep a VPN as backup.
Proposing manual console steps or ad-hoc scripts as the provisioning method for a repeatable environment.
Candidates describe what they would click through in a lab rather than how a team would reproduce the environment. The exam rewards infrastructure-as-code, templates, and pipeline-driven provisioning.
What to do instead
Default to declarative IaC (templates/modules), version control, and a CI/CD pipeline with plan/apply stages. Describe environment promotion (dev to staging to prod) and how drift is detected. Mention manual steps only as break-glass, with an audit trail.
Sizing compute and storage from a single average utilization number and never addressing autoscaling, quotas, or cost controls.
The prompt gives one metric (average CPU, average IOPS) and candidates treat it as the design input. Real workloads are bursty, and quota limits are a classic implementation blocker.
What to do instead
Design for peak plus headroom, specify autoscaling signals and bounds, and check regional quotas for the resources you propose. Add a cost guardrail (budgets, alerts, committed-use discounts) and state how you would validate sizing with a load test before full rollout.
Answering identity questions with 'use IAM roles' and stopping there, without separating human, workload, and cross-project access.
Roles are the correct primitive, so the answer feels complete. The exam probes least privilege, separation of duties, and how service identities are scoped, which a one-line answer never covers.
What to do instead
Break access into three planes: workforce identity (federated SSO, MFA, group-based roles), workload identity (dedicated service accounts, short-lived credentials, no static keys), and cross-boundary access (explicit trust policies, conditions). State how permissions are reviewed and revoked.
Encrypting data at rest and calling the compliance requirement satisfied, ignoring key management, data residency, and audit logging.
Encryption is the most familiar control, so candidates equate it with compliance. Regulated scenarios usually hinge on who controls keys, where data lives, and whether access is provable after the fact.
What to do instead
For each compliance scenario, enumerate the control families: encryption in transit and at rest, key custody (provider-managed vs customer-managed vs external), residency constraints on storage and backups, and immutable audit logs with retention. Map each control to the specific regulation named in the prompt.
Presenting a migration or modernization plan with no baseline metrics or success criteria.
Candidates focus on the target state and skip measurement, because the prompt asks 'how would you migrate' rather than 'how would you prove it worked'. The exam expects a before/after comparison.
What to do instead
Define baseline metrics (latency, cost per transaction, error rate, deployment frequency), the target values, and the measurement method. Tie each process change to a metric it should move, and include a rollback or validation gate before declaring the migration complete.
Recommending the newest managed service for every workload without weighing operational overhead, lock-in, or team skill.
Managed services are usually the 'right' answer in cloud exams, so candidates over-apply them. The exam also tests trade-off reasoning, and an unjustified choice reads as a guess.
What to do instead
For each service choice, state the alternative you rejected and why: operational burden, portability, cost curve at the expected scale, and team capability. Prefer managed services when they remove undifferentiated toil, and say explicitly what you gain and give up.
Describing a monitoring stack as 'set up dashboards and alerts' with no SLOs, error budgets, or alert routing.
Monitoring is treated as a checkbox rather than a feedback loop. The exam wants to see that operations are driven by measurable objectives and that alerts reach someone who can act.
What to do instead
Define SLIs and SLOs per user-facing journey, derive error budgets, and specify alert thresholds tied to burn rate rather than raw CPU. Describe routing (on-call rotation, escalation, runbook link) and what automated remediation runs before a human is paged.
Writing a disaster-recovery plan that stops at backups, with no restore test, no failover runbook, and no defined decision authority.
Backups feel like the hard part, so candidates stop there. The exam tests whether recovery actually works under pressure, which requires tested restores and clear ownership.
What to do instead
Specify backup frequency and retention, then a scheduled restore test with a pass/fail criterion. Add a failover runbook with trigger conditions, named decision owner, communication plan, and a post-incident review. State the measured RTO/RPO from the last test, not the aspirational one.