3.2 - Automation with Systems Manager (Run Command, Patch Manager)
AWS SysOps Administrator objective 3.2 covers automating manual and repeatable operations with AWS Systems Manager. Managed instances need the SSM Agent and an instance profile with AmazonSSMManagedInstanceCore. Run Command executes scripts across a fleet without SSH, Session Manager opens a shell with no open inbound ports or bastion and logs the session, and State Manager enforces a desired configuration on a schedule. Patch Manager applies patch baselines to patch groups defined by tags, scans or installs during Maintenance Windows, and reports compliance. Parameter Store holds configuration as String, StringList or KMS-encrypted SecureString, while Secrets Manager adds rotation. Automation runbooks chain multi-step actions such as creating an AMI or remediating a resource. Expect scenario questions about running commands at scale, shell access without SSH, or fleet patching, and ask which Systems Manager capability fits.
Shell access with no open ports or bastion = Session Manager. Run a script across a fleet without SSH = Run Command. Patch a fleet on a schedule = Patch Manager plus a Maintenance Window.
Practice questions
1. A CloudWatch alarm should automatically run a runbook that clears a full disk on the affected instance. What is the cleanest way to wire this?
- Have the alarm publish to SNS, which triggers an SSM Automation runbook (correct answer)
- Manually SSH into the instance every time the on-call engineer is paged at night
- Reboot the instance from the alarm and hope the disk clears itself
- Terminate the instance so Auto Scaling launches a clean replacement each time
Routing the alarm to SNS (or EventBridge) that invokes an SSM Automation runbook gives repeatable, hands-off remediation. Manual SSH does not scale, and terminate/reboot are heavy-handed for a disk-space issue.
2. You must roll out the same CloudWatch agent configuration to 200 EC2 instances and collect memory metrics. What is the recommended approach?
- Store the config in SSM Parameter Store and deploy it with SSM (correct answer)
- Copy a hand-edited config file onto every instance individually over SSH
- Enable detailed monitoring, which pushes memory metrics across the fleet
- Raise a support ticket asking AWS to enable memory metrics for you
Storing the agent config in SSM Parameter Store and pushing it with SSM (or amazon-cloudwatch-agent-ctl) gives consistent, repeatable rollout at scale. Detailed monitoring never adds memory metrics; only the agent does.
3. You must install and start the CloudWatch agent on 200 running instances without SSH. What is the cleanest method?
- Use SSM Run Command with the AmazonCloudWatch-ManageAgent document (correct answer)
- Connect to each instance over SSH and run the installer script by hand
- Bake a brand-new AMI and force-replace all 200 running instances at once
- Add the install commands to user data and reboot every instance in production
SSM Run Command with the managed CloudWatch agent document installs and configures the agent fleet-wide with no SSH and no reboot. Manual SSH does not scale, re-baking AMIs is disruptive, and user data runs only at boot so it would force reboots.
4. Your team wants metric filters versioned and deployed the same way as the rest of the stack. What is the best approach?
- Click each metric filter into the console and screenshot it for the wiki
- Define AWS::Logs::MetricFilter resources in the CloudFormation template (correct answer)
- Have each engineer re-create the filters manually in every environment
- Store the filter patterns in a spreadsheet and paste them in when needed
Declaring AWS::Logs::MetricFilter (or the equivalent in CDK/Terraform) versions and deploys filters as code, consistently across environments. Console clicks, manual re-creation, and spreadsheets are error-prone and not reproducible.
5. You want the same dashboard reproduced identically across dev, test and prod. Best practice?
- Recreate each dashboard by hand in every environment
- Define the dashboard as code in CloudFormation (correct answer)
- Screenshot the dev dashboard and share the image widely
- Grant everyone console access to edit one shared dashboard
Defining the dashboard as an AWS::CloudWatch::Dashboard resource in CloudFormation makes it versioned, repeatable and identical per environment. Manual recreation drifts, screenshots are not live, and one shared editable dashboard is not reproducible infrastructure.
6. Business stakeholders without AWS accounts must view a live dashboard. Which built-in option lets them?
- Give each stakeholder a full IAM user in the account
- Share the dashboard using CloudWatch dashboard sharing (correct answer)
- Email a static PNG export of the dashboard each morning
- Grant them the AdministratorAccess managed policy
CloudWatch dashboard sharing produces a link (optionally password-protected or SSO-gated) so external viewers see a live dashboard without AWS accounts. Full IAM users or AdministratorAccess over-grant access, and a PNG export is not live.