ACA CCP common mistakes
ACA CCP · Understand the traps and how to avoid them.
Treating IaaS, PaaS, and SaaS as a single blended category and picking the 'cloud service model' answer that sounds most modern rather than matching the layer of responsibility described in the scenario.
Candidates memorise the three acronyms as definitions but never map them to who manages what (OS, runtime, application). Under time pressure they default to the newest-sounding term.
What to do instead
Before answering, draw a quick line for the scenario: who patches the OS, who deploys the code, who uses the app. Assign the model by the highest layer the customer still controls, then check the option matches that layer.
Confusing elasticity/scalability with availability or with cost optimisation, and selecting 'auto scaling' as the answer to any question containing the word 'traffic' or 'demand'.
The terms cluster together in study material and all sound like 'handling growth'. Candidates stop reading the actual requirement (e.g. surviving an AZ failure, or reducing spend).
What to do instead
Classify the requirement first: capacity change over time = elasticity; fault tolerance = availability/redundancy; lower unit cost = pricing model. Only then match the product feature to that single requirement.
Mixing up the roles of the core compute, storage, and networking products, e.g. choosing an object storage bucket for a scenario that needs a POSIX-mounted filesystem shared by several instances, or vice versa.
All storage options are described as 'scalable and durable', so candidates key on the adjectives instead of the access pattern. Similarly, load balancing, NAT gateway, and EIP get conflated as 'networking'.
What to do instead
Learn each product by its access interface and semantics: block (attached to one instance), file (shared mount), object (HTTP/key-based), plus which networking component is inbound vs outbound and public vs private. Answer by access pattern, not by marketing words.
Assuming a managed database service removes the need for the candidate to reason about replication, backup, or read/write splitting, and picking 'the managed service handles everything' as the answer.
The 'managed' label invites the belief that all operational concerns vanish. In reality the exam tests which capabilities you must still configure (e.g. read-only replicas for read scaling, backup retention).
What to do instead
For every managed-service question, ask what the service does automatically versus what the customer must enable. Read-scaling and disaster recovery answers usually require an explicit configuration step, not the default.
Choosing the security control that matches the threat description rather than the layer the question asks about, e.g. answering a 'protect against SQL injection' item with a network firewall or WAF interchangeably.
Candidates match on the attack name and grab the first security product they associate with it, ignoring whether the control operates at the network, host, or application layer.
What to do instead
Tag each control with its layer before choosing: network (security groups, firewalls), host (anti-malware, patching), application (WAF), identity (RAM). Then confirm the layer in the stem matches the layer of the answer.
Treating identity and access management as a single 'give the user admin' decision, failing to distinguish between granting permissions to a user, a group, or a role assumed by a service.
Candidates learn that policies attach to identities but not that long-term credentials should be avoided for workloads. They pick 'create an AccessKey for the application' as the standard answer.
What to do instead
Default to least privilege via groups for humans and roles for services; reserve AccessKeys for cases with no role option. When an option grants broad admin or embeds long-lived keys, treat it as a distractor unless the scenario explicitly demands it.
Answering encryption questions with 'enable encryption' without specifying at-rest versus in-transit or who manages the key, and picking the option that encrypts in the wrong place.
Encryption is treated as a binary switch. The exam distinguishes data on disk, data on the wire, and key custody, and candidates collapse these into one concept.
What to do instead
Split every encryption option into two axes: where (at rest / in transit) and key ownership (provider-managed / customer-managed). Match both axes to the scenario's stated risk before selecting.
Designing for high availability by adding more instances in a single zone instead of distributing across zones, and labelling horizontal scaling as a resilience design.
Scaling out and fault tolerance both 'add redundancy', so candidates substitute one for the other. They also overlook that a single-zone deployment fails together.
What to do instead
For any availability question, first ask 'what single failure must this survive?' If the answer is a datacenter or zone outage, the design must span zones; instance count within one zone does not satisfy it.
Ignoring the operational lifecycle in architecture questions: proposing a design with no monitoring, logging, backup, or rollback path and still selecting it because it is technically functional.
Candidates optimise for 'does it work' and forget the exam also scores operability. Options that omit observability or recovery are often the most attractive distractors.
What to do instead
Screen candidate designs against a checklist: monitoring/alerting, logging/audit, backup and restore, and change/rollback. Eliminate any option that satisfies the functional requirement but fails a lifecycle item the stem implies.
Skipping the cost and trade-off reasoning in architecture items, choosing the most robust or highest-spec option regardless of the stated budget or workload profile.
Candidates equate 'best practice' with 'most redundant'. Exam scenarios often constrain cost or workload characteristics, making the over-engineered option wrong.
What to do instead
Re-read the stem for explicit constraints (budget, traffic pattern, latency, data volume) and eliminate options that exceed them. Prefer the design that meets the stated requirement with the least unnecessary redundancy.