CCP-C common mistakes
CCP-C · Understand the traps and how to avoid them.
Selecting an answer because the service name looks familiar, without first deciding whether the scenario describes IaaS, PaaS, or SaaS - for example, answering 'the customer must patch the guest operating system' on a scenario that actually describes a managed application platform.
Candidates memorise product catalogues and brand names instead of the service-model boundary, and the exam deliberately uses vendor-neutral wording that hides which layer is being managed by whom.
What to do instead
Before reading the options, write one line classifying the scenario against the five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service) and the IaaS/PaaS/SaaS boundary. Then ask 'who manages the OS in this model?' and eliminate any option that contradicts it.
Treating high availability and disaster recovery as the same requirement - proposing a multi-region active-active design for a scenario that only asks to survive the loss of a single data centre within a stated availability target.
Both topics use the same vocabulary (redundancy, failover, resilience) and candidates pattern-match 'resilience' to 'multi-region' without checking the stated RTO, RPO, and availability figure.
What to do instead
Convert every scenario into explicit numbers first (RTO, RPO, availability %), then map the tiers: single-AZ = no HA, multi-AZ = HA within a region, multi-region = DR or extreme availability. Reject any option that exceeds the stated requirement, because over-engineering is scored as wrong when the stem says 'MOST cost-effective'.
Assuming the cloud provider secures everything above the physical layer - choosing options in which the provider patches the guest OS, hardens the application, or manages tenant identity and access configuration.
Marketing language such as 'fully managed' and 'secure by default' blurs the shared responsibility split, and candidates generalise from the provider-managed layer to the whole stack.
What to do instead
Draw the split per service model and check the option against it: for IaaS the provider owns facilities, hardware, and hypervisor while the customer owns OS, patching, and everything above; for PaaS the provider adds OS and runtime while the customer still owns application code, data, and identity/permission configuration; for SaaS the customer retains data, access management, and client-side configuration.
Conflating 'encryption is enabled' with 'the customer controls the key' - answering that provider-managed encryption satisfies a requirement for customer-controlled key rotation, key revocation, or the ability to make data unreadable on demand.
Encryption at rest, encryption in transit, and key custody are usually taught as one topic, so candidates tick the 'encrypted' option and stop reading the qualifying clause about key ownership.
What to do instead
Separate the three controls every time: (1) is the data encrypted at rest, (2) is it encrypted in transit with valid certificates, (3) who holds and can revoke the key (provider-managed, customer-managed/BYOK, or externally held HSM/HYOK). If the stem mentions revocation, rotation policy, or separation of duties, only a customer-controlled key option can be correct.
Mixing up release strategies - answering 'blue/green' for a stem that requires exposing a change to a small slice of live traffic while watching error rates, or answering 'canary' where the requirement is instant rollback by switching traffic back to the previous environment.
The strategies differ only in the traffic-handling detail, and candidates recall the labels without the trigger conditions that distinguish them.
What to do instead
Memorise each strategy by its trigger phrase: rolling = replace instances in batches, no extra capacity, mixed versions during rollout; blue/green = two full environments, instant cutover and instant rollback, double cost during the switch; canary = small percentage of traffic first, metrics-gated promotion. Match the stem's phrase ('minimise blast radius', 'instant rollback', 'no extra capacity') to the strategy before looking at the options.
Adding an explicit inbound rule for the return half of a connection because the candidate believes the cloud firewall is stateless - or, in the reverse error, assuming a subnet-level access control list automatically permits return traffic to ephemeral ports.
The two filtering layers look like the same feature in the console and the stateful/stateless distinction is a single word that candidates skip over when reading quickly.
What to do instead
Anchor the pair: security-group style filtering is stateful - allow the request and the response returns automatically; subnet-level ACLs are stateless - you must permit both directions, including the outbound request port and the inbound ephemeral range (commonly 1024–65535). Check the direction and the port range in the option before judging it.
Designing a multi-VPC topology with pairwise peering and assuming connectivity is transitive - for example, peering A-to-B and B-to-C and expecting A to reach C, or peering two networks whose IP ranges overlap.
Peering is described as 'private connectivity', so candidates mentally equate it with a routed network where every connected node reaches every other node.
What to do instead
Treat peering as a non-transitive one-to-one link. If the design has a hub, or more than two networks that all need to communicate, use a transit/hub construct (transit gateway, hub VPC with routing, or a shared network). Always verify that CIDR ranges do not overlap before selecting any peering option.
Accepting a read replica, a same-region snapshot, or a nightly export as the answer to a durability or disaster-recovery requirement - especially where the stated RPO is near zero or where the scenario describes accidental deletion or a malicious actor.
Replication and snapshots both look like 'copies of the data', so candidates stop at 'there is a copy' without checking where it lives, whether it is isolated from the primary account, whether it is immutable, and whether a restore has ever been tested.
What to do instead
Score each data-protection option on four axes: distance (same AZ, same region, cross-region), isolation (same account, cross-account, immutable/object-lock), lag (synchronous vs asynchronous, and the RPO it implies), and restore testability. Replication protects against infrastructure failure, not against deletion or corruption - only point-in-time recovery, versioning, or immutable copies do.
Treating infrastructure as code as a set of imperative deployment scripts - expecting a second run to 'just pick up the changes', hand-editing resources in the console afterwards, or planning changes without reviewing the diff first.
Candidates with scripting backgrounds map templates onto shell scripts, so idempotency, desired-state reconciliation, and state files are unfamiliar concepts that the options test directly.
What to do instead
Learn the four properties and check options against them: declarative (describe the end state, not the steps), idempotent (re-applying the same template changes nothing), stateful (a state file records what exists, and out-of-band console edits cause drift), and gated (a plan/diff is reviewed before apply). Any option that relies on manual console changes to a managed resource is drift, not a fix.
Choosing the cheapest published unit price for a steady-state 24/7 workload, and ignoring data transfer egress, cross-zone traffic, idle or oversized resources, storage tiering, and the staff time the option consumes.
The on-demand hourly rate is the most visible number, while egress charges and operational overhead are invisible in a quick comparison - and stems that say 'MOST cost-effective' invite exactly this shortcut.
What to do instead
Match workload pattern to pricing model first: spiky or short-lived = on-demand; predictable steady-state = commitment or savings plan; interruption-tolerant batch = spot/preemptible. Then build a mini total cost of ownership covering compute, storage tier chosen by access frequency, egress and cross-zone transfer, idle and orphaned resources, and the operational effort of running it. Re-read the stem's qualifier ('cost-effective' vs 'lowest operational overhead') before selecting.