Lesson 418 · AWS Learning Path

AWS 418: Resilience, monitoring, and incident response

Anil Jalela · Published Aug 17, 2026 · 4 min read

Purpose and exam boundary

This checkpoint assesses DOP-C02 Domain 3 Resilient Cloud Solutions, Domain 4 Monitoring and Logging, and Domain 5 Incident and Event Response. The guide weights them at 15, 15 and 14 percent of scored content. You must connect architecture, telemetry and operations rather than answering each domain in isolation.

Scenario packet

A two-Region order service uses Route 53, ALB/Auto Scaling, ECS, SQS and Aurora. Its stated RTO is 30 minutes and RPO five minutes, but backups are untested, failover depends on one operator, dashboards show infrastructure rather than checkout outcomes, alarms page multiple teams, and the last incident closed when instances became healthy while orders remained delayed.

Assessment tasks

1. Decompose user journeys and dependencies. Define availability, latency, correctness and freshness SLIs with exact good/total events.
2. Calculate a 30-day SLO/error budget and burn for three incidents. Decide when releases stop or continue and justify exclusions.
3. Build an observability plan across metrics, structured logs, traces, deployment/configuration and CloudTrail, with identity, retention and cost controls.
4. Design symptom-first alarms, composite/no-data behavior, severity, owner, runbook, deduplication, acknowledgement and escalation.
5. Select multi-AZ, backup/restore, pilot-light, warm-standby or active-active patterns by measured RTO/RPO, consistency and cost.
6. Write recovery order for identity/network, data, queues, compute, traffic and verification. Handle writes during failover and failback.
7. Design an EventBridge/SQS/Step Functions/SSM response that is idempotent, bounded, authorized, observable and reversible.
8. Use Health, deployment, Config, CloudTrail, metrics/logs/traces to evaluate five competing incident hypotheses.
9. Produce customer/internal communications using confirmed scope, impact, mitigation, risk and next-update time.
10. Write a post-incident review with trigger, contributors, failed controls and tested corrective actions, not blame.

Quantitative section

Compute observed RPO from last durable replicated/backup recovery point, RTO from declaration to verified customer service, detection/acknowledgement/containment/recovery/verification intervals, queue drain time at changing arrival/service rates, required healthy capacity after one AZ loss, log/cardinality volume and alarm burn rates. Show units and sensitivity.

A design fails even with correct arithmetic if it assumes unavailable control planes, shared credentials, correlated Regions, infinite quota, instant DNS/cache/session convergence or zero data reconciliation. State what was measured versus estimated.

Evidence-led incidents

Diagnose eight supplied cases: ALB 5xx after deployment, queue age with healthy consumers, missing spans at asynchronous boundary, log delivery throttling/DLQ growth, AWS Health maintenance with paginated resources, Region evacuation with stale replica, automated repair repeated by duplicate event and recovery that restores HTTP success but not order correctness.

For each provide impact, severity, evidence timeline, supported/contradicted hypotheses, containment and reversal, remediation, user/security/data verification, communication and prevention. Missing telemetry is a finding, not proof that nothing happened.

Resilience and operations decisions

Write six ADRs covering Regional recovery pattern, data protection/failover, telemetry routing/retention, alert ownership, remediation automation and incident command. Compare at least two viable alternatives and include steady-state capacity, degraded behavior, dependencies, security, cost, game-day proof and exit/reversal.

Design a game day for Region impairment plus identity-provider outage. State hypothesis, exact blast radius, fault method, observers, stop conditions independent of the fault, abort authority, communications, recovery and evidence. The test must not claim production resilience from a tabletop alone.

For every recommendation, provide a cross-domain proof chain: the architecture behavior expected during failure, the telemetry that detects and distinguishes it, the authorized operational action, the customer/data/security verification and the retained learning evidence. Reject designs whose recovery depends on the same Region, identity provider, queue, key, dashboard or human that the scenario removes. Also identify which assumptions require a game day, restore test, load test or live canary rather than document review.

Scoring and remediation

Pass at 80/100, no automatic failure and at least 60 percent per area. Remediation requires reviewing the mapped lesson, correcting the model, solving a changed scenario and supplying stronger evidence. A multiple-choice score alone cannot pass this practical checkpoint.

Submission acceptance

Submit service/telemetry diagrams, SLI/SLO math, ten task answers, capacity/recovery calculations, eight incident reports, six ADRs, game-day charter, communications, post-incident review and personal remediation map. Acceptance requires measured recovery, customer-level verification, evidence-led diagnosis, safe automation and owned learning actions.

Official sources

• DOP-C02 exam guide
• Domain 3: Resilient Cloud Solutions
• Domain 4: Monitoring and Logging
• Domain 5: Incident and Event Response
• Reliability pillar
• Operational Excellence pillar