Configuration Management with AWS OpsWorks and Systems Manager. It solves the chaos of keeping hundreds or thousands of servers (virtual computers) set up identically and securely, especially when humans make mistakes or servers get restarted. For the DOP-C02 exam, you must understand how these two services automate the boring but critical tasks of applying settings, updating software, and fixing drift so that your infrastructure stays consistent and auditable.
Jump to a section
A simple way to picture Configuration Management with AWS OpsWorks and Systems Manager
You are managing the renovation of a 150-room hotel. The owner wants every room to have the same light switch layout, the same thermostat brand, and the same smart TV software version. You have a team of 10 electricians, 5 painters, and 3 IT technicians. Without a central plan, each electrician installs switches at different heights, painters choose slightly different shades of white, and IT technicians update TVs on different days, leaving 20 rooms with outdated software.
This is exactly the problem Configuration Management solves in IT. AWS OpsWorks is like giving every worker a printed blueprint for each room type, plus a checklist that must be signed off before the next room starts. If a worker deviates, the blueprint is the single source of truth.
AWS Systems Manager is like a mobile app on your phone that lets you check any room’s status remotely, push a new TV software update to all 150 rooms at once, and automatically fix a broken light switch in Room 42 without sending an electrician. Systems Manager also sends you a daily report: '150 rooms compliant, 0 rooms out of date.' Without these tools, you would be running from room to room, clipboard in hand, hoping everyone followed the plan. With them, you control the entire hotel from a single dashboard.
Configuration Management is the practice of making sure every piece of computer infrastructure (servers, databases, networks) is set up exactly the way you want it, and stays that way over time. Without it, you might manually install software on one server, forget to run an update on another, and end up with a security hole because one server has an old version. AWS OpsWorks and AWS Systems Manager are two services that automate this control.
AWS OpsWorks is a managed service that lets you define your infrastructure as stacks and layers. Think of a stack as a complete application: for example, a web application with a database, a web server, and a load balancer. Each component is a layer. OpsWorks uses Chef (a tool that writes recipes for server configuration) or Puppet (another similar tool) to apply a desired state. When you create a layer, you assign recipes that install software, set firewall rules, and configure services. When a new server is added to that layer, OpsWorks automatically runs those recipes so the server matches exactly. It replaces the old way of creating a 'golden image' (a frozen snapshot of a perfectly configured server) and then hoping you never need to update it.
AWS Systems Manager is a broader toolset. It does not rely on Chef or Puppet. Instead, it uses an agent installed on every server (the SSM Agent) that reports back to AWS. Systems Manager has several features:
State Manager: Defines a desired configuration (like 'turn on Windows Firewall' or 'install antivirus software') and enforces it on a schedule. If the server drifts (someone manually disables the firewall), State Manager automatically re-applies the correct setting at the next check.
Patch Manager: Automates installing security updates on a set schedule. You define a patch baseline (approved updates) and a maintenance window (a time when servers can be restarted). Patch Manager then scans servers, identifies missing patches, and installs them without you logging in.
Run Command: Lets you run a script (like a PowerShell or shell command) on many servers at once without needing SSH keys or Remote Desktop credentials. This is useful for emergency fixes, like killing a rogue process.
Session Manager: Provides secure, audited shell access to servers without opening inbound ports (port 22 for SSH or port 3389 for RDP). You connect through the AWS console or CLI, and all commands are logged to CloudTrail.
The core difference between OpsWorks and Systems Manager is this: OpsWorks is designed to manage the entire life cycle of an application stack — provisioning servers, deploying code, scaling up. Systems Manager is more of a Swiss Army knife that works across any server (AWS or on-premises) to apply configurations, patch, and manage without touching the application lifecycle. For DOP-C02, you need to know when to use each. For example, if you need to deploy a new version of your application with rolling updates, OpsWorks is better. If you need to ensure all your servers have the latest security patches every Tuesday at 2 AM, use Systems Manager Patch Manager.
Configuration Management replaces the manual, error-prone process where someone logs into each server one by one and runs commands. It also replaces the 'pet server' model (where you treat each server as unique and irreplaceable) with the 'cattle' model (where servers are interchangeable and you manage them in groups).
Install the SSM Agent
On every server you want to manage with Systems Manager, install the SSM Agent. For Amazon EC2 instances running Amazon Linux 2, the agent is pre-installed. For on-premises servers, you download and install it manually. Without the agent, Systems Manager has no way to communicate with the server.
Register the Server as a Managed Instance
After installing the agent, you register the server with AWS Systems Manager. This creates a managed instance ID that AWS can use to target the server. For EC2 instances, this happens automatically if the instance has an IAM role that allows Systems Manager actions.
Define a Desired State with State Manager
In Systems Manager, you create a State Manager association. You choose a document (pre-defined or custom) that describes the configuration you want, for example 'ensure Windows Firewall is enabled'. You set a schedule, such as every 30 minutes, and specify which servers to target using tags. The association is then applied.
Set Up Patch Manager with a Maintenance Window
You create a patch baseline that lists approved patches (e.g., only critical security updates). Then you create a maintenance window that defines a time window (e.g., every Tuesday 2-4 AM). You assign the patch baseline and target servers to the maintenance window. Patch Manager will then scan, download, and install patches during the window.
Create an OpsWorks Stack with Layers and Recipes
In OpsWorks, you create a stack for your application (e.g., a web app). Within the stack, you define layers: a web layer, an app layer, a database layer. For each layer, you assign Chef recipes for setup, configure, deploy, and shutdown lifecycle events. When you add an instance to a layer, OpsWorks automatically runs the recipes.
Deploy an Application Update with OpsWorks
When you have a new version of your code, you update the Chef recipe or deployment script. In OpsWorks, you trigger a 'Deploy' command. OpsWorks runs the Deploy recipe on all instances in the stack, pulling the new code from your repository (e.g., S3 or GitHub) and performing a rolling update to avoid downtime.
Imagine you work as a DevOps engineer for a retail company that runs an e-commerce website on 100 Amazon EC2 (Elastic Compute Cloud) servers. The business depends on the website being fast and secure. Every Tuesday, security patches are released by the operating system vendor (Microsoft for Windows Server or the Linux kernel maintainers). Before Configuration Management, a junior engineer would manually Remote Desktop or SSH into each server, run the update command, wait, reboot, and move to the next. This took 10 minutes per server, so over 16 hours of tedious work. One server always got missed because the engineer was distracted. That server had a known vulnerability, and it got compromised in a breach. The company lost customer credit card data.
With AWS Systems Manager Patch Manager, you set up a weekly maintenance window every Tuesday from 2 AM to 4 AM. You define a patch baseline that automatically approves all security patches with a severity of 'Critical' or 'Important'. Patch Manager then scans all 100 servers, identifies which missing patches are approved, downloads them, installs them, and reboots the servers if required. You also use State Manager to enforce a configuration: every server must have the Windows Firewall enabled and the local administrator password must change every 60 days. If someone accidentally disables the firewall during troubleshooting, State Manager re-enables it within 15 minutes.
For application deployment, you use AWS OpsWorks. Your e-commerce app has three layers: a web layer (serving web pages), an app layer (processing orders), and a database layer (PostgreSQL). You define a Chef recipe that installs the latest version of node.js, configures the web server (Nginx), and deploys the application code from an S3 bucket. When you launch a new environment for testing, OpsWorks automatically creates the stack, installs software, and deploys the code in about 10 minutes. When you push a new feature, you update the recipe and let OpsWorks roll out the change to all servers in the production layer without downtime.
These tools free the team from drudgery. Instead of babysitting servers, the DevOps team works on building new features, improving performance, and writing automated tests. The business also benefits from an audit trail: you can prove to an auditor that all servers had patches installed within 30 days of release, and that configuration changes were approved and logged.
The DOP-C02 exam tests your ability to choose the right tool for the specific configuration management task. You will see scenario-based questions where you must decide between AWS OpsWorks, Systems Manager, or other services like AWS Config or AWS Elastic Beanstalk. Here is what to focus on:
OpsWorks vs Systems Manager: The exam loves to present a scenario where you need to manage packages or run scripts on a schedule. The trap is that both services can do some of this. The key differentiator: OpsWorks is lifecycle-oriented (provisioning, deployment, scaling) and uses Chef/Puppet. Systems Manager is agent-based, agent-agnostic, and works outside of application stacks. If the question mentions 'desired state configuration' for Windows servers, it is likely Systems Manager State Manager. If it mentions 'rolling updates' or 'layers', it is OpsWorks.
Systems Manager Patch Manager concepts:
Patch Baseline: defines which patches are approved (e.g., only security patches, or all patches).
Patch Group: a tag (e.g., 'PatchGroup: Production') that tells Patch Manager which servers to target.
Maintenance Window: a schedule (e.g., every Sunday at 2 AM) when patching can occur.
The exam will test that you cannot patch a server without a maintenance window.
Systems Manager State Manager:
You define an association between a set of servers (by tag) and a document (a JSON or YAML file that describes the desired state).
The association can be applied once or on a schedule (e.g., every 30 minutes).
Exam trap: State Manager does not require Chef or Puppet. It runs directly on the SSM Agent.
OpsWorks Stacks, Layers, and Recipes:
- Stacks group resources that belong together (e.g., all servers for a web app). - Layers define a role (e.g., web server, database server). Each layer has Chef recipes. - Lifecycle events: Setup (first time), Configure (when instances are added or removed), Deploy (when code is deployed), Undeploy (when instances are shut down), Shutdown. The exam tests that Chef recipes are associated with the correct lifecycle event. - Auto Healing: if a server fails health checks, OpsWorks automatically replaces it. This is a key exam concept. - Common trap: Questions that ask about 'configuration management' but mention 'compliance' or 'auditing'. The correct answer is often AWS Config, not Systems Manager. AWS Config records configuration changes and evaluates rules (e.g., 'all EC2 instances must have a specific tag'). It does not apply changes — it only detects and reports. Systems Manager applies changes. Know the difference. - Another trap: Questions about patching on-premises servers. Systems Manager can manage on-premises servers if you install the SSM Agent and register them as managed instances. OpsWorks is for AWS resources only. - Key definitions to memorise: - 'Desired State Configuration' (DSC): the concept of declaring what a server should look like, and having the tool make it so. - 'Drift': when a server's actual state differs from its desired state. State Manager fixes drift. - 'SSM Agent': the software installed on each server that communicates with Systems Manager. Without it, Systems Manager does not work. - 'Chef Recipe': a script that defines steps to configure a server (e.g., install Apache, copy config files). Used by OpsWorks.
Configuration management is the practice of defining and enforcing a desired state for servers, replacing manual and error-prone logins.
AWS Systems Manager State Manager enforces a desired configuration on a schedule and automatically corrects any drift.
AWS OpsWorks uses Chef or Puppet recipes applied to layers in a stack to automate application deployment and lifecycle management.
Patch Manager requires a maintenance window, a patch baseline, and a patch group (a tag) to target servers for patching.
The SSM Agent is mandatory for any server (AWS or on-premises) to be managed by Systems Manager; without it, the service cannot communicate.
OpsWorks auto-healing automatically replaces an unhealthy instance in a layer without manual intervention.
Configuration management helps achieve auditability by logging all changes and patches, which is critical for compliance frameworks.
Systems Manager Run Command lets you execute scripts on many servers simultaneously without needing SSH keys or open inbound ports.
These come up on the exam all the time. Here's how to tell them apart.
AWS OpsWorks
Uses Chef or Puppet recipes to define configuration
Manages the full lifecycle of an application stack (setup, deploy, scale, shutdown)
Primarily works within AWS, with limited support for on-premises via hybrid mode
AWS Systems Manager
Uses SSM Agent and documents (no Chef/Puppet required)
Focuses on operational tasks: patching, state enforcement, remote commands, session management
Works with both AWS and on-premises servers registered as managed instances
State Manager (Systems Manager)
Enforces a desired configuration (e.g., firewall settings, registry keys) on a schedule
Corrects drift back to the defined state
Uses associations and SSM documents
Patch Manager (Systems Manager)
Scans and installs operating system security updates on a schedule
Uses patch baselines, maintenance windows, and patch groups
Only applies patches; does not manage other configuration settings
Configuration Management (OpsWorks/Systems Manager)
Manages software and settings inside servers after they are running
Reactive or scheduled enforcement of desired state
Examples: install Apache, enable firewall, deploy application code
Infrastructure as Code (AWS CloudFormation)
Defines and provisions the infrastructure itself (VPC, subnets, EC2 instances, load balancers)
Provisioning happens at creation time; does not manage post-creation software config
Example: create a stack that launches 3 EC2 instances in an auto-scaling group
Mistake
AWS OpsWorks and AWS Systems Manager are the same service, just with different names.
Correct
OpsWorks is for managing application lifecycles using Chef/Puppet layers and stacks. Systems Manager is a broader operational toolset for patching, state management, and secure access, that works across AWS and on-premises.
Both services deal with configuration, so beginners think they overlap. But their purposes and mechanisms are fundamentally different.
Mistake
Systems Manager can only patch Windows servers, not Linux.
Correct
Systems Manager Patch Manager supports both Windows and Linux (Amazon Linux, Ubuntu, CentOS, Red Hat, SUSE). The patch baselines can be customised per operating system.
Many beginners associate patching with Windows Update, so they assume it only applies to Windows. AWS designed Patch Manager to cover all major OS types.
Mistake
Configuration Management is only needed for large companies with thousands of servers.
Correct
Even a single server benefits from Configuration Management because it ensures reproducibility, security, and auditability. If a server crashes, you can rebuild it identically in minutes instead of hours.
Beginners think the complexity is not worth it for small setups. But manual configuration is a common source of security breaches and downtime, regardless of scale.
Mistake
Once you apply a configuration with State Manager, it never changes unless you manually intervene.
Correct
State Manager runs on a schedule you define (e.g., every 30 minutes). If the server drifts between checks, State Manager will re-apply the desired configuration at the next scheduled run. It does not continuously monitor.
People assume 'desired state' means 'set and forget' with immediate enforcement. They forget that State Manager is event-driven on a timer, not real-time.
Mistake
AWS OpsWorks uses AWS CloudFormation templates to define infrastructure.
Correct
OpsWorks uses Chef or Puppet recipes for configuration, and its own stack/layer model. While you can integrate CloudFormation with OpsWorks, they are separate tools. CloudFormation is for provisioning infrastructure (VPCs, subnets, etc.), not for configuring software inside servers.
Both OpsWorks and CloudFormation create resources, so beginners confuse their roles. CloudFormation is 'Infrastructure as Code'; OpsWorks is 'Configuration as Code'.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Not necessarily. If you just need to patch servers and enforce basic configurations, Systems Manager is sufficient. But if you are managing a complex application with multiple tiers and need automated deployment and scaling tied to Chef recipes, OpsWorks is built for that.
Yes. You can install the SSM Agent on any server running Windows or Linux, whether it is in a different cloud or on your own data centre. After registering it as a managed instance, Systems Manager can patch, run commands, and enforce state on that server.
If the agent crashes or cannot reach AWS (e.g., network issue), Systems Manager cannot manage that server. Patching, state enforcement, and remote commands will fail. You must restart the agent or fix the network connectivity to restore management.
No. Elastic Beanstalk is a Platform-as-a-Service (PaaS) that automatically provisions and manages the underlying infrastructure for your application. OpsWorks gives you more control over the configuration using Chef recipes, but you must define the stack and layers yourself.
If the task involves running scripts on a schedule, patching, or enforcing a simple setting, use Systems Manager. If the task involves deploying an application with multiple tiers and requires lifecycle management (setup, configure, deploy, shutdown), use OpsWorks.
Indirectly yes. You can install the SSM Agent inside a container (if it is running a full OS like Ubuntu), but it is not recommended. For managing containers, AWS recommends using Amazon ECS or EKS with task definitions that define the container configuration, rather than Systems Manager.
You've finished Configuration Management with AWS OpsWorks and Systems Manager. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?