Operational Excellence Pillar
The ability to support development and run workloads effectively, gain insight into their operations, and continuously improve supporting processes and procedures.
Official Questions
Best Practices
High Risk if Missing
AWS Verbatim
The 4 Golden Signals (Latency, Traffic, Errors, Saturation), distributed tracing with AWS X-Ray, canary deployments with automated rollback alarms, and Amazon COE post-mortems.
In AWS Well-Architected, questions do not have single-choice trick answers. Every listed Best Practice represents an official architectural answer you must incorporate into your workload. When asked these questions in an Amazon System Design interview, your score is evaluated by how many of these best practices you proactively articulate and defend with trade-offs.
Verbatim Questions & Architecture Answers
How do you determine what your priorities are?
Everyone needs to understand their part in enabling business success: priorities come from customer needs, governance, compliance, threats and explicit trade-offs.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Set SLOs from what external customers actually need from the workload.
Account for the needs of internal teams that build on or support the workload.
Know the organizational policies and guidelines the workload must follow.
Know the regulatory and industry rules (for example, data residency) the workload must meet.
Weigh current threats to the business and workload when setting priorities.
Make trade-offs between competing goals explicit, and record the risk you accept.
Priorities tell you where latency matters most, such as the checkout path, and where it can wait.
Spend goes where customer impact is highest.
Written priorities give teams a shared rule for deciding trade-offs.
How do you structure your organization to support your business outcomes?
Clear ownership of every resource, process and operations activity, with agreed responsibilities between teams.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Every resource (account, service, table, pipeline) has a named owning team.
Every runbook and process has a named owner who keeps it current.
Each operations activity (on-call, deploys, patching) has an owner accountable for how it performs.
Ownership is recorded and kept up to date, so it can be looked up during an incident.
Teams have a defined way to request changes, additions or exceptions from the owning team.
Responsibilities between teams are written down, for example as service-level agreements.
Clear owners shorten time to mitigate because the right team is paged first.
Owned resources get cleaned up; orphaned ones keep billing.
Two-pizza teams owning a service end to end keep changes local and fast.
How does your organizational culture support your business outcomes?
Leadership sponsorship, empowered and escalating teams, clear communication, safe experimentation and properly resourced teams.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Leaders set expectations and fund operational work, not just features.
Anyone can stop a deploy or take action when customer outcomes are at risk.
Raising problems early is expected and never punished.
Status updates are timely, clear and say what action is needed.
Teams can safely try new approaches and learn from them.
Engineers get time to build and keep up their skills.
Teams have enough people and tools to run what they own.
Empowered engineers mitigate faster than those waiting for approval.
Under-resourced teams accumulate operational debt that costs more later.
A blameless culture surfaces problems while they are still small.
How do you implement observability in your workload?
Instrument the workload: KPIs, application, user-experience and dependency telemetry, and distributed tracing.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Define the few KPIs that show whether the workload meets its business goals.
Emit metrics, logs and events from the application itself.
Measure what users actually experience, for example with real-user or synthetic monitoring.
Measure the health and latency of every dependency the workload calls.
Propagate a trace ID through every hop so one request can be followed end to end.
Asynchronous telemetry and trace sampling keep instrumentation off the request's critical path.
Retention policies and sampling keep high-volume logs and traces affordable.
Traces let engineers find the failing component in minutes instead of hours.
How do you reduce defects, ease remediation, and improve flow into production?
Version control, testing, configuration and deployment automation, patching, shared standards, multiple environments and small reversible changes.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Keep code, infrastructure and configuration in version control.
Test and validate every change before it reaches production.
Manage configuration through a system, not by hand on servers.
Build and deploy through managed, repeatable pipelines.
Patch operating systems, runtimes and dependencies on a schedule.
Share design standards and reusable components across teams.
Use code review, static analysis and other practices that raise code quality.
Keep separate environments (development, test, production) to catch problems early.
Ship frequent, small changes that are easy to reverse.
Automate integration and deployment end to end.
Automated regression tests catch performance regressions before production.
Fewer defects in production means fewer costly incidents and rollbacks.
Small changes are easier to review, test and roll back.
How do you mitigate deployment risks?
Plan for failed changes, test deployments, use safe deployment strategies, and automate testing and rollback.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Have a tested way back (rollback or roll-forward) before every change.
Test the deployment process itself, not only the code, in a production-like environment.
Use canary, blue/green, one-box or wave deployments to limit how many users a bad change reaches.
Roll back automatically when alarms fire during or after a deployment.
Canaries catch latency regressions on a small slice of traffic first.
Blue/green briefly doubles capacity, which costs money during each deploy.
Automated rollback removes human delay from the worst moments.
How do you know that you are ready to support a workload?
Capable personnel, operational readiness reviews, runbooks, playbooks, informed deploy decisions and support plans.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
The team has the skills and the number of people needed to run the workload.
Run an operational readiness review (ORR) before launch and on a regular schedule.
Write runbooks for routine, well-understood procedures.
Write playbooks for investigating issues whose cause is not yet known.
Decide to deploy based on evidence of readiness, not on the calendar.
Have a support plan (on-call, escalation, vendor support) for every production workload.
Runbooks and playbooks cut time to mitigate during incidents.
An ORR finds gaps before they turn into costly outages.
Documented procedures let new engineers operate the system safely.
How do you utilize workload observability in your organization?
Analyze metrics, logs and traces, create actionable alerts, and build dashboards.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Watch workload metrics against their expected ranges, for example the golden signals.
Search and analyze logs to explain what the metrics show.
Analyze traces to find where time is spent and which dependency fails.
Alert only on conditions a human must act on, and link each alert to a first action.
Build dashboards that show workload health at a glance for each audience.
Alerting on P99 latency catches tail problems that averages hide.
Fewer, actionable alerts reduce on-call load and missed pages.
Shared dashboards give everyone the same picture during an incident.
How do you understand the health of your operations?
Measure operations goals and KPIs, communicate status and trends, and review operations metrics to prioritize improvement.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Track operations KPIs such as time to detect, time to mitigate and deploy frequency.
Share operations status and trends so everyone can see them.
Review operations metrics regularly and act on the worst trends first.
Tracking time to mitigate shows where tooling would speed up response.
Operations metrics show where toil costs the most engineering time.
Trends make slow decay visible before it becomes an outage.
How do you manage workload and operations events?
Processes for events, incidents and problems, a response per alert, business-impact priorities, escalation paths, customer communication and automated responses.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Have a defined process for events, incidents and underlying problems.
Every alert has a documented response and an owner.
Rank events by their impact on customers and the business.
Define who to escalate to, and when.
Plan how and when customers are told about service-impacting events.
Publish event status on dashboards so people don't have to ask.
Automate the response to well-understood events.
Automated responses mitigate known failures in seconds.
Impact-based priorities focus effort where customers are hurt most.
A clear process keeps incidents calm and repeatable.
How do you evolve operations?
Continuous improvement: post-incident analysis (for example Amazon's Correction of Errors), feedback loops, knowledge sharing, validated insights and time set aside for improvements.
Recommended Answers (Official AWS Best Practices Checklist)
Every best practice below is an official answer to incorporate into your system design:
Run a regular, owned process for improving operations.
Analyze every significant incident for root causes and track the fixes to completion.
Feed what you learn from operations back into design and priorities.
Keep operational knowledge current, findable and shared.
Decide what drives improvement work, such as goals, incidents and customer feedback.
Check that an improvement idea is backed by data before investing in it.
Review operations metrics with stakeholders on a schedule.
Write up and share lessons learned across teams.
Reserve engineering time for operational improvements, not only features.
Fixing root causes stops the same incident from recurring.
Removing toil frees engineering time for product work.
Shared lessons prevent other teams from repeating the same mistake.