Commitments, Spot and the Order You Optimize In
Cost optimization has a sequence, and doing it out of order wastes money. You turn off what nobody uses, right size what is left, move interruptible work to Spot, and only then commit to the steady baseline that remains, because committing first locks in whatever waste was already there. The exam expects you to know which purchasing model fits which shape of workload and what flexibility each one gives up.
Exam tip. If a scenario says the team is unsure which instance families they will use next year but the total spend is steady, that is a Compute Savings Plan. If it says the fleet is fixed and understood, the deeper EC2 Instance plan or a reservation is the better answer.
S3 Cost Optimization and the Storage Class Ladder
S3 bills for storage, for requests and for retrieval, and the cheap classes shift cost from the first of those to the last two. That means the right class depends entirely on how often the data is read, and when nobody can tell you that with confidence, Intelligent Tiering is the honest answer because it measures rather than guesses. Minimum duration charges are the trap that makes an aggressive lifecycle rule cost more than doing nothing.
Exam tip. The phrase access patterns are unknown or unpredictable is the giveaway for Intelligent Tiering. A lifecycle policy is the intended answer only when the scenario tells you how old the data is when it goes cold.
Observability Beyond Basic Metrics
Default CloudWatch metrics tell you that something is wrong and almost never tell you what. Improving an existing system usually means adding the three things the default view lacks: metrics from inside the guest, traces that follow a request across services, and log analysis that identifies which customer or resource is responsible. The exam frames this as choosing the right observability tool for a specific diagnostic question.
Exam tip. Match the tool to the question being asked. Where did the latency come from is X-Ray, which tenant is causing this is Contributor Insights, and is memory the problem is the CloudWatch agent. The wrong answers are usually correct tools for a different question.
Improving the Reliability of a System Already in Production
Improving reliability on a running system is different from designing it, because you cannot stop the world to rebuild. The work is a sequence of targeted changes: remove the single points of failure, make retries safe, degrade rather than fail outright, and then prove the improvements with deliberate failure testing. The exam scenarios usually describe an outage that already happened and ask what stops it happening again.
Exam tip. When a scenario describes a failure that cascaded across the system, look for answers that add isolation: bulkheads, queues, timeouts and circuit breakers. Adding more capacity usually just moves the failure a little further out.
Caching at Every Layer
Most performance improvements on an existing system come from not doing the work twice, which means caching, and caching exists at every layer from the browser to the database. Each layer has its own invalidation problem, and choosing where to cache is really choosing whose staleness you can tolerate. The exam expects you to place the cache as close to the user as the freshness requirement allows.
Exam tip. If the scenario says the same content is requested by many users worldwide, the answer sits at CloudFront. If it says the same query hits the database repeatedly, the answer is ElastiCache or DAX. Adding read replicas is the plausible looking distractor.
Safer Deployments and Faster Rollback
Improving an existing system usually means shipping changes to it more often, and that only stays safe if a bad release can be withdrawn faster than it can do damage. The deployment strategies differ mainly in how many users see a broken version before you notice, and in how expensive it is to keep the previous version alive. Automated rollback tied to a real alarm is what turns any of them from a plan into a control.
Exam tip. When a scenario demands both zero downtime and immediate rollback, blue green is the answer. When it demands that only a limited number of users can ever see a defect, canary is the answer. The two requirements are not the same thing.
Detecting and Correcting Configuration Drift
Any environment that people can log into will drift away from what was designed, usually through small emergency changes nobody wrote down. AWS Config is the mechanism that notices, and Systems Manager Automation is the mechanism that fixes it, and neither is useful without the other. Doing this organization wide is what separates a professional answer from an account level one.
Exam tip. Read the requirement carefully. Must be corrected within a set time points to Config with automatic remediation. Must never happen points to a preventive control such as an SCP, and an answer offering only detection will be wrong.
Running the Fleet with Systems Manager
Systems Manager is the service that quietly answers a whole category of operational questions: patching without inbound ports, remote access without bastion hosts, configuration without hand written scripts, and inventory without a spreadsheet. It works through an agent making outbound calls, which is why it also works for on premises servers during a migration. Exam scenarios often present a manual operational burden and expect you to recognise the managed replacement.
Exam tip. Any scenario mentioning bastion hosts, SSH key distribution or opening port 22 for administration is pointing at Session Manager. Any scenario about patching servers without inbound access is pointing at Patch Manager.
Reviewing an Existing Architecture and Prioritising the Work
Continuous improvement questions often hand you a working but flawed system and ask what to do first. The Well Architected Framework gives you the vocabulary for that review, Trusted Advisor gives you the automated findings, and the prioritisation comes from risk multiplied by effort rather than from whichever pillar you enjoy most. The exam rewards answers that address the highest risk with the smallest safe change.
Exam tip. When asked what to do first, look for the option that reduces the largest risk with the least disruption. Sweeping rewrites are almost never the first step, and answers that improve monitoring alone do not fix a stated reliability gap.