Cloud+ common mistakes
Cloud+ · Understand the traps and how to avoid them.
Designs for availability by putting several identical instances behind a load balancer inside a single availability zone, then labels the design 'highly available' when the question asks how to survive a zone outage.
The candidate equates 'more copies' with 'fault tolerance' and forgets that redundancy only helps if the copies sit in different failure domains; the words 'multiple instances' and 'load balancer' trigger a familiar pattern match before the failure domain is checked.
What to do instead
Before choosing an option, write down the failure domains named or implied in the stem (process, instance, zone, region, shared dependency such as a single DB or DNS record). Then require that each critical component survive the loss of one zone and that every dependency be replicated or managed multi-AZ. If two instances share a zone or a database, the design is not HA regardless of instance count.
Answers elasticity and capacity questions with the on-premises pattern: a bigger single server, a fixed-size cluster sized for peak, or manual failover - even when the stem describes demand that swings by an order of magnitude or an unpredictable traffic source.
Prior on-premises or homelab experience makes advance capacity purchase and vertically scaled 'pet' servers feel like the default; the candidate does not translate 'elastic' into the operational requirement of automatic scale-in as well as scale-out.
What to do instead
When the stem mentions variable, spiky, or unpredictable load, filter every option through cloud-native patterns: horizontal scaling of stateless instances, autoscaling policies with defined triggers and cool-downs, queue or buffer decoupling, and managed multi-AZ failover. Explicitly ask what happens on scale-in - session handling, connection draining, state externalisation - because options that only describe growth are usually distractors.
Misclassifies deployment strategies: reads 'traffic shifted 10%, then 50%, then 100%' and answers blue/green, or reads two full parallel environments and answers rolling, because both options mention 'zero downtime'.
The strategies are memorised as slogans ('avoid downtime') rather than as distinct mechanics, so any option containing the right-sounding benefit looks correct; candidates also skip the cost and rollback implications that actually distinguish the three.
What to do instead
Build a three-row comparison before answering: rolling = same fleet replaced in batches, no extra capacity, mixed versions during rollout, rollback is a reverse rollout; blue/green = two complete environments, instant switch and instant rollback, roughly double the cost; canary = a small slice of live traffic gated on metrics, then gradual promotion. Match the stem's described traffic percentages and environment count to that table rather than to the benefit wording.
Proposes logging into running instances to patch, hotfix, or hand-edit configuration when the scenario asks how to roll out an OS or configuration change across a fleet, or how to eliminate configuration drift.
In-place administration is the familiar workflow, and the exam's phrase 'immutable infrastructure' is treated as a buzzword rather than as a rule that says a deployed instance is never modified after boot.
What to do instead
Default to replace, do not repair: build a new machine image with the change, deploy new instances, and drain and terminate the old ones. If the stem is about consistency rather than images, answer with declarative infrastructure as code plus drift detection and reconciliation from a single source of truth. Choose any option containing 'SSH in and patch' only if the question is explicitly about an emergency exception process.
Swaps RTO and RPO. A scenario saying 'no more than 15 minutes of data may be lost' is answered by choosing a 15-minute failover time, or a scenario saying 'restore service within one hour' drives the backup frequency answer.
Both targets are expressed in minutes, and in conversation 'recovery time' is used loosely for both; under time pressure the candidate grabs whichever number appears first in the stem and attaches it to the wrong metric.
What to do instead
Before looking at the options, rewrite the requirement in plain words: data lost points to RPO and constrains backup and replication intervals; time down points to RTO and constrains failover automation, warm-standby readiness, and runbook speed. Keep the two rewritten sentences visible while eliminating options, and reject any option that quotes the RPO number as a recovery duration.
Builds monitoring and alerting answers around resource thresholds - 'alert the on-call engineer when CPU exceeds 80%' - when the scenario is about detecting user-visible degradation or reducing alert fatigue.
Threshold alerting is the first thing taught in every tool tutorial, so it feels like the safe answer; the candidate has not internalised that page-worthy alerts should describe user pain, while cause metrics belong on dashboards and tickets.
What to do instead
Separate the two layers explicitly. Page a human on symptoms derived from service-level objectives - error rate, latency, availability, and error-budget burn rate - and route cause metrics (CPU, memory, queue depth, disk) to dashboards and low-priority tickets. Also state the expected action for each alert; an alert with no runbook or owner is a distractor in these questions.
Treats cloud network security controls as interchangeable: adds a deny rule to a security group, describes security groups as stateless, or assumes a subnet-level ACL is sufficient because it is attached to the workload's subnet.
On-premises firewalls really are stateful and support both allow and deny, so the candidate carries that model into cloud controls and never notices the four properties that separate security groups from network ACLs.
What to do instead
Memorise a four-axis table and check the stem against it: stateful (security group) versus stateless (network ACL); allow-only implicit-deny (security group) versus ordered allow and deny rules (network ACL); attached to the instance or elastic network interface versus attached to the subnet; all rules evaluated versus first match wins. A single question usually turns on exactly one of these axes, so identify which one is being tested before choosing.
Answers identity and data-protection requirements with network perimeter controls - proposing a VPN, private link, or bastion host to fix an object store that is publicly readable, or assuming encryption at rest satisfies a requirement about data in transit.
Security is mentally filed as 'networking', and perimeter thinking is the most familiar model; the candidate never classifies the requirement as an identity, network, data, or detective control before scanning options.
What to do instead
Classify the requirement first, then answer in that category. Identity and authorisation questions are fixed by removing public policies, scoping roles and least privilege, and requiring short-lived credentials or signed requests; network questions by segmentation; data questions by encryption in transit (TLS) versus at rest (key management and rotation) - these are separate controls and one never substitutes for the other. Add logging and anomaly detection only when the stem asks for detection rather than prevention.
Uses continuous integration and continuous delivery interchangeably: describes a pipeline that builds and unit-tests on every merge and calls it continuous deployment, or assumes a green build means the artifact is releasable.
The acronyms overlap, and vendor marketing collapses the stages; the candidate answers the pipeline vocabulary question from memory of a tutorial rather than from the gates the stem actually describes.
What to do instead
Hold four distinct definitions and map the stem onto them: CI = build plus automated tests on every commit; continuous delivery = every passing build becomes a deployable, versioned, immutable artifact that is promoted automatically through environments with a human approval before production; continuous deployment = that same flow with the approval gate removed; and rollback = automated redeploy of the previous artifact. If the stem mentions manual approval or a release button, the answer is delivery, not deployment.
Troubleshooting questions are answered by jumping straight to the most recent change or the deepest layer - proposing an application code fix for intermittent 502s without first establishing whether every user is affected, whether it started at a known time, and which tier in the request path is failing.
Under exam time pressure, pattern recognition beats method: the stem mentions a deploy, so the deploy gets blamed; alternatively the candidate diagnoses the layer they know best (usually the app) rather than the layer the evidence points to.
What to do instead
Apply a fixed order every time: state the symptom precisely and its blast radius (all users or one zone, one endpoint or all, constant or intermittent); identify the most recent change and whether the timing correlates; then walk the request path from the edge inward - DNS, load balancer and health checks, application, cache, database, dependencies - eliminating one layer per piece of evidence. Prefer the option that gathers a measurement or isolates a variable over any option that changes several things at once or applies a fix before the faulty layer is confirmed.