CCP (Other exams) common mistakes
CCP · Understand the traps and how to avoid them.
Treating the shared responsibility model as a single fixed split, so the candidate assigns a control (e.g., patching the guest OS on IaaS, encrypting data at rest, configuring bucket policies) to the provider when the customer owns it, or vice versa for SaaS.
Candidates memorize 'the provider secures the cloud, you secure what's in it' but never map it per service model, so the boundary shifts between IaaS, PaaS, and SaaS and they answer from the slogan instead of the service.
What to do instead
Build a 3-column table (IaaS/PaaS/SaaS) and place each control layer (physical, hypervisor, OS, runtime, app, data, identity, network config) in the owning party's column; before answering, name the service model in the stem and read the row.
Choosing the most available or most durable storage/architecture option by default, ignoring the cost and access-frequency signals in the scenario (e.g., picking multi-region replication for infrequently read backups).
Candidates equate 'best practice' with 'maximum resilience' and answer the architecturally strongest option rather than the one matching the stated RPO/RTO, access pattern, and budget.
What to do instead
Extract the explicit constraints (access frequency, retention, RPO/RTO, budget) into a short list first, then eliminate any option that violates a constraint before comparing the survivors.
Confusing elasticity/scalability with high availability, so the candidate selects auto-scaling as the fix for a requirement that is actually about surviving a zone or region failure.
All three concepts are described with similar language ('handles demand', 'stays up'), and candidates pattern-match the word 'resilient' to scaling without checking whether the failure domain in the stem is load or infrastructure loss.
What to do instead
Classify the requirement first: load variation → elasticity/scalability; component or AZ failure → high availability; region loss → disaster recovery. Match the option to the classified failure mode.
Picking a network design that is technically valid but ignores the trust boundary, such as exposing a database or admin interface to the public internet or routing all traffic through a single flat subnet, when the stem implies least privilege.
Candidates focus on connectivity ('can it reach?') and forget that security groups, private subnets, and bastion/private-link patterns are the expected answer whenever the scenario mentions sensitive data or compliance.
What to do instead
After choosing a connectivity answer, run a one-line check: 'Is anything now reachable that the stem said should be restricted?' If yes, prefer the private-path option (private subnet, security group restriction, private endpoint).
Treating identity and access management as an afterthought, so the candidate grants broad roles or uses long-lived access keys where the scenario calls for federation, roles, or least privilege.
IAM questions read like configuration trivia, and candidates answer 'what makes it work' rather than 'what makes it work with the minimum permission and no static credentials'.
What to do instead
Memorize the default preference order: federated identity/role assumption > scoped policy > broad policy > static keys. Any option containing long-lived credentials for humans or cross-account access should be a red flag.
Failing to distinguish governance controls from operational controls, so the candidate proposes tagging, budgets, or policy guardrails to solve a runtime incident, or proposes monitoring to solve a cost-allocation problem.
Cost management and governance overlap with operations in vocabulary (both mention 'monitoring', 'policies', 'alerts'), and candidates don't separate 'prevent/allocate' from 'detect/respond'.
What to do instead
Tag each requirement as prevent, allocate, detect, or respond before looking at options; governance tools (tags, budgets, policy-as-code) answer prevent/allocate, observability tools answer detect/respond.
Assuming the cheapest list price equals the lowest total cost, ignoring data egress, request charges, storage tier minimum durations, or idle reserved capacity when comparing options.
Candidates compare the headline unit (per GB stored, per hour) and miss the secondary billing dimensions that dominate real workloads, especially for data-intensive or spiky usage.
What to do instead
For every cost comparison, enumerate all billing dimensions the option touches (compute, storage, requests, egress, minimum commitment) and check the workload profile in the stem for the dimension that will dominate.
Confusing backup, replication, and archival as interchangeable, so the candidate proposes cross-region replication as a ransomware or accidental-deletion defense, or archive storage as a fast-recovery solution.
All three 'copy the data elsewhere', and candidates don't check whether the requirement is recoverability from corruption/deletion (needs immutability/versioning/point-in-time), durability (replication), or low-cost retention (archive with retrieval latency).
What to do instead
Map the threat or requirement to the mechanism: corruption/deletion → versioning/immutable backups; site loss → replication/DR; long retention at low cost → archive with retrieval-time noted. Reject options whose mechanism doesn't match the threat.
Answering deployment and operations questions with manual or ad hoc procedures (console clicks, hand-built environments) when the stem signals repeatability, auditability, or multiple environments.
Candidates read 'how do you deploy' as 'what is the fastest way to deploy once' instead of recognizing the infrastructure-as-code/CI-CD signal words (repeatable, consistent, auditable, multiple environments).
What to do instead
Scan the stem for repeatability and audit keywords; when present, prefer declarative IaC and pipeline-based deployment over manual steps, and prefer immutable/replaceable infrastructure over in-place mutation.
Ignoring data residency and compliance scope, so the candidate selects a global or multi-region service that moves data across borders when the stem specifies a regulated region or a specific framework.
Candidates optimize for availability and latency and treat geography as a performance detail rather than a legal constraint, missing that some services replicate metadata or data globally by design.
What to do instead
Treat every stated region, residency, or framework requirement as a hard filter applied first; eliminate any option whose data path crosses the boundary, then optimize among the remaining compliant options.