CCC-A common mistakes
CCC-A · Understand the traps and how to avoid them.
Treating 'cloud' as a synonym for 'virtualization' and answering that virtual machines on owned hardware are cloud computing, missing the on-demand self-service and measured-service elements of the definition.
Most candidates arrive with a VMware or hypervisor background, and virtualization is the most visible enabling technology, so the mental model collapses into 'VMs = cloud'. Exam items deliberately probe the essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service) and a virtualization-only answer fails several of them.
What to do instead
Before answering any definitional item, check the scenario against all five essential characteristics and the three service models explicitly. If a described environment lacks self-service provisioning or metered billing, it is not cloud under the exam's definition. Build a one-page checklist and run every scenario through it.
Confusing IaaS, PaaS, and SaaS by what the provider hosts rather than by where the customer's management responsibility stops, so a managed database is mislabeled IaaS because 'it is infrastructure' or a container platform is mislabeled SaaS.
The services overlap in practice: a managed Kubernetes service, a managed database, and a serverless function platform each sit between the classic tiers. Candidates memorize vendor examples instead of the responsibility boundary, so unfamiliar examples break the mapping.
What to do instead
Classify by the control boundary: IaaS leaves the customer managing OS, middleware, and runtime; PaaS leaves the customer managing only applications and data; SaaS leaves only configuration and data. For any unfamiliar service, ask what the customer patches and what the customer deploys, then assign the model from that answer.
Choosing the deployment model (public, private, hybrid, community) from the technology used rather than from the business, regulatory, and tenancy requirements stated in the scenario, and ignoring explicit constraints such as data residency or a fixed latency budget.
Candidates default to the model they use at work. Exam scenarios often embed a decisive constraint (regulated data must stay in-country, or a legacy system cannot be rehosted) that makes the familiar answer wrong. The distractor option is usually the candidate's own environment.
What to do instead
Underline every stated constraint before reading the options, then eliminate any model that violates one. Rank the remaining options by which requirement they satisfy best, and prefer the answer that addresses the named constraint over the answer that is technically more modern.
Equating cost savings with the lowest monthly infrastructure bill, ignoring migration cost, staff retraining, licensing changes, and the operational cost of re-architecting, so a total-cost-of-ownership item is answered with a raw compute price comparison.
Vendor marketing and price calculators emphasize per-hour rates, and candidates rarely do the multi-year arithmetic under time pressure. Business-value items test whether the candidate can weigh one-time and ongoing costs against elasticity, reduced idle capacity, and avoided capital expenditure.
What to do instead
For any business-case item, enumerate four cost buckets: one-time migration, ongoing run cost, exit or lock-in cost, and people/process change. Then compare on a multi-year basis and state which assumption drives the conclusion. If an option claims savings without addressing utilization or idle capacity, treat it as a distractor.
Treating elasticity and scalability as interchangeable, so a scenario describing automatic scale-in after a traffic spike is answered as 'scalability' and a scenario describing growth in capacity is answered as 'elasticity'.
The terms are used loosely in industry writing, and both involve adding capacity. The exam distinguishes them: scalability is the ability to handle growth, elasticity is the automated, bidirectional matching of resources to demand, including release of capacity. Candidates who never separated the concepts cannot spot the scale-in cue.
What to do instead
Memorize the discriminator: elasticity requires automatic acquisition and release, often in both directions; scalability only requires the capacity to grow. Scan the scenario for words like 'automatically released', 'scale down', or 'matches demand' and map those to elasticity; map 'handles increased load' to scalability.
Designing for high availability by adding redundancy in a single availability zone, or treating backup and disaster recovery as the same control, so an item asking for a recovery objective is answered with a snapshot schedule.
Availability, backup, and disaster recovery are taught together and share vocabulary. Candidates conflate 'we have backups' with 'we can survive a zone or region failure', and they confuse RTO (time to restore) with RPO (tolerable data loss). Multi-zone and multi-region designs also look similar on paper.
What to do instead
Separate the three questions: does the service stay up (availability), can we restore a lost object (backup), and can we resume operations after losing a site (DR)? For any numeric objective, decide first whether it measures elapsed time (RTO) or data loss (RPO), then verify the proposed design actually spans the failure domain named in the scenario.
Applying the shared responsibility model as a fixed split instead of a model that shifts by service type, so the candidate states the provider secures the network in all cases or that the customer is never responsible for physical security.
Candidates learn one memorized sentence ('provider secures the cloud, customer secures what is in the cloud') and apply it unchanged to IaaS, PaaS, and SaaS. In practice the customer's share shrinks as the service model rises, and some controls (identity, data classification, access policy) remain the customer's throughout.
What to do instead
Draw the responsibility line per service model: in IaaS the customer owns guest OS and above; in PaaS the customer owns application, data, and identity configuration; in SaaS the customer owns data, identity, and usage governance. Physical security is always the provider's. Answer by locating the specific control in the scenario on that per-model line.
Confusing identity and access management concepts: treating authentication as authorization, assuming federation means single sign-on without trust configuration, or answering privilege questions with network controls such as security groups.
Identity is the most common place where security and architecture overlap, and the vocabulary is dense (federation, SSO, MFA, role assumption, least privilege). Candidates reach for the control they know best, often a firewall rule, when the item is about who may do what.
What to do instead
Classify the control being asked about: proving identity (authentication), granting permission (authorization), limiting network reachability (segmentation), or protecting data at rest or in transit (encryption). Answer only within the named category. For privilege items, apply least privilege and prefer role-based or attribute-based grants over long-lived credentials.
Treating governance as a purely technical control set, so an item about policy, cost accountability, or service lifecycle is answered with a monitoring tool rather than with the organizational mechanism (policy definition, tagging standard, approval gate, chargeback model).
Candidates with engineering backgrounds equate governance with logging and alerting. Governance items test whether the candidate can distinguish the rule (policy), the evidence (audit and reporting), and the enforcement point (guardrail, approval, budget). A monitoring tool provides evidence but is not the policy itself.
What to do instead
For each governance scenario, identify the three layers: what the rule says, who owns it, and how it is enforced or evidenced. Tagging and cost allocation, service catalog approval, and policy-as-code guardrails are the usual correct mechanisms; monitoring is the evidence layer, not the answer to 'how is this governed'.
Answering service management items with the incident response instinct, so a request for a standard change, a known error, or a service level objective is answered with 'escalate and fix it', collapsing incident, problem, and change management into one behavior.
Under time pressure, all operational scenarios feel like outages. The exam distinguishes the practices: incidents restore service, problems remove root cause, changes control modification risk, and SLAs/SLOs define commitments and targets. Candidates who have not internalized these boundaries pick the most action-oriented option.
What to do instead
Name the practice before reading options: is the scenario about restoring service now (incident), preventing recurrence (problem), approving a modification (change), or measuring against a commitment (service level)? Then choose the option that belongs to that practice. Reject any option that mixes practices, such as permanently changing a system as the immediate incident response.