Systems Manager and event-driven automation: managing resources for SOA-C03

Systems Manager can only operate on instances it can see, and visibility rests on three prerequisites. First, the SSM Agent must be installed and running on the instance — it comes preinstalled on many AWS-provided AMIs, but a custom or minimal image may lack it, and a stopped or crashed agent makes the instance invisible. Second, the instance needs an IAM instance profile that lets the agent talk to the service — the managed policy AmazonSSMManagedInstanceCore is the standard grant. Third, the agent needs a network path to the Systems Manager endpoints (the ssm, ssmmessages, and ec2messages services): the agent makes outbound HTTPS connections, so it needs internet egress through an internet or NAT gateway, or — for private subnets with no internet access — interface VPC endpoints for those services.

The classic exam scenario: an instance does not appear in the managed-instance list, so Run Command, Session Manager, and Patch Manager all ignore it. Diagnose in exactly those three directions. Is the agent installed and running? Restart it and check its logs. Does the instance profile include AmazonSSMManagedInstanceCore? Attaching a role after launch works, but the agent has to pick up the new credentials. Can the instance reach the endpoints? The sneaky variant is an instance in a private subnet with no NAT gateway and no VPC endpoints — the agent simply cannot connect, and the security groups on interface endpoints must also allow inbound HTTPS from the instances. When a question says an instance is missing from Systems Manager, the answer is one of these three; nothing else in the scenario matters.

Session Manager gives you an interactive shell on a managed instance without SSH keys, bastion hosts, or any open inbound ports. The SSM Agent maintains an outbound connection to the service and sessions are brokered over it — so security groups can block all inbound traffic and you still get a shell from the console or CLI. Access is controlled by IAM policies rather than distributed keys, and sessions can be logged to CloudWatch Logs or S3 for a full audit trail of who connected and what they ran. Any scenario asking you to eliminate bastions, stop managing SSH keys, close port 22, or audit interactive access is a Session Manager answer.

Run Command is for commands, not conversations: execute a Systems Manager document — AWS-RunShellScript on Linux, AWS-RunPowerShellScript on Windows — across one instance or thousands, targeting by tags or resource groups instead of maintaining instance lists. Rate controls set how many instances run the command concurrently and how many errors stop the rollout, so one bad command cannot take down a whole fleet at once, and output can be shipped to S3 for review. Run Command is the ad hoc, imperative tool: restart a service everywhere, collect a log file, apply an urgent one-time fix. If the same command needs to run continuously to keep instances in a desired state, that is no longer Run Command's job — that is State Manager, covered below.

Automation runbooks are Systems Manager's multi-step workflows: a runbook defines a sequence of steps that call AWS APIs, run scripts, invoke Run Command on instances, or wait for conditions, with each step's output available to later steps. AWS ships predefined runbooks for common operations — AWS-RestartEC2Instance, AWS-StopEC2Instance, AWS-CreateImage — and you author custom runbooks when the procedure is your own. Runbooks are how you turn a wiki page of manual steps ('snapshot the volume, stop the instance, resize it, start it, verify') into a single executable, repeatable operation that behaves the same at 3am as it does in a change window.

Two features matter at exam depth. Approval steps pause the workflow until designated approvers sign off, so a runbook can automate a risky procedure while keeping a human decision in the loop — automation with a brake. And rate controls let a runbook target many resources with bounded concurrency and error thresholds, the same safety valves Run Command offers.

Runbooks are also the standard target of other automation: a maintenance window can run one on a schedule, and an EventBridge rule can invoke one in response to an event — which is how detection (an alarm, a finding, a state change) becomes remediation without a human in the chain. When a question describes a multi-step operational procedure that should be standardized, repeatable, and optionally gated by an approval, the answer is an Automation runbook.

Patch Manager is the exam's patching answer, and it is worth walking a real campaign end to end. Say you run 200 Linux instances across three environments and must patch on a schedule with evidence for auditors.

First, the patch baseline defines what patched means: which patch classifications and severities are approved, any explicitly approved or rejected patches, and an auto-approval delay — for example, approving security patches several days after release so early regressions surface elsewhere first. AWS provides default baselines per operating system; custom baselines encode your own policy. Instances map to baselines through patch groups, assigned by a tag on the instances.

Second, a maintenance window defines when disruptive work may happen: a schedule, a duration, and a cutoff after which no new tasks start. Register the patch task — the AWS-RunPatchBaseline document — as a window task with rate controls: limited concurrency, and an error threshold that halts a rollout gone bad. AWS-RunPatchBaseline runs in two operations: Scan reports missing patches without changing anything, and Install applies approved patches, rebooting as configured. A common pattern is scanning daily for visibility and installing inside the weekly or monthly window.

Third, compliance reporting closes the loop: Patch Manager records per-instance patch compliance, so you can see which instances are missing which approved patches and export the evidence. Keep the framing operational here — this data answers whether the fleet is patched; wider security posture aggregation is a different domain's concern.

The pattern to lock in: baseline defines what, the patch-group tag defines which instances, the maintenance window defines when, AWS-RunPatchBaseline Scan or Install defines how, and compliance provides the proof.

State Manager is the desired-state half of Systems Manager: an association binds a document to a set of targets on a schedule, and Systems Manager reapplies it continuously — correcting configuration drift rather than merely detecting it. Where Run Command fires once, an association keeps being enforced: keep the CloudWatch agent installed and running on every instance carrying a tag, keep the SSM Agent itself current with AWS-UpdateSSMAgent, keep a required configuration applied to every new instance that matches the target. When a question says configuration must stay enforced — including on instances launched later — the answer is a State Manager association, not a script.

Inventory collects what is actually on the fleet: installed applications and versions, agent versions, OS details, network configuration. Paired with Compliance, which reports association and patch status, it answers what is installed where, and whether it matches policy, without connecting to a single instance.

Parameter Store holds operational configuration in a hierarchical, versioned store: AMI IDs, endpoint URLs, feature flags, and — as SecureString parameters encrypted with KMS — values that should never sit in plain text. Runbooks, Run Command, State Manager documents, and CloudFormation templates can all resolve parameters at execution time, so a value lives in one place and every automation reads the current version. Operationally this is the difference between a hard-coded AMI ID in five scripts and one parameter that your pipeline updates whenever a new golden image ships — every downstream automation follows automatically.

Choosing the right Systems Manager capability is its own exam skill — scenarios are engineered so exactly one fits. The discriminators are cadence (once versus continuous), shape (single command versus multi-step workflow), and domain (general operations versus patching).

Two boundary reminders keep answers clean. Session Manager is interactive access, not automation — it never competes in these questions. And a maintenance window is less a capability of its own than the scheduler that coordinates disruptive work: it can run Run Command tasks and Automation runbooks alike inside an agreed operational window, which is why patching and other risky jobs anchor to it. If a scenario stresses that work must only happen during an approved window, the maintenance window is part of the answer regardless of which capability does the work.

Event-driven automation reacts to what just happened instead of polling for it, and EventBridge is the router. The default event bus receives events from AWS services automatically; a rule matches either an event pattern (react when something happens) or a schedule (run at a cadence), and delivers matches to targets: Lambda functions, Systems Manager Automation runbooks, Run Command, SQS queues, SNS topics, Step Functions state machines. The operational vocabulary is pattern plus target: an EC2 instance changes state → invoke a runbook that tags or remediates it; a Health event lands → notify the on-call topic; a Config compliance change appears → trigger remediation; a GuardDuty finding arrives → invoke a runbook that isolates the instance. In each case the detection plumbing already exists — your job in this task is consuming the event and wiring the response.

S3 Event Notifications are the bucket-level original: object-created and object-removed events delivered to Lambda, SQS, or SNS, with prefix and suffix filters (only a given folder, only .csv keys). For richer filtering and a wider target list, enable EventBridge on the bucket and write EventBridge rules against S3 events instead — the better fit when multiple consumers or complex matching are involved.

Lambda is the glue for logic AWS does not ship: parse the event, decide, call APIs. For multi-step flows with branching and retries beyond one function, Step Functions orchestrates — know it at mention level here.

AWS DevOps Agent

The exam guide names AWS DevOps Agent — newly in scope for SOA-C03 — as an example service for event-driven automation and automated remediation, alongside Lambda and EventBridge. Know it at exactly that level: an agentic AI tool AWS positions for operational automation, recognizable as a plausible option in a question. The guide does not go deeper, so do not memorize feature details.

End-to-end automation chains these pieces, and the exam rewards recognizing whole patterns. Scheduled stop/start for cost: an EventBridge schedule rule invokes AWS-StopEC2Instance against tagged development instances every evening and AWS-StartEC2Instance every morning — no custom code, because predefined runbooks already do the work. A patching campaign is baselines, patch-group tags, a maintenance window, and compliance reporting, as walked through above. An AMI refresh chain keeps golden images current: a scheduled rebuild produces a new AMI, the new AMI ID lands in a Parameter Store parameter, and downstream launch templates and automations read that parameter — the running fleet then picks it up through its normal rollout mechanism.

When several answers would technically work, apply the selection rule the exam repeats across services: prefer managed and declarative over custom code. If a predefined runbook, a State Manager association, or Patch Manager covers the requirement, choosing Lambda means writing, patching, and monitoring code for an already-solved problem — the phrase 'least operational overhead' points at the managed option. Choose Lambda when the logic is genuinely custom: parse this event, apply business rules, call several APIs in a particular order. Choose a runbook when the procedure is multi-step and operational, especially when it needs an approval gate. Choose State Manager when the requirement is a state to maintain rather than an action to perform. Read the verbs in the question — run once, keep enforced, on a schedule, when X happens — and each maps to a different tool you now know.