Cloud Essentials+ common mistakes
Cloud Essentials+ · Understand the traps and how to avoid them.
Selecting an answer that ignores reversibility and exit planning in adoption questions, for example agreeing to a migration with no data-export format, no notice period and no deletion verification, and calling that 'vendor lock-in avoidance' because the workload is containerised.
Candidates focus on the migration-in phase and on technical portability, while exam items test the contractual and operational exit conditions that determine real portability.
What to do instead
For any adoption or sourcing scenario, check four exit levers: data export format and cost, contractual notice and transition assistance, deletion certification, and skills to run the workload elsewhere. Containerisation helps only the runtime layer; proprietary managed services and egress pricing are where lock-in actually lives.
Ignoring the shared responsibility model when answering security questions, so the candidate says the provider is responsible for data classification, access management or customer application vulnerabilities, or conversely claims the customer must patch the hypervisor.
The model shifts with the service model, and candidates apply one fixed split (often the IaaS split) to PaaS and SaaS scenarios where the boundary has moved upward.
What to do instead
For each scenario, first name the service model, then place the boundary. In all models the customer retains responsibility for data, identity and access decisions, and client-side configuration; the provider covers the physical layer and, increasingly with PaaS and SaaS, the runtime and application stack. Answer from the boundary, not from a memorised slogan.
Confusing identity and access concepts in cloud security items, such as choosing 'authentication' when the question is about what a principal may do, or treating federation and single sign-on as the same control.
IAM vocabulary is dense (authentication vs authorisation, roles vs policies, federation vs SSO vs provisioning) and candidates rely on everyday usage where 'access' covers everything.
What to do instead
Fix the definitions: authentication proves identity, authorisation decides permitted actions, federation trusts an external identity provider, SSO is a user experience built on federation or a shared session, provisioning creates accounts. Read the question for the verb ('prove', 'permit', 'trust', 'create') and match it.
Treating compliance and data-location questions as purely technical, e.g. answering that encrypting data removes the need to consider where it is stored, or assuming a provider's certification automatically makes the customer compliant.
Candidates conflate security controls with legal obligations, and provider compliance pages are written to encourage that reading; the exam tests the distinction between the provider's certification scope and the customer's accountability.
What to do instead
Inspect provider assurance scope, actual duties of each party and relevant technical controls. Outsourcing does not by itself remove the customer’s own obligations. Encryption, key administration, data location, replicas and actual jurisdiction need separate analysis.
Confusing cost-management concepts, such as treating reserved capacity as automatically cheaper in every case, ignoring egress and storage-request charges when comparing options, or assuming that shutting down a virtual machine stops all billing.
Candidates reason from the headline compute price and from on-premises intuition where powering off a server ends its cost, while cloud billing includes attached storage, public IPs, licences and data transfer.
What to do instead
Build a total-cost checklist for every cost question: compute, storage (including snapshots and replicas), data transfer in/out, requests/operations, licences, and support plan. Remember that stopped instances usually still incur storage and reserved IP charges, and that reservations only pay off when utilisation is predictable and high.
Answering availability and continuity items with the wrong mechanism, e.g. offering backups as the answer for a service that must survive a zone failure, or claiming a multi-zone deployment protects against accidental deletion by an administrator.
Backup, replication, high availability and disaster recovery are taught together and candidates do not map each to the failure it addresses (component failure, zone loss, region loss, data corruption or human error).
What to do instead
Learn the mapping: multi-zone/multi-AZ handles infrastructure failure within a region; multi-region handles regional loss; replication keeps a live copy but propagates deletions; backup with versioning and immutability handles corruption and human error. Match the stated failure in the scenario to the mechanism before reading the options.
Treating 'cloud computing' as a synonym for 'virtualisation' or 'hosting', and answering questions about the NIST essential characteristics by picking 'virtualisation' or 'internet access' as the defining feature.
Candidates come from an infrastructure background where VMs and rented servers are the visible part of cloud, so they anchor on the mechanism rather than the service-definition criteria (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service).
What to do instead
Memorise the five NIST essential characteristics and, for each practice question, ask which characteristic is being described before looking at the options. Note that virtualisation is an enabling technology, not a characteristic, and that private networks can still deliver cloud if the five characteristics hold.
Answering elasticity and scalability questions with the wrong term, e.g. describing 'scale up' when the scenario adds more identical instances to handle a traffic spike, or treating 'elastic' as merely 'large'.
The words are used interchangeably in vendor material, and candidates do not separate vertical scaling (more power per node), horizontal scaling (more nodes) and elasticity (automatic, demand-matched provisioning and release).
What to do instead
Distinguish vertical scale up/down from horizontal scale out/in. Elasticity emphasizes adapting provisioned capacity to changing demand, often automatically. Scalability is the ability to accommodate changed demand; billing and minimum commitments remain separate contract questions.
Confusing the three service models by what the provider 'does' rather than by where the management boundary sits, so a question about who patches the guest OS in IaaS gets answered 'the provider' or a question about a managed runtime is labelled IaaS.
Marketing descriptions blur the layers ('fully managed platform', 'serverless containers'), and candidates reason from product names instead of from the responsibility split across application, data, runtime, middleware, OS, virtualisation, servers, storage and network.
What to do instead
Draw the layer stack once from memory and mark the boundary for IaaS (provider: virtualisation, hardware, network; customer: OS upward), PaaS (provider adds OS, runtime, middleware; customer: application and data) and SaaS (provider manages everything; customer manages users and data). Apply the stack to every scenario question before choosing.
Mixing up the four deployment models, for example calling a community cloud 'public' because it is shared, or calling a provider-hosted single-tenant environment 'private' when it is a dedicated public-cloud offering.
The distinction hinges on who the resource pool serves and who controls it, not on physical location or tenancy wording, and exam distractors exploit exactly that ambiguity.
What to do instead
Identify exclusive use, the relevant resource pool, service boundary and actual deployment arrangement. Third-party hosting does not by itself disqualify a private cloud; a dedicated host offering alone also does not establish all private-cloud characteristics.