AWS Certified CloudOps Engineer - Associate (SOA-C03) #8 Domain 3-2 Deployment: Systems Manager Operations Automation
If #7 deployed infrastructure as code with CloudFormation, this post covers Systems Manager (SSM), the tool for operating the deployed instances. SSM is not a single service but a bundle of operations features, and it is one of the most frequently tested topics in SOA-C03. Let’s walk through its core features by operational use case.
The premise of SSM: agent and permissions #
Most SSM features require two things.
- SSM Agent: included by default in recent Amazon Linux and Windows AMIs. It lets the instance communicate with SSM
- Instance IAM Role: the
AmazonSSMManagedInstanceCorepolicy. Without it, the instance isn’t visible to SSM
For the scenario “the instance doesn’t appear in the managed list in the Systems Manager console,” the answer is almost always a missing IAM Role or an agent/network (endpoint) problem.
Parameter Store: managing config and secrets #
A store for centrally managing application config, connection strings, and secrets.
| Type | Use |
|---|---|
| String / StringList | General config values |
| SecureString | KMS-encrypted secrets (passwords, tokens) |
- Organize per environment with hierarchical paths (
/app/prod/db/url) - Track value change history with versioning
- Also used as the standard CloudWatch Agent config store seen in #3
Parameter Store vs Secrets Manager #
A frequent exam comparison.
| Aspect | Parameter Store | Secrets Manager |
|---|---|---|
| Cost | Standard is free | Paid per secret |
| Automatic rotation | None (implement it yourself) | Built-in automatic rotation |
| RDS integration | Manual | Integrated automatic credential rotation |
The answer to “periodically auto-rotate the DB password” is Secrets Manager. For a simple config value, the cost-free Parameter Store is the right choice.
Session Manager: keyless access #
A feature for connecting to a shell without an SSH key or inbound port.
- No need to open port 22. No bastion host required
- Connect to instances in private subnets too (via a VPC endpoint)
- Record every session to CloudTrail, S3, and CloudWatch Logs for auditing
It’s a strong answer on both security and operations. “Connect securely to a private instance without opening the SSH port, and keep a connection record” is almost always Session Manager.
Patch Manager: bulk patch application #
Automatically applies OS and application patches in bulk to instances.
| Component | Role |
|---|---|
| Patch Baseline | Rules for which patches to approve or reject |
| Patch Group | A group of patch targets bundled by tags |
| Maintenance Window | The time window in which to apply patches |
The answer to “automatically apply monthly security patches to hundreds of instances at a set time, and report unpatched instances” is Patch Manager (+ Maintenance Window + compliance reporting).
State Manager: maintaining the desired state #
Applies periodically so that an instance always maintains a defined configuration.
- Continuously enforces agent installation state, specific config files, domain join, and so on
- When drift occurs, it brings things back into line
If CloudFormation drift detection “reports the mismatch,” State Manager “corrects the mismatch.”
Run Command and Automation #
| Feature | Nature | Example |
|---|---|---|
| Run Command | Run a one-off command on multiple instances | Run a script once on all instances |
| Automation | Run a multi-step procedure (runbook) | The auto-recovery from #4 |
Run Command is a tool for fanning out commands simultaneously without SSH. The answer to “run the same command on multiple instances without keys” is Run Command. Automation is the one behind the auto-recovery runbook seen in #4.
Exam Question Patterns #
- Instance not visible as an SSM managed target → Check the IAM Role (
AmazonSSMManagedInstanceCore) - Auto-rotate the DB password → Secrets Manager
- Central management of simple config values (free) → Parameter Store
- Access a private instance without keys or ports + auditing → Session Manager
- Automatic bulk patch application to hundreds of instances + reporting → Patch Manager + Maintenance Window
- Continuously enforce a configuration → State Manager
- One-off command on multiple instances → Run Command
Common Pitfalls #
1) Assuming SSM requires the internet #
Private-subnet instances connect to SSM via a VPC interface endpoint even without internet. For “it’s private and SSM doesn’t work,” the answer is often endpoint configuration.
2) Thinking Parameter Store does automatic rotation #
Automatic rotation is a feature of Secrets Manager. Parameter Store requires you to update values yourself.
3) Misunderstanding that Session Manager needs port 22 #
Session Manager opens no inbound port. It connects even when the security group blocks SSH.
4) Patching one by one with Run Command #
For one-offs, Run Command works, but if you need regular, compliance reporting, Patch Manager is the right choice.
Summary #
What we covered in this post:
- SSM requires the agent + IAM Role (
AmazonSSMManagedInstanceCore) as a premise. The most common cause of a missing managed list entry - Parameter Store (free config, SecureString) vs Secrets Manager (paid, automatic rotation). For secret auto-rotation, Secrets Manager
- Session Manager for keyless, portless access + full session audit records. No bastion required
- Patch Manager for patch automation based on baselines, groups, and maintenance windows, plus compliance reporting
- State Manager to continuously enforce the desired configuration, Run Command for one-off commands, Automation for multi-step runbooks
Next: Domain 3-3 Container Operations #
Now that we’ve covered instance operations, the next topic is container operations, which were newly added in SOA-C03.
In #9 Domain 3-3 Deployment: Container Operations (ECS, EKS, ECR), I’ll cover the difference between ECS and EKS, the Fargate and EC2 launch types, how to manage images with ECR, container logging and monitoring, and deployment and scaling operations—the new scope of SOA-C03.