CCP (WorldatWork Rewards Certifications) common mistakes
CCP · Understand the traps and how to avoid them.
Treating AWS as a list of standalone services and answering 'which service does X' without first identifying the workload's operational model (serverless, container, managed instance, batch).
Most prep material drills service names and feature lists, so candidates pattern-match a keyword in the stem to a familiar service and skip the architectural reasoning step that the scenario questions actually test.
What to do instead
Before evaluating options, restate the scenario in one sentence covering traffic pattern, statefulness, latency target, and team operational capacity. Eliminate any option that contradicts that sentence, then choose among survivors. Practise by writing the one-sentence restatement for 20 practice scenarios before looking at the answers.
Choosing the theoretically most scalable or cheapest architecture for a small, steady, low-variability workload, ignoring the operational overhead the team would absorb.
Candidates over-learn 'design for scale' and treat elasticity as an unconditional good, forgetting that managed overhead and complexity are also costs and that the exam rewards fitness for purpose.
What to do instead
Apply a proportionality test: if the workload is predictable and modest, prefer the simplest managed option that meets the requirement. Explicitly note in your reasoning why the more complex option's benefits do not apply here.
Mixing up when to use a load balancer versus when to use a queue or event bus for decoupling, and answering 'add a load balancer' for a problem that is really about absorbing bursty producer traffic.
Both appear in resilience questions and both sound like 'handling traffic', but they solve different problems: one distributes synchronous requests, the other buffers asynchronous work. The distinction is rarely made explicit in study notes.
What to do instead
Memorise the discriminator: is the consumer required to respond to the caller in the same request, or can work be deferred? Synchronous plus distribution means load balancer; deferred plus buffering means queue or event bus. Tag every practice question with 'sync' or 'async' before choosing.
Assuming a managed container or serverless platform automatically handles stateful workloads, sessions, or long-running jobs, and picking it for a scenario that needs persistent local state.
Marketing framing emphasises 'no servers to manage', which candidates read as 'no constraints'. The actual constraints (ephemeral storage, execution time limits, cold starts) are the discriminating detail in exam scenarios.
What to do instead
Keep a short constraint sheet per compute option: max execution duration, ephemeral storage, concurrency model, cold-start behaviour, and state persistence. When a scenario mentions long-running processes or local state, check the sheet before answering.
Defaulting to the largest or most durable storage class for every workload instead of matching access frequency, retrieval latency, and retrieval cost to the requirement.
Candidates conflate durability with suitability and fear choosing a class that sounds 'cheaper and worse'. In reality the exam often penalises over-provisioned storage because it ignores cost and access-pattern requirements.
What to do instead
For each storage question, extract three facts first: access frequency, tolerated retrieval latency, and whether data must be instantly retrievable. Map those three onto the class matrix rather than onto a vague sense of quality.
Confusing backup, replication, and archival as interchangeable durability measures, and answering a compliance-retention question with a replication feature.
All three protect data and all three appear in the same study chapter, but they differ in recovery objective, immutability, and cost. Candidates remember 'it copies data' and stop there.
What to do instead
Learn the three axes: recovery point objective, recovery time objective, and immutability/retention. Retention and legal-hold questions require an immutable archive; availability questions require replication; accidental-deletion questions require versioned backups. Label each practice scenario with the axis it is testing.
Designing a network topology that puts all resources in a single subnet or a single availability zone, then adding a firewall as the resilience answer.
Security controls feel more concrete and examinable than topology, so candidates reach for the control they can name. Multi-AZ and subnet-tiering reasoning requires holding a mental diagram that many candidates never build.
What to do instead
Sketch the three-tier layout (public ingress, private application, isolated data) across at least two zones for every VPC scenario, and check each option against that sketch. If an option collapses a tier or a zone, it is usually wrong regardless of the security features listed.
Answering connectivity questions with a VPN when the requirement implies private, dedicated, predictable bandwidth, or vice versa.
Both are 'private connections' in casual reading, and the exam rarely uses the vendor's exact terminology. Candidates match on 'secure connection' and miss the latency, bandwidth, and cost signals.
What to do instead
Build a two-column comparison: setup time, bandwidth predictability, encryption scope, and cost model. If the stem mentions consistent throughput, large sustained transfers, or a compliance requirement for a dedicated link, prefer the dedicated option; if it mentions fast setup or small occasional traffic, prefer the tunnel.
Granting broad permissions or using long-lived access keys because the scenario 'just needs it to work', instead of scoping to least privilege with temporary credentials.
Candidates optimise for whether the proposed solution functions, not for whether it would pass a security review. Least privilege and role assumption feel like extra steps rather than the point of the question.
What to do instead
Adopt a standing rule: any option containing wildcard actions, wildcard resources, or static long-lived keys is suspect unless the stem explicitly demands it. Prefer options using assumed roles and scoped policies, and state the scope in your reasoning.
Treating encryption and identity as substitutes, for example answering an authorisation question with 'encrypt the data' or a data-protection question with 'add a role'.
Both sit under the security umbrella and both are frequently correct answers in their own domains, so under time pressure candidates grab whichever security term they recognise first.
What to do instead
Classify the stem before answering: is the risk unauthorised access to data at rest or in transit (encryption), or is it who may perform an action (identity and policy)? Write the classification down; only then evaluate options within that category.
Choosing a monitoring answer that collects metrics when the scenario asks for tracing a single request across services, or vice versa.
Logging, metrics, and tracing are often taught as one 'observability' block, so the boundaries blur. The exam scenarios hinge precisely on that boundary.
What to do instead
Memorise the question each signal answers: metrics answer 'how much/how many over time', logs answer 'what happened in this component', traces answer 'where did this one request go and where did it slow down'. Match the stem's question to the signal before looking at product names.
Designing for high availability without defining a recovery objective, then being unable to distinguish backup-and-restore, warm standby, and active-active options.
Disaster recovery strategies are described in prose rather than numbers, so candidates pick the strategy that sounds most robust instead of the one meeting a stated recovery time and recovery point.
What to do instead
For every DR scenario, extract or infer the recovery time and recovery point objectives first, then map them onto the strategy ladder from cheapest/slowest to most expensive/fastest. If the stem gives no objective, choose the option that states one explicitly.
Ignoring the pricing model implications of a design choice, such as choosing a provisioned-capacity or always-on option for intermittent workloads, when the stem mentions cost constraints.
Cost is often the last sentence of a long scenario, and candidates who have already settled on a technically correct answer treat the cost clause as decoration rather than a filter.
What to do instead
Read the final sentence of every scenario first and highlight any constraint word: cost, budget, predictable spend, minimum waste. Then re-check your chosen option against that constraint before committing.
Confusing governance mechanisms (organisational guardrails, policy enforcement, account structure) with operational controls, and answering a 'prevent this from being deployed at all' question with a monitoring or alerting tool.
Both are about control, but governance acts before or at deployment while monitoring acts after. Candidates reach for the tool they know best rather than the point in the lifecycle the stem describes.
What to do instead
Locate the stem on a lifecycle line: design, deploy, run, audit. Prevention questions belong at deploy time with policy guardrails; detection questions belong at run time with monitoring. Answer only within the lifecycle stage the stem names.