A watch that only pages a human is half a system. The other half decides what the machine may fix without one.
Both AWS professional exams circle one competence from opposite sides. The Solutions Architect Professional asks what a resilient system looks like at rest: how it is shaped so failure is contained. The DevOps Professional asks what a resilient system does in motion: how it notices trouble and acts on it without a human in the middle of every fix. The meeting point is a loop. Detect a bad state, decide whether a machine or a human owns the response, and act. Today's lesson builds that loop out of three AWS services and one hard question about authority.
The trio this lesson belongs to spent the morning on the same shape at chain scale: a watch that reads divergence across many nodes and a signal that wakes a human when the safe move is to stop. AWS gives the cloud-operations version of the same idea, and the exams reward the operator who knows exactly which failures a machine may fix alone and which it may only report.
Three services carry the loop, one per stage. CloudWatch detects state that has crossed a threshold. AWS Config detects drift, the slower failure where a resource's configuration has moved away from the shape policy requires. Systems Manager Automation acts, running a documented runbook against the offending resource. EventBridge wires them together, routing an alarm or a Config finding to the automation that answers it.
The precondition under all three is telemetry. Kim and co-authors put it plainly in The DevOps Handbook (Part IV, p. 300): you cannot automate a response to a condition you cannot measure. Every automated fix begins as a measured signal, and a fix wired to a signal you do not trust is worse than no fix, because it acts with confidence on a false reading. The SRE treatment of toil (Beyer et al., Part III, p. 134) supplies the other half of the case: repetitive manual remediation is the work most worth automating, precisely because a human doing it by hand is slow, error-prone, and expensive at three in the morning.
The Solutions Architect exam frames remediation through AWS Config. A Config rule expresses a desired configuration: an S3 bucket must block public access, a security group must not open port 22 to the world, an EBS volume must be encrypted. Config continuously evaluates resources against the rule and marks each compliant or non-compliant. Non-compliance is drift, and drift is a state that arrived quietly, usually through a manual change that skipped the pipeline.
Config supports remediation actions directly, binding a non-compliant finding to a Systems Manager Automation document that corrects it. A bucket that drifts to public gets its public-access block re-applied. A security group that opens SSH to the world gets the rule revoked. The architect's judgment is which rules carry automatic remediation and which only flag for review. Re-encrypting a volume is safe and mechanical. Deleting an over-permissive IAM policy might break a production workload that quietly depended on it, so that one flags and waits.
At organization scale, Config aggregators and conformance packs turn this from a per-account chore into a governance surface. A conformance pack is a versioned collection of rules and remediations deployed across every account through the organization, so drift is detected and corrected the same way everywhere. This is the SAP-flavored answer to the detect-decide-act loop: the desired shape is declared once as policy, and the platform holds every account to it.
The DevOps exam frames the same loop through CloudWatch and the event path. A CloudWatch alarm watches a metric against a threshold across a number of periods, moving between OK, ALARM, and INSUFFICIENT_DATA. The three-state model matters for the exam: INSUFFICIENT_DATA is not OK, and treating missing telemetry as health is the classic mistake, the cloud version of trusting a node that has stopped reporting.
An alarm's response is where DOP depth lives. The simple path notifies through SNS. The operational path routes the alarm through EventBridge to a Systems Manager Automation document that runs the fix: restart the stuck agent, replace the unhealthy instance, roll back the deployment that spiked the error rate. The SRE health-check-and-failover discipline (Beyer et al., Part III, p. 315) is the model. A health check that only lights a dashboard red is diagnostic. A health check wired to an automated failover is operational, and the difference is whether recovery waits on a human noticing.
DOP also owns the guardrails that keep automation from becoming its own incident. An automated rollback needs a circuit breaker so a flapping metric does not trigger an endless deploy-rollback cycle. A remediation that replaces instances needs a rate limit so a region-wide metric blip does not cycle the whole fleet at once. The exam rewards the candidate who pairs every automated action with the limit that stops it from over-firing, the same instinct the fork detector showed when it refused to act on a tie and woke a human instead.
A payments service runs behind an Auto Scaling group. Two failures need answering, and they sit on opposite sides of the authority boundary.
First failure: an instance fails its ELB health check. This is frequent, well-understood, and safe to fix mechanically. Auto Scaling already owns the response, terminating the unhealthy instance and launching a replacement, no human required. A CloudWatch alarm on the group's healthy-host count still fires, but only to notify, because the machine has authority here and is already acting. This is the 2026-06-16 elasticity lesson's mechanism, seen now as one instance of the broader loop.
Second failure: AWS Config reports that the payments bucket has drifted to allow public reads. This is a security-critical state that must be corrected in seconds, and the correction is mechanical and safe: re-apply the public-access block. Config binds the finding to an SSM Automation document that does exactly that, and the whole cycle from drift to correction runs without a page. But the same event also writes to CloudTrail Lake, the 2026-06-23 lesson's audit surface, because a mechanical fix must still leave a record of who changed the bucket and when the platform reverted it. The machine may fix the drift. It may not erase the evidence.
Third state, and the one the machine does not own: the payments error rate crosses a threshold with no matching deploy and no obvious cause. This is ambiguous. An automated rollback would act on a cause it has not identified. So the alarm routes through EventBridge to a Step Functions workflow, the 2026-06-30 lesson's sequencing engine, which gathers diagnostics and pages on-call with them attached. The machine detects and decides that this one is a human's. It acts by preparing the human's decision, not by making it.
The chain fork detector and the AWS remediation loop are the same architecture in two clouds. Both read a signal that separates a benign state from a dangerous one: lag from fork on the chain, INSUFFICIENT_DATA from ALARM in CloudWatch. Both draw an authority boundary the same way: the machine handles the frequent and safe cases, the human handles the rare and ambiguous ones. And both refuse to act on a tie. The Python quorum reducer flags a fifty-fifty split rather than naming a winner; the AWS loop pages a human on the unexplained error spike rather than rolling back on a guess. Detect, decide who owns it, act within authority. One discipline, three surfaces.
Learn the three services as one loop, not three features. CloudWatch and Config detect, on the fast metric axis and the slow configuration axis. EventBridge routes. Systems Manager Automation acts, running the documented fix. The exam questions that separate the passing candidate from the rest are never about a single service's syntax. They are about the authority boundary: given this failure, may a machine fix it alone, must it fix it and log it, or must it only prepare the human's decision. Answer that correctly and the service choices follow.
Take one recurring alarm in your own account and ask the three questions of it: is this frequent, is the fix well-understood, is it safe to do mechanically. Three yeses earn an SSM Automation document. One no earns a page. Draw that boundary once per failure, and the loop builds itself.