AWS Systems Manager Operations for the DevOps Engineer Professional (DOP-C02): Session Manager, Run Command, Patch Manager, Fleet Manager, OpsCenter & Incident Manager

Introduction

AWS Systems Manager is one of the most heavily used services on the DevOps Engineer Professional exam, and one of the easiest to underestimate. Candidates learn it as “the Parameter Store service,” store a few secrets, and move on — then lose points when a scenario asks how to patch a thousand instances on a schedule, give an auditor shell access without opening port 22, or aggregate operational issues into a single actionable queue. Systems Manager is really a suite of operational capabilities, and the DOP-C02 exam tests the operational half far more than most people expect.

This guide covers that operational surface: node management (Session Manager, Run Command, Patch Manager, Fleet Manager, Inventory, Compliance, Maintenance Windows) and operations management (OpsCenter, Change Manager, Incident Manager). Two Systems Manager topics are deliberately handed off to sibling articles so this one stays focused: Parameter Store and State Manager are configuration-management tools covered in the Configuration Management & IaC deep dive, and event-driven Automation runbooks as an auto-remediation engine are covered in the Incident and Event Response guide. If you haven’t mapped the whole exam yet, start with the AWS DevOps Engineer Professional exam guide.

What Systems Manager Actually Is

Systems Manager (often abbreviated SSM) is an umbrella over a dozen capabilities that share one foundation: the SSM Agent and a set of IAM permissions. Every managed node runs the agent, which is preinstalled on current Amazon Linux, Ubuntu, and Windows AMIs. The agent polls the Systems Manager service over HTTPS — outbound only — which is why so many SSM features work without inbound ports or a public IP.

For an instance to become a managed node, three things must be true:

1. The SSM Agent is installed and running (default on most modern AMIs).
2. The instance has an IAM instance profile granting the AmazonSSMManagedInstanceCore permissions (or a scoped equivalent).
3. The agent can reach the Systems Manager endpoints — via a NAT gateway, or better, via VPC interface endpoints (ssm, ssmmessages, ec2messages) so traffic never leaves the VPC.

If a scenario says “the instance doesn’t appear in Systems Manager,” the answer is almost always one of those three: missing agent, missing instance-profile permissions, or no network path to the endpoints. Commit that triage list to memory — it’s a recurring exam pattern.

Session Manager: Agentless Shell Access

Session Manager gives you an interactive shell (or port forwarding) to a managed node without SSH, without a bastion host, without an open inbound port, and without a public IP. Access flows through the SSM Agent’s outbound connection, and every action is governed by IAM.

Why the exam loves it:

• No inbound ports. You can close port 22 / 3389 entirely and remove bastion hosts. When a scenario asks how to reduce attack surface while keeping admin access, Session Manager is the answer.
• IAM-based authorization. Access is granted by IAM policy, not shared SSH keys — no key distribution or rotation problem.
• Full auditability. Session activity can be logged to CloudWatch Logs or S3, and every session start is an API call recorded in CloudTrail. You can also enforce KMS encryption on session data.

Starting a session from the CLI:

aws ssm start-session --target i-0abc123def4567890

Port forwarding — reach a private database through the instance without exposing it:

aws ssm start-session \
  --target i-0abc123def4567890 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3306"],"localPortNumber":["9000"]}'

Session Manager vs a bastion host is a frequent comparison. The bastion is a server you must patch, harden, and monitor, reachable on an open port. Session Manager removes the server entirely, ties access to IAM, and logs everything centrally. On the exam, “eliminate the bastion” and “close inbound SSH while keeping break-glass access” both point here.

Run Command: Ad-Hoc Actions at Fleet Scale

Run Command executes an SSM document (a defined action, like running a shell script or installing an agent) across many nodes at once, selected by instance IDs or by tags. It’s the imperative “do this now on these hundreds of machines” tool, and it replaces the old pattern of SSHing into each box.

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters 'commands=["sudo systemctl restart nginx"]' \
  --max-concurrency "25%" \
  --max-errors "5"

The two controls the exam cares about are rate and blast-radius limits: max-concurrency caps how many nodes run at once (as a number or percentage), and max-errors stops the whole command once too many fail. Together they let you roll an action out gradually and abort automatically if it’s going wrong. Output can be streamed to CloudWatch Logs or S3, and executions are recorded in CloudTrail.

Run Command is ad hoc. When you need the same action applied continuously to keep nodes in a desired state, that’s State Manager’s job — a configuration-management concern covered in the Configuration Management & IaC guide. Knowing the Run Command (once) vs State Manager (continuously enforced) distinction is a classic exam discriminator.

Patch Manager and Patch Baselines

Patch Manager automates OS and application patching across a fleet. Three concepts drive it:

• Patch baselines define which patches are approved. AWS provides predefined baselines per OS; you create custom baselines with approval rules — for example, “auto-approve Critical and Important security patches seven days after release” — plus explicit approve/reject lists.
• Patch groups map instances (via a Patch Group tag) to a specific baseline, so different fleets follow different policies (aggressive for dev, conservative for prod).
• Patch operations run in one of two modes: Scan (report compliance without changing anything) or Install (apply approved patches, typically with a reboot).

You almost never run patching by hand — you schedule it, which is where Maintenance Windows come in.

Maintenance Windows: Scheduling the Disruptive Work

A Maintenance Window is a recurring, bounded time slot for running disruptive tasks — patching, restarts, cleanup — against a set of targets. Each window has:

• A schedule (cron or rate expression) and a duration, with a cutoff so no new tasks start in the final N hours.
• Targets — instances chosen by ID or tag.
• Tasks — what to run: a Run Command document, an Automation runbook, a Lambda, or a Step Functions state machine, each with its own concurrency and error limits.

The canonical DOP-C02 pattern for compliant, hands-off patching is: a custom patch baseline → a patch group tag on the instances → a Maintenance Window that runs the AWS-RunPatchBaseline document on those targets on a schedule, with concurrency and error caps. If a scenario asks for “automatic monthly patching within an approved change window, without downtime beyond the window,” that’s the stack to assemble.

Fleet Manager, Inventory, and Compliance

Fleet Manager is a console-based remote-management UI for your nodes — browse the filesystem, view processes and performance counters, inspect logs, and open a session, all without direct login. It’s the “manage servers like a fleet, from the browser” experience.

Inventory collects metadata from managed nodes on a schedule — installed applications, OS details, network config, running services, custom attributes — and can aggregate it across accounts and Regions into an S3-backed data lake you can query with Athena. It answers “which instances have package X at version Y?” across the whole estate.

Compliance rolls up two signals: patch compliance (from Patch Manager — is each node at its approved patch level?) and association compliance (from State Manager — is each node in its desired configuration?). It gives you a single compliant/non-compliant view and can feed dashboards and alerts. When an auditor asks “prove every production instance is patched to policy,” Compliance plus Inventory is the evidence trail.

Operations Management: OpsCenter, Change Manager, and Incident Manager

The capabilities above manage nodes. The operations-management group manages operational work itself — issues, changes, and incidents — and it’s where DOP-C02’s Monitoring/Logging and Incident-Response domains intersect Systems Manager.

OpsCenter

OpsCenter aggregates operational issues — called OpsItems — into a single, searchable queue, each carrying context (related resources, recent CloudTrail events, relevant Automation runbooks) so an engineer can triage and remediate without hunting across consoles. OpsItems can be created automatically from CloudWatch alarms, EventBridge rules, or AWS Config rule changes. Instead of an alarm firing into an inbox that everyone ignores, it becomes a tracked item with suggested runbooks attached. On the exam, “centralize and track operational issues with remediation context” points to OpsCenter.

Change Manager

Change Manager is a change-control framework for requesting, approving, and executing operational changes safely. A change request references a change template (which defines the approval workflow and the runbook to execute), routes to designated approvers, and only then runs the associated Automation runbook — within an optional change calendar that blocks changes during freeze periods. It brings governed, auditable change management to infrastructure operations, which maps directly to the exam’s emphasis on controlled, reviewable change.

Incident Manager

Incident Manager is Systems Manager’s incident-response capability. It ties together:

• Response plans — predefined engagement: who gets paged, via which contacts and escalation plans, and which runbook to launch.
• Automatic incident creation — a CloudWatch alarm or EventBridge event can open an incident, page on-call, and start a runbook without human initiation.
• Incident records — a timeline, chat-based collaboration, and a structured post-incident analysis afterward to capture lessons learned.

When a scenario describes “detect a severe issue, automatically page on-call with escalation, launch a remediation runbook, and produce a post-incident review,” that’s Incident Manager. It complements the event-driven auto-remediation patterns in the Incident and Event Response guide — remediation fixes the resource automatically; Incident Manager coordinates the people and process when human response is required.

A DOP-C02 Decision Table

Requirement	Systems Manager capability
Admin shell without SSH, bastion, or open ports	Session Manager
Run a command now across a tagged fleet	Run Command
Keep nodes continuously in a desired state	State Manager (see config-mgmt guide)
Automated, scheduled OS patching to policy	Patch Manager + patch baseline + Maintenance Window
Prove patch/config compliance to an auditor	Compliance + Inventory
Browse and manage servers from the console	Fleet Manager
Central queue of operational issues with context	OpsCenter
Governed, approved change execution	Change Manager
Page on-call, run a runbook, review afterward	Incident Manager
Store config values and secrets	Parameter Store (see config-mgmt guide)

Common DOP-C02 Traps

• “Instance not managed” is a permissions/agent/network problem — check the instance profile (AmazonSSMManagedInstanceCore), the agent, and the path to the ssm/ssmmessages/ec2messages endpoints, in that order.
• Session Manager over a bastion whenever the goal is reducing attack surface or eliminating shared SSH keys.
• Run Command is once; State Manager is continuous. Don’t pick Run Command when the requirement is ongoing enforcement.
• Patching = baseline + patch group + Maintenance Window. A patch baseline alone doesn’t schedule anything.
• max-concurrency and max-errors are how you limit blast radius on Run Command and Maintenance Window tasks.
• OpsCenter aggregates issues; Incident Manager runs incident response. They’re related but distinct — OpsItems are a backlog, incidents are active engagements with paging.
• VPC interface endpoints keep SSM traffic private and let private-subnet instances work without a NAT gateway.

Reinforce the monitoring signals that trigger much of this — alarms, EventBridge, Logs Insights — with the monitoring and observability guide, since those are what open OpsItems and incidents in the first place.

Frequently Asked Questions

How is AWS Systems Manager weighted on the DOP-C02 exam?

Systems Manager isn’t a single exam domain — it’s a service that appears across domains. Session Manager and Patch Manager show up in security and compliance questions, Run Command and State Manager in configuration management, and OpsCenter and Incident Manager in monitoring and incident response. Because it spans so much of the operational surface, most candidates encounter several SSM scenarios on a single exam. Knowing which capability solves which problem — rather than memorizing every parameter — is what earns the points.

What makes an EC2 instance a managed node in Systems Manager?

Three conditions. First, the SSM Agent must be installed and running — it’s preinstalled on current Amazon Linux, Ubuntu, and Windows AMIs. Second, the instance needs an IAM instance profile granting Systems Manager permissions, typically the AmazonSSMManagedInstanceCore managed policy. Third, the agent must reach the Systems Manager endpoints, either through internet egress (NAT gateway) or, preferably, VPC interface endpoints for ssm, ssmmessages, and ec2messages. If an instance is missing from Systems Manager, one of these three is almost always the cause.

Why use Session Manager instead of a bastion host?

A bastion host is a server you must run, patch, harden, monitor, and expose on an open inbound port — plus you manage SSH keys for it. Session Manager removes the server entirely: access flows through the agent’s outbound connection, so you can close inbound SSH/RDP and drop public IPs. Authorization is IAM-based rather than key-based, and every session can be logged to CloudWatch Logs or S3 with the start recorded in CloudTrail. It reduces attack surface and operational overhead simultaneously, which is why exam scenarios about secure admin access point to it.

What is the difference between Run Command and State Manager?

Run Command is imperative and one-time: you send a document to a set of targets and it runs once, right now — restart a service, install a package, run a script across a tagged fleet. State Manager is declarative and continuous: it defines a desired state (an association) and re-applies it on a schedule to keep nodes compliant, correcting drift. If the requirement is “do this now,” use Run Command; if it’s “keep this true over time,” use State Manager. The exam frequently tests this exact distinction.

How do I set up automated, scheduled patching with Patch Manager?

Assemble three pieces. Create a patch baseline with approval rules defining which patches are approved and after what delay. Tag the target instances with a Patch Group value that maps them to that baseline. Then create a Maintenance Window on a cron or rate schedule that runs the AWS-RunPatchBaseline document against those targets, with max-concurrency and max-errors to control blast radius. The baseline decides what to patch, the patch group decides which instances follow it, and the Maintenance Window decides when — all without manual intervention.

What is the difference between OpsCenter and Incident Manager?

OpsCenter is an aggregated queue of operational issues (OpsItems) with remediation context attached — a place to track and work through problems, often created automatically from CloudWatch alarms, EventBridge, or Config. Incident Manager is a full incident-response system: response plans that page on-call contacts through escalation paths, automatic incident creation from alarms, chat-based collaboration during the incident, an automated runbook launch, and a structured post-incident analysis afterward. OpsCenter manages a backlog of issues; Incident Manager coordinates the active response to a serious one.

Conclusion

Systems Manager is far more than Parameter Store. For the DOP-C02 exam, its operational capabilities — agentless Session Manager access, fleet-wide Run Command, scheduled patching through baselines and Maintenance Windows, Fleet Manager, Inventory and Compliance for audit evidence, and the OpsCenter / Change Manager / Incident Manager operations suite — show up across security, configuration, monitoring, and incident-response scenarios. Learn which capability solves which problem, memorize the “not managed” triage list and the patching stack, and keep the once-vs-continuous and OpsCenter-vs-Incident-Manager distinctions sharp.

Sailor.sh’s AWS DevOps Engineer Professional (DOP-C02) mock exams include full-length, scenario-based exams with detailed explanations across all six domains — including the Session Manager, Patch Manager, Run Command, and Incident Manager scenarios this guide covered. Working through them is the fastest way to close the gap between “I understand this service” and “I can pick the right answer under pressure.” To structure your prep, the DOP-C02 study plan sequences the domains week by week, and the free DOP-C02 practice questions let you self-check before committing to a full mock.

Ready to make Systems Manager a strength? Drill realistic, explained scenarios with the Sailor.sh DOP-C02 mock exams, then map your full prep with the AWS DevOps Engineer Professional exam guide.