ExamFinch.com My Study

Study guide

6.2 Systems Manager Run Command, State Manager & Associations

Practice this exam

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

6.2 Systems Manager Run Command, State Manager & Associations

Key Takeaways Explain This Topic AI

SSM Run Command executes ad-hoc commands and scripts across fleets of EC2 and hybrid instances without requiring SSH/RDP, governed by fine-grained IAM controls and EventBridge lifecycle notifications.

Deterministic blast-radius management in Run Command is achieved using maxConcurrency and maxErrors, specified as absolute counts or percentages to halt execution upon failure thresholds.

The GetCommandInvocation API and AWS Console truncate command output to 2,500 characters; persistent streaming to Amazon S3 and CloudWatch Logs is mandatory for comprehensive log capture.

Systems Manager State Manager enforces declarative desired state configuration across fleets via recurring Associations (cron/rate), tracking compliance and automatically remediating drift.

SSM Automation Documents orchestrate complex multi-step cloud workflows using action plugins (aws:executeScript, aws:runInstances, aws:invokeLambdaFunction, aws:branch) with explicit error handling and automated rollback steps.

Last updated: September 2026

Systems Manager Run Command: Fleet-Wide Execution at Scale

AWS Systems Manager Run Command enables administrators and automated CI/CD pipelines to execute commands, shell scripts, and configuration bundles across thousands of managed instances simultaneously. Because Run Command leverages the outbound SSM Agent communication channel, operators can administer fleets without opening inbound management ports, managing SSH bastion keys, or orchestrating complex VPN topologies.

Standard Command Documents

Run Command operations are defined by SSM Command Documents (JSON or YAML manifests) that specify the execution plugins, parameters, and operating system targets:

AWS-RunShellScript : Executes Linux, macOS, or Unix shell scripts ( /bin/sh or /bin/bash ). Commands execute under the local root account (or ssm-user if configured).

AWS-RunPowerShellScript : Executes Windows PowerShell scripts and cmdlets on Windows Server instances under the NT AUTHORITY\SYSTEM context.

AWS-RunRemoteScript : Downloads a script from an Amazon S3 bucket or public/private GitHub/CodeCommit repository and executes it locally on the managed node.

AWS-ConfigureAWSPackage : Installs, uninstalls, or updates AWS-curated or custom software packages (such as the unified Amazon CloudWatch Agent or AWS CLI) across targeted instances.

Fleet Targeting Strategies

Run Command allows flexible target specification to prevent operational drift and ensure precise command delivery:

Explicit Instance IDs : Targeting specific instances (e.g., i-0123456789abcdef0 , mi-0123456789abcdef0 ). Suitable for emergency break-glass triage on individual hosts.

Tag-Based Targeting : Selecting nodes dynamically using resource tag keys and values (e.g., tag:Environment=Production AND tag:Role=WebServer ). Newly launched Auto Scaling instances matching the tag criteria automatically become eligible for subsequent invocations.

Resource Groups : Targeting AWS Resource Groups that aggregate diverse resources across tags and CloudFormation stacks.

Concurrency and Blast Radius Management: maxConcurrency & maxErrors

When deploying updates or executing disruptive commands across large production fleets, cascading failures can cause catastrophic outages. Run Command provides built-in rate control via two critical parameters:

maxConcurrency : The maximum number or percentage of managed instances that can execute the command simultaneously. For example, setting maxConcurrency: 10 limits parallel execution to 10 instances; setting maxConcurrency: 20% on a 50-instance fleet processes instances in batches of 10.

maxErrors : The maximum number or percentage of instance execution failures permitted before AWS Systems Manager immediately halts the command execution across the rest of the fleet. For example, setting maxErrors: 0 ensures that if a single instance returns a non-zero exit code, the command is aborted immediately for all remaining un-executed targets. [ Fleet of 100 Managed Instances ]

  • │
  • ├─ Batch 1: 20 Instances (maxConcurrency: 20%)
  • │ ├── 19 Succeeded
  • │ └── 1 Failed! ──> Evaluates against maxErrors (0% / 0 count)
  • ▼
  • [ Circuit Breaker Tripped! ]
  • │
  • └─ Status transitions to FAILED
  • Remaining 80 instances are CANCELLED without running the command
  • Command Output Capture & The 2,500 Character Truncation Limit

Important

DOP-C02 Exam Trap : The Systems Manager API calls ( GetCommandInvocation and ListCommandInvocations ) and the AWS Management Console truncate stdout and stderr output to the first 2,500 characters ! If a script outputs a stack trace, verbose installation log, or compilation result that exceeds 2,500 characters, the trailing output is permanently lost unless external logging is configured.

To preserve comprehensive execution transcripts:

Configure OutputS3BucketName and OutputS3KeyPrefix : Systems Manager streams full stdout and stderr logs as discrete text files directly to the designated S3 bucket.

Configure CloudWatchOutputConfig : Systems Manager streams command logs into an Amazon CloudWatch Logs log group, allowing real-time log analysis and subscription filtering.

Use Amazon EventBridge : Systems Manager emits status events on command state changes ( InProgress , Success , Failed , TimedOut , Cancelled ), enabling automated event-driven alerting or automated rollback pipelines.

Loading diagram... Run Command Execution Flow & State Manager Reconciliation

Systems Manager State Manager: Continuous Desired State Configuration

While Run Command is designed for imperative, ad-hoc execution, Systems Manager State Manager provides declarative, continuous configuration management. State Manager ensures that your target fleet conforms to a defined "desired state" and continuously monitors and remediates configuration drift .

The State Manager Association

A State Manager Association is the foundational binding between a configuration document, a set of target instances, parameters, and an execution schedule:

Association Document : The SSM Document (command or automation) specifying the configuration steps. Examples include updating the SSM Agent ( AWS-UpdateSSMAgent ), executing an Ansible Playbook ( AWS-ApplyAnsiblePlaybooks ), or enforcing security benchmark settings.

Targeting : Defines which instances the association applies to. Targets can be dynamic (using tag queries such as tag:OS=Linux ), explicit instance IDs, or account-wide ( * ).

Schedule : Associations run on a recurring schedule defined by a cron expression (e.g., cron(0 0 ? * SUN *) for every Sunday at midnight) or a rate expression (e.g., rate(30 minutes) ).

Compliance Status : Every time an association executes, State Manager evaluates the execution outcome and assigns a compliance status: Compliant or Non-Compliant . This compliance state is published to the Systems Manager Compliance dashboard and emitted to AWS Config.

Third-Party Framework Integration: Ansible, Chef, and PowerShell DSC

State Manager eliminates the traditional operational burden of maintaining separate, long-running configuration management master servers (such as Ansible Tower/AWX, Chef Infra Server, or Puppet Master):

AWS-ApplyAnsiblePlaybooks : An AWS-managed SSM document that downloads an Ansible playbook directly from Amazon S3, GitHub, or AWS CodeCommit, installs the Ansible engine locally if not present, and executes ansible-playbook against localhost .

AWS-ApplyChefRecipes : Downloads Chef cookbooks and executes Chef Solo locally.

AWS-InstallPowerShellModule : Installs PowerShell Desired State Configuration (DSC) resources and compiles configurations locally.

This "masterless" architecture allows infrastructure teams to store declarative playbooks in Git, update the S3 source bucket via CI/CD pipelines, and let State Manager automatically enforce the playbook across thousands of instances without SSH access.

SSM Automation Documents: Multi-Step Operational Workflows

SSM Automation Documents (defined under schemaVersion: '0.3' ) orchestrate complex, multi-step cloud workflows that span multiple AWS services, managed nodes, and third-party systems. Automation documents are frequently used for automated golden AMI baking, disaster recovery failover, forensic isolation of compromised EC2 instances, and automated patch remediation.

Core Automation Action Plugins

Action Plugin Functional Description Common Use Case

aws:executeScript Executes inline Python (Python 3.10+) or PowerShell script code with context objects and parameter bindings. Querying AWS APIs via boto3 , parsing dynamic payloads, evaluating custom algorithms.

aws:runInstances Launches new EC2 instances with designated AMIs, instance types, and user data. Creating temporary build instances for AMI baking pipelines.

aws:stopInstances / aws:terminateInstances Stops or terminates EC2 instances. Shutting down temporary builder nodes or isolating compromised servers.

aws:createImage Creates an Amazon Machine Image (AMI) from a target EC2 instance. Automated snapshotting and image baking workflows.

aws:invokeLambdaFunction Invokes an AWS Lambda function synchronously or asynchronously. Dispatches alerts to Slack/PagerDuty, integrates with Jira/ServiceNow ITSM systems.

aws:executeAutomation Invokes a secondary (child) SSM Automation document. Modular workflow composition and reusable sub-routines.

aws:runCommand Dispatches a Run Command execution across targeted instances within the workflow. Running post-boot validation scripts on newly launched instances.

aws:branch Evaluates conditional logic (StringEquals, BooleanEquals, etc.) to choose the next execution step. Dynamic decision-making based on prior step outputs.

aws:approve Pauses workflow execution until designated IAM users/roles approve or reject the action. Enforcing manual approval gates before applying production changes.

Error Handling, Rollback Steps, and Branching

Enterprise automation requires deterministic failure recovery. In an SSM Automation document, each step can explicitly define failure behavior:

onFailure : Defines what occurs when the step fails. Options include:

Abort (default): Immediately stops workflow execution and marks the execution as Failed .

Continue : Ignores the error and proceeds to the next sequential step.

step:<step_name> : Immediately diverts execution to a dedicated recovery, cleanup, or rollback step .

isEnd: true : Marks the step as the terminal step of the workflow upon successful completion.

maxAttempts : Configures automatic retries for transient API rate-limiting or network issues.

Production Automation Document Example

The following document illustrates dynamic branching, inline Python scripting, step retries, and automated rollback upon validation failure: description: "Automated EC2 Maintenance and Health Verification with Rollback"

  • schemaVersion: '0.3'
  • assumeRole: "arn:aws:iam::123456789012:role/SSMAutomationExecutionRole"

parameters:

InstanceId:

  • type: String
  • description: "Target EC2 Instance ID"

mainSteps:

  • name: InspectInstanceHealth
  • action: aws:executeScript

inputs:

  • Runtime: python3.10
  • Handler: check_health

InputPayload:

  • instance_id: "{{ InstanceId }}"
  • Script: |
  • import boto3

def check_health(events, context):

  • ec2 = boto3.client('ec2')
  • resp = ec2.describe_instance_status(InstanceIds=[events['instance_id']])
  • status = resp['InstanceStatuses'][0]['SystemStatus']['Status'] if resp['InstanceStatuses'] else 'impaired'
  • return {'status': status}

outputs:

  • Name: SystemStatus
  • Selector: $.Payload.status
  • Type: String
  • name: EvaluateBranch
  • action: aws:branch

inputs:

Choices:

  • NextStep: ExecutePackageUpgrade
  • Variable: "{{ InspectInstanceHealth.SystemStatus }}"
  • StringEquals: ok
  • Default: TerminateWithRollback
  • name: ExecutePackageUpgrade
  • action: aws:runCommand
  • onFailure: step:RollbackPackageUpgrade

inputs:

DocumentName: AWS-RunShellScript

InstanceIds:

- "{{ InstanceId }}"

Parameters:

commands:

  • "yum update -y security"
  • "systemctl restart my-critical-service"
  • name: VerifyServiceHealth
  • action: aws:runCommand
  • onFailure: step:RollbackPackageUpgrade

inputs:

DocumentName: AWS-RunShellScript

InstanceIds:

- "{{ InstanceId }}"

Parameters:

commands:

  • "curl -f http://localhost:8080/health || exit 1"
  • isEnd: true
  • name: RollbackPackageUpgrade
  • action: aws:runCommand

inputs:

DocumentName: AWS-RunShellScript

InstanceIds:

- "{{ InstanceId }}"

Parameters:

commands:

  • "echo 'Rolling back package upgrades...'"
  • "yum history undo last -y"
  • "systemctl restart my-critical-service"
  • isEnd: true
  • name: TerminateWithRollback
  • action: aws:invokeLambdaFunction

inputs:

FunctionName: "AlertOperationsCenter"

InputPayload:

  • message: "Instance {{ InstanceId }} failed initial health inspection. Aborting."
  • isEnd: true
  • Comparison: Run Command vs. State Manager vs. Automation

Dimension SSM Run Command SSM State Manager SSM Automation

Execution Paradigm Imperative, one-time, ad-hoc execution across instances Declarative, continuous scheduled enforcement Orchestrated multi-step workflow across cloud resources

Primary Scope OS-level commands inside EC2/hybrid managed nodes OS-level configuration states and software baselines AWS API actions, cloud infrastructure, and node actions

Execution Engine SSM Agent on the managed node SSM Agent on the managed node on schedule AWS Systems Manager backend workflow engine

Failure Control maxConcurrency and maxErrors rate limiting Re-evaluated on next scheduled cycle; marks Non-Compliant Granular onFailure routing ( Abort , Continue , step:... )

Trigger Mechanism Manual CLI/Console or event-driven EventBridge rule Recurring interval ( cron or rate expression) Manual, EventBridge, AWS Config Remediation, or Maintenance Window