What's changed: In-scope coverage: added Control Tower, Service Catalog, AWS Proton to s2; OpsWorks, License Manager, EC2 Image Builder to s3
2.3Configuration Management (Systems Manager, Config)
Understand runtime configuration management—Systems Manager (Parameter Store/State Manager/Patch Manager), AWS Config (configuration evaluation), and Elastic Beanstalk. Maintain desired state and correct drift.
Even after IaC provisioning, configuration drifts. Use Systems Manager and Config to maintain desired state and detect/correct drift.
2.3.1Configuration management services
- Parameter Store: centralize settings and secrets (SecureString).
- State Manager / Patch Manager: keep instances in desired state and auto-apply OS patches.
- AWS Config: continuously evaluate configuration against rules, detecting/recording drift (with auto-remediation).
- Elastic Beanstalk: a platform that abstracts app deploy/capacity/monitoring.
Common on DOP-C02: central settings/secrets = Parameter Store (SecureString), desired state = State Manager, OS patch automation = Patch Manager, config compliance/drift = AWS Config, app platform abstraction = Elastic Beanstalk. Auto-remediate Config violations via EventBridge + Lambda/SSM Automation.
For secrets needing rotation, use Secrets Manager; for simple settings or light secrets, Parameter Store (SecureString) is convenient.
DOP-C02 configuration management probes closing the loop from drift detection to automated remediation. AWS Config records resources as configuration items, evaluates compliance via managed rules or Lambda custom rules, and auto-remediates on violation by attaching a remediation action (SSM Automation document). Across an org, a Config aggregator centralizes compliance from many accounts/regions, and Conformance Packs distribute rule sets together. On the Systems Manager side, State Manager associations periodically enforce a "desired state" (agent config, domain join, etc.), Patch Manager governs patching with patch baselines and maintenance windows, and Automation runbooks idempotently run multi-step operations (AMI creation, isolation, recovery). For secrets, use Secrets Manager for DB credentials needing rotation (Lambda rotation) and Parameter Store for simple settings or hierarchical parameters. To abstract the app platform, Elastic Beanstalk (environment versioning, .ebextensions, immutable/rolling deploys) is an option, but choose plain IaC + CodeDeploy when fine-grained control is needed. The canonical auto-remediation is "Config noncompliant → EventBridge → Lambda/SSM Automation."
| Use | Service/feature | Key point |
|---|---|---|
| Settings / hierarchical params | Parameter Store | SecureString; free tier; lightweight |
| Secrets needing rotation | Secrets Manager | Lambda rotation; DB credentials |
| Desired state / patching | State Manager / Patch Manager | Associations; baselines; maintenance windows |
| Config compliance | AWS Config | Rule eval + remediation; aggregator |
Scenario: Enforce "no public S3 access" org-wide and auto-fix violations. → Distribute the AWS Config managed rule (s3-bucket-public-read/write-prohibited) to all accounts via a Conformance Pack or StackSets. On violation, a remediation action (SSM Automation) enables public access block. Centralize compliance with a Config aggregator for a single dashboard view.
FAQ: Parameter Store vs Secrets Manager? If you need automatic rotation (DB passwords, etc.), use Secrets Manager (paid; rotates via Lambda). For simple settings or light secrets, Parameter Store SecureString suffices (standard tier is free, lightweight). Parameter Store can also reference Secrets Manager secrets, so the two can be combined.
Exam trap: AWS Config handles evaluating, recording, and (if configured) remediating configuration, but auditing "who called the API" is CloudTrail’s job—don’t confuse them. Also, Config alone does not auto-fix; only with remediation actions or EventBridge + Lambda/SSM does the loop close.
2.3.2Services that complement configuration and image management
In the configuration management context, DOP-C02 in-scope services include Chef/Puppet-based configuration management (OpsWorks), license management (License Manager), and automated golden AMI creation (EC2 Image Builder).
OpsWorks runs Chef or Puppet as managed services, managing server configuration (package installation, service startup, app deployment) as code. Two variants exist: OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise. Its DevOps role is "configuration management leveraging existing Chef/Puppet recipes or manifests." The mainstream choices are Systems Manager (State Manager/Automation) and IaC (CloudFormation/CDK). Note: AWS OpsWorks (Stacks / Chef Automate / Puppet Enterprise) reached end of life on May 26, 2024; migrate to Systems Manager, IaC, or self-managed Chef/Puppet.
License Manager centralizes management of software licenses (BYOL: Bring Your Own License). Define license rules to prevent exceeding limits on cores, sockets, or instance counts; it integrates with Dedicated Hosts and provides usage reporting. In a DevOps context, choose it to automatically enforce and visualize software license compliance. License Manager rules can also control license counts at AMI launch time.
EC2 Image Builder automates the creation, testing, and distribution of golden AMIs and container images. An image pipeline defines the full workflow—build → test → multi-region distribution—and can embed base patching, CIS benchmark hardening, and vulnerability scanning. Its DevOps role is automating the image-baking phase of Immutable Infrastructure, keeping hardened images up to date with scheduled runs. Combined with IaC (CloudFormation/CDK), you can automate both the image layer and the stack layer of infrastructure.
| Service | DevOps role | When to choose |
|---|---|---|
| ==OpsWorks== | Server config management via Chef/Puppet | Leverage existing Chef/Puppet workflows |
| ==License Manager== | BYOL license cap management and compliance | Auto-prevent violations; visualize usage |
| ==EC2 Image Builder== | Automate golden AMI/container image build and distribution | Keep immutable infra images current and hardened |
DOP-C02 in-scope: managed Chef/Puppet config mgmt = OpsWorks, auto-enforce BYOL license caps = License Manager, automated golden AMI pipeline = EC2 Image Builder. EC2 Image Builder is tested in combination with Patch Manager to produce "already patched" images at build time. OpsWorks typically appears in the context of existing Chef/Puppet workflows, not new-system design.
2.3.3Section summary
- SSM = Parameter Store / State Manager / Patch Manager
- Evaluate = AWS Config (rules + remediation) / platform = Elastic Beanstalk
- Complement = OpsWorks (Chef/Puppet) / License Manager (licenses) / EC2 Image Builder (golden AMIs)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to auto-apply OS patches to many EC2 instances on a maintenance window. What in Systems Manager?
Q2. You want to centralize app settings/connection info (incl. secrets) and reference them without hardcoding. Convenient option?
Q3. You want continuous evaluation of whether resource configs comply with rules (e.g., EBS must be encrypted). What?