Deployment, Provisioning, and Automation
Systems Manager Operations and Event-Driven Resource Automation
CoreOperate existing fleets with the correct Systems Manager surface and build event-driven actions that are scoped, retry-safe, observable, and verifiable.
Aligned to AWS Certified CloudOps Engineer - Associate (SOA-C03) Version 1.1, verified August 24, 2026.
Why this matters
Run Command, State Manager, Automation, patching, inventory, EventBridge, S3 notifications, and Lambda are neighboring tools with different state, timing, and delivery contracts.
Must Know
- Run Command performs bounded commands on managed nodes; State Manager associations maintain desired configuration; Automation coordinates multi-step operations; patch policies and maintenance windows govern patch execution and compliance.
- Systems Manager managed nodes need the agent or supported management path, an authorized instance or hybrid role, and endpoint connectivity; inbound SSH or RDP is not inherently required.
- Target fleets by tags or resource groups and set concurrency and error thresholds so one bad action cannot affect the entire fleet.
- EventBridge rules and S3 Event Notifications need matching or filtering, target permissions, execution-role permissions, retry handling, and observable terminal failure.
- Event delivery can repeat. Use a stable idempotency key or recorded state and a conditional action so retries do not duplicate side effects.
- For cross-account automation, authorize the event path and assume a scoped target-account role; Organization membership or an SCP does not grant execution permission.
Compare and Distinguish
- Run Command is immediate command execution; State Manager is recurring desired-state enforcement; Automation is an ordered workflow.
- Image Builder updates a new baseline; Patch Manager maintains an existing fleet.
- EventBridge routes many AWS and custom events; S3 notifications originate selected object events directly.
- A retry policy governs delivery attempts; idempotency governs repeated side effects.
Scenario examples
- Scenario: Run one diagnostic command across tagged managed instances with limited concurrency and captured output instead of opening inbound administration ports.
- Scenario: A result written to S3 triggers the same notification prefix. Separate input and output prefixes or buckets and make processing idempotent.
- Scenario: A central event triggers a member-account runbook. Route the event with policy, assume a narrow role in the member, and return execution evidence.
Exam traps
- Do not use one-time Run Command as continuous configuration enforcement.
- Do not assume event delivery is exactly once.
- Do not let an S3 processor write into its own unfiltered trigger path.
- Do not grant AWS DevOps Agent broad authority merely because its finding is relevant.
Key takeaways
- Choose the Systems Manager capability from timing and workflow state.
- Bound fleet operations with target, concurrency, and error controls.
- Design every event action for retries and terminal failure.
- Verify the resource postcondition independently.
How it works
- Confirm that each target is a managed node and resolves to the intended tag and account scope.
- Select the command, association, runbook, patch policy, or event target that matches the required lifecycle.
- Capture output and terminal failure evidence, then verify the resource state independently of delivery status.
When to use it
- Run Command fits immediate command execution, State Manager fits recurring desired-state enforcement, and Automation fits an ordered multi-step workflow.
- Create a new patched baseline with EC2 Image Builder; use Patch Manager to maintain the operating-system patch state of an existing fleet.
- Choose EventBridge when many AWS or custom event sources need routing; use S3 Event Notifications when selected object events should originate directly from an S3 bucket.
- Configure the retry policy to control delivery attempts, and implement idempotency to prevent repeated deliveries from duplicating side effects.
Security and governance implications
- Limit command and Automation roles to the targeted nodes and actions, especially across account boundaries.
- Store command output and event records with access controls appropriate to the operational data they contain.
Failure signals and diagnosis
- For unmanaged nodes, inspect agent state, role registration, endpoint path, time, and service status.
- For missing events, inspect source emission, filters, destination policy, invocation permission, and target logs.
- For repeated effects, correlate event IDs and conditional state before changing retry behavior.
More detail
- Verify the agent or supported management path, instance or hybrid role, and endpoint connectivity before calling a node unmanaged.
- Use tags or resource groups plus concurrency and error thresholds to bound fleet operations.
- For event-driven and cross-account work, separate source filtering, target permission, assumed role, retries, and execution evidence.
Ready for the quiz?
- A Systems Manager command never reaches a tagged EC2 instance. Which checks determine whether the node is unmanaged, incorrectly targeted, or unable to reach Systems Manager?
- How should an event-driven action handle duplicate delivery and expose retries that end in terminal failure?
- Which timing and state requirement separates Run Command, State Manager, Automation, and patch policies for the same fleet?
Related objectives
- D3.2 — Task 3.2: Automate the management of existing resources.
- 3.2.1 — Use AWS services to automate operational processes (for example, Systems Manager).
- 3.2.2 — Implement event-driven automation by using AWS services and features (for example, Lambda, S3 Event Notifications, EventBridge, AWS DevOps Agent).