AWS Systems Manager Operations — Overview
Systems Manager is the largest single-service topic on SOA-C03 (51+ questions) and appears frequently on SAP-C02 and SCS-C03. The exam tests Patch Manager, Session Manager, Automation, State Manager, Run Command, and Parameter Store — often in combination with other services for automated operations.
Maintenance windows
Compliance reporting
Auto-approve rules
OS + app patching
No inbound ports needed
IAM-based auth
Full audit logging
Port forwarding
Approval workflows
Cross-account/region
EventBridge triggers
Change management
Scheduled associations
Auto-remediation
Agent configuration
Drift prevention
Across fleet (tags/groups)
Rate control
Output to S3/CW
No SSH needed
Patch Manager — Enterprise Patching
| Component | Purpose | Key Config |
|---|---|---|
| Patch Baseline | Defines which patches to approve/reject | Auto-approve after N days, severity filters, patch exceptions |
| Patch Group | Associate instances with baseline via tags | Tag: Patch Group = Production → uses Production baseline |
| Maintenance Window | Schedule when patching occurs | Cron/rate expressions, duration, cutoff time |
| Compliance | Report patch status across fleet | Compliant/Non-compliant per instance, integrate with Security Hub |
Session Manager — Secure Access
- How: Browser-based or CLI shell access to instances through SSM Agent (no SSH, no bastion, no inbound SG rules)
- Security: IAM controls who can start sessions. CloudTrail logs session start/end. Session data can be logged to S3/CloudWatch.
- Port forwarding: Tunnel ports through Session Manager (access RDS, internal web apps without VPN)
- Exam note: “Secure shell access without opening port 22” → Session Manager. “Audit all admin commands” → Session Manager logging.
Automation — Runbooks & Change Management
- Runbooks: Multi-step automation documents (YAML/JSON). Steps: approve, run command, invoke Lambda, wait, branch.
- Change Manager: Approval workflows for changes. Request → Approve → Execute → Verify.
- Cross-account: Execute automation in multiple accounts from a central admin account (Organizations integration).
- Common runbooks: Restart instance, create AMI, patch and reboot, remediate Config findings, golden AMI pipeline.
- Rate control: Limit concurrent executions (e.g., patch 10% of fleet at a time).
State Manager — Desired State
- Purpose: Ensure instances maintain a defined configuration. If they drift, auto-remediate.
- Associations: Link a document (desired state) to targets (instances by tag/ID). Runs on schedule or on change.
- Examples: Ensure CloudWatch agent is installed and running, ensure specific packages are installed, ensure firewall rules are configured.
- vs Config: Config DETECTS drift. State Manager ENFORCES and REMEDIATES drift automatically.
Inventory & Fleet Management
- Inventory: Collects metadata from instances (installed applications, OS versions, network config, Windows updates)
- Resource Data Sync: Aggregates inventory data to central S3 bucket (query with Athena across all accounts)
- Fleet Manager: Console for managing instances (view performance, connect, manage file systems) — centralized ops
- OpsCenter: Aggregates operational issues (OpsItems) from multiple sources for centralized tracking
Exam Tips
| Exam | Key Points |
|---|---|
| SOA-C03 | “Patch fleet on schedule” → Patch Manager + Maintenance Window. “Shell access without SSH” → Session Manager. “Enforce installed software” → State Manager. “Run script across 1000 instances” → Run Command. “Approval before changes” → Automation Change Manager. “Track patch compliance” → Patch Manager compliance + Security Hub. “Store config values” → Parameter Store. |
AWS Certification Exam Practice Questions
Question 1:
A company needs to patch 500 EC2 instances across production and staging. Production instances must be patched during a specific maintenance window (Sunday 2-4 AM). Staging can be patched anytime. Critical patches should auto-approve after 7 days. How should this be configured?
- Single patch baseline with all patches auto-approved, schedule Run Command for Sundays
- Two patch baselines (Prod: critical auto-approve 7 days; Staging: all auto-approve immediately). Patch groups via tags. Maintenance window for Prod on Sunday 2-4 AM. Staging patched on demand.
- Use AWS Config to detect missing patches and Lambda to install them
- Create AMIs with patches and replace instances weekly
Show Answer
Answer: B — Two baselines allow different approval rules per environment. Patch Groups (tags) associate instances with the correct baseline. Maintenance Window schedules production patching in the approved window. Staging can be patched immediately or on-demand. This is the standard enterprise patching pattern. Config (C) detects but doesn’t patch. AMI replacement (D) is a valid strategy but doesn’t directly patch running instances.
Question 2:
A security team requires that all administrator access to EC2 instances is auditable, doesn’t use SSH keys, and works without opening inbound ports in security groups. Which solution provides this?
- EC2 Instance Connect with temporary SSH keys
- Systems Manager Session Manager with IAM authentication and session logging to CloudWatch Logs
- VPN to private subnet + SSH with key rotation
- AWS Client VPN + bastion host
Show Answer
Answer: B — Session Manager: (1) No SSH keys (IAM auth). (2) No inbound ports needed (agent connects outbound to SSM endpoints). (3) Full audit: CloudTrail logs who started sessions, session data logged to CloudWatch/S3 (every command recorded). (4) Granular IAM control (who can access which instances). Instance Connect (A) still requires port 22 open.
Question 3:
A company needs to ensure the CloudWatch Agent is always installed and running on all EC2 instances. If an instance is launched without the agent, it should be automatically installed. If the agent stops, it should be automatically restarted. Which SSM feature provides this?
- Run Command executed on a cron schedule
- State Manager association with the AWS-ConfigureAWSPackage document, targeted by tag, applied on schedule
- Patch Manager with CloudWatch Agent in the patch baseline
- EventBridge rule detecting agent stop events
Show Answer
Answer: B — State Manager enforces desired state continuously. Associate the AWS-ConfigureAWSPackage document (installs/ensures CloudWatch Agent) with all instances (by tag). Runs on schedule (e.g., every 30 min) and on new instance launch. If agent is missing or stopped, association re-applies it. Run Command (A) is ad-hoc, not continuous enforcement. State Manager is the desired-state tool.
Question 4:
A security engineer needs to run a forensic script across 50 potentially compromised instances simultaneously. The script output must be captured in S3 for analysis. Which approach is fastest without requiring SSH access?
- Create an AMI of each instance for offline analysis
- Use Run Command with the AWS-RunShellScript document, target instances by tag, output to S3 bucket
- SSH into each instance sequentially and run the script
- Deploy a Lambda function that connects to each instance
Show Answer
Answer: B — Run Command executes commands across multiple instances simultaneously (no SSH needed). Target by tag or instance IDs. Output automatically stored in S3. Rate control available if needed. This is the fastest approach for fleet-wide script execution. SSH (C) is sequential and requires network access. Lambda (D) can’t directly execute on EC2 instances.
Question 5:
An operations team wants to create a golden AMI pipeline: launch base AMI → install updates → run hardening script → create new AMI → test → distribute to other accounts. Which SSM feature orchestrates this multi-step workflow?
- Run Command with a single script doing all steps
- SSM Automation runbook with sequential steps (launch, run command, create image, test, share)
- State Manager with the full pipeline as desired state
- Patch Manager with a custom patch baseline
Show Answer
Answer: B — SSM Automation is designed for multi-step operational workflows. Steps can include: aws:runInstances, aws:runCommand, aws:createImage, aws:approve (human gate), aws:copyImage (cross-account). Built-in error handling, rollback, and rate control. This is the standard golden AMI pattern. Run Command (A) is single-step. State Manager (C) is for desired state, not pipelines.
Related Posts
- Config vs CloudTrail vs CloudWatch
- Incident Response Architecture
- CI/CD Pipeline Architecture
- Auto Scaling & Performance
References
- AWS Systems Manager User Guide
- Patch Manager — AWS Docs
- Replacing Bastion with Session Manager — AWS Blog
Frequently Asked Questions
State Manager vs AWS Config — what’s the difference?
AWS Config: Detects configuration drift and compliance violations (detective). Records changes, evaluates rules, reports non-compliance. State Manager: Enforces desired state and auto-remediates (preventive/corrective). If something drifts, it fixes it. Use Config to KNOW about drift. Use State Manager to PREVENT/FIX drift. They complement each other.
When should I use Run Command vs Automation?
Run Command: Single-step, ad-hoc commands across a fleet (run a script, install a package, restart a service). Automation: Multi-step workflows with logic (if/else, approvals, wait states, cross-account). Use Run Command for simple immediate actions. Use Automation for orchestrated processes (golden AMI, DR failover, change management).