5 Questions to Test Your Configuration Management and IaC Knowledge (DOP-C02)
Here are 5 DOP-C02 practice questions on Configuration Management and IaC. About 17% of the exam comes from this domain. Each answer explains the correct choice and what is wrong with the others.
AWS DevOps Engineer – Professional (DOP-C02) · Configuration Management and IaC · 5 questions with answers and explanations
🧠Reading Configuration Management and IaC questions
Configuration and IaC scenarios ask how to apply changes across fleets, accounts and applications in a repeatable way. The choices span CloudFormation, CDK, StackSets, Control Tower, Systems Manager, AppConfig and Config. Many options only store or detect something; the right one usually also enforces, rolls out gradually or corrects, depending on what the scenario requires.
Tips for this set
• Tell similar Systems Manager features apart: State Manager keeps a configuration in place, Patch Manager handles patches, and Inventory reports what is installed.
• For large fleets, control both the pace of a rollout and how many errors it tolerates, so a bad change stops early.
• Fast reaction to one specific API call comes from events, not periodic scans. Check how quickly the scenario needs to respond.
📊 About this set
Exam: DOP-C02 · 75 questions · 180 minutes · passing score 750
This set: 3 applied, 2 advanced · 3 scenario, 1 trade-off, 1 troubleshooting
Topics: AWS AppConfig, Amazon CloudWatch, AWS Lambda, AWS Systems Manager, AWS IAM Identity Center, Amazon EventBridge, AWS Step Functions, AWS CloudTrail, AWS Config, AWS OpsWorks
Question 1 of 5
A mobile backend team wants to roll out a new pricing algorithm to a Lambda-based API gradually, monitor CloudWatch alarms during the rollout, and automatically halt and roll back the configuration change if error rates spike, without redeploying application code. Which AWS service is designed for this use case?
Show answer
✅ Answer: C
Difficulty: applied · Topic: AWS AppConfig, Amazon CloudWatch, AWS Lambda
AWS AppConfig
AppConfig is a capability of Systems Manager for deploying application configuration and feature flags separately from code.
• A configuration profile stores the data, for example a feature flag newPricing or a JSON document.
• A deployment strategy controls rollout: for example linear 20% every 2 minutes, followed by a bake time.
• An environment can have CloudWatch alarms as monitors. If an alarm goes into ALARM during deployment or bake time, AppConfig stops and rolls the configuration back automatically.
How Lambda reads it
Lambda functions use the AppConfig Lambda extension, which fetches and caches the configuration locally, so switching the pricing algorithm needs no code redeploy. Only the configuration version changes.
Why each option works or fails
• ✗ A. Secrets Manager rotation: rotation changes secret values on a schedule for security. It has no gradual rollout, alarm monitoring or automatic rollback of configuration.
• ✗ B. Parameter Store standard parameters: a parameter change is visible to all readers at once. There is no percentage-based rollout or alarm-triggered rollback.
• ✓ C. AppConfig with a gradual strategy and alarm monitor (correct): it rolls out configuration incrementally, watches the CloudWatch alarms, and reverts automatically if error rates spike, with no code deployment.
• ✗ D. CloudFormation change sets with approval: change sets preview infrastructure updates. They do not gradually release a configuration value to a running API or watch error rates to roll it back.
Question 2 of 5
An operations team creates a State Manager association targeting 2,000 managed instances to apply a configuration update immediately. They want to avoid overwhelming instances or downstream systems by applying the change to all 2,000 instances simultaneously. Which State Manager association setting should they configure?
Show answer
✅ Answer: C
Difficulty: applied · Topic: AWS Systems Manager
What a State Manager association does
A State Manager association applies an SSM document (for example AWS-RunShellScript or AWS-ApplyAnsiblePlaybooks) to a set of targets, such as all instances with tag Env=prod, either once or on a schedule, and keeps them in that state.
Rate controls
With 2,000 targets, you rarely want everything to run at the same moment. Associations have two rate-control settings:
• MaxConcurrency: how many targets run at once, as a number or a percentage, for example 50 or 10%. The rest wait until slots free up, so the change rolls out in waves.
• MaxErrors: how many failures are allowed before State Manager stops sending the association to new targets, for example 5%. A broken configuration is caught after a few instances instead of all 2,000.
Run Command and Automation use the same two settings for fleet-wide actions.
Why each option works or fails
• ✗ A. Use Maintenance Windows instead: associations do support rate controls themselves. Maintenance Windows are about when work is allowed to run, and they would add scheduling overhead without being needed for concurrency control.
• ✗ B. CloudWatch alarm pause: an alarm can be attached to an association as a stop condition, but it only reacts after load has already spiked; it does not limit how many of the 2,000 instances start at the same time.
• ✓ C. MaxConcurrency and MaxErrors (correct): MaxConcurrency staggers the rollout so only a controlled number of instances run the update at once, and MaxErrors halts it early if the change starts failing.
• ✗ D. MaxErrors only: MaxErrors limits how many failures are tolerated but does nothing about how many instances run at once; MaxConcurrency is the setting that prevents the simultaneous rollout.
Question 3 of 5
A security team wants IAM Identity Center permission sets and assignments managed as code and applied consistently. Which approach fits?
Show answer
✅ Answer: C
Difficulty: applied · Topic: AWS IAM Identity Center
IAM Identity Center objects
IAM Identity Center gives workforce users single sign-on into many accounts:
• A permission set is a template of policies (AWS managed, customer managed references, an inline policy, a permissions boundary) plus a session duration.
• An account assignment links a user or group to a permission set in a specific account; Identity Center then creates a matching IAM role in that account.
Managing them as code
These objects can be declared in CloudFormation (AWS::SSO::PermissionSet, AWS::SSO::Assignment) or Terraform (aws_ssoadmin_permission_set, aws_ssoadmin_account_assignment) and deployed from the management account or the delegated administrator account. Changes then go through pull requests, reviews and pipeline deployment, and the same definition produces the same access everywhere.
Why each option works or fails
• ✗ A. IAM users per account: it bypasses Identity Center entirely, creates long-term credentials in every account and multiplies what must be managed.
• ✗ B. One admin permission set for all groups: it violates least privilege, and giving everyone the same broad access says nothing about managing configuration as code.
• ✓ C. Permission sets and assignments as code (correct): CloudFormation or Terraform makes access configuration reviewable, versioned and applied identically every time, which is exactly the requirement.
• ✗ D. Manual console configuration per account: manual clicks are slow, error-prone and drift between accounts, with no review history.
Question 4 of 5
A team wants a fully automated pipeline: whenever a specific security-relevant API call, such as opening port 22 to 0.0.0.0/0 via ec2:AuthorizeSecurityGroupIngress, occurs anywhere in the account, the system should automatically evaluate the change, notify a Slack channel, and revoke the rule if it matches a disallowed pattern, all within seconds of the event, with clear visibility into each execution's steps for troubleshooting later. Which architecture is most appropriate?
Show answer
✅ Answer: A
Difficulty: advanced · Topic: Amazon EventBridge, AWS Step Functions, AWS Lambda, AWS CloudTrail, AWS Config
Reacting to an API call in near real time
When someone calls an AWS API, such as ec2:AuthorizeSecurityGroupIngress, CloudTrail records a management event. With CloudTrail recording those events, they also flow to Amazon EventBridge with the detail type "AWS API Call via CloudTrail", usually within seconds.
An EventBridge rule can match on fields in that event, for example eventName = AuthorizeSecurityGroupIngress, and start a target.
Why Step Functions as the target
The response has several steps: evaluate the rule (is it port 22 from 0.0.0.0/0?), post to Slack, revoke the rule if it is disallowed, and maybe record the result. A Step Functions state machine runs these as separate states:
• Choice states hold the "does it match the disallowed pattern?" logic.
• Task states call Lambda, an HTTP endpoint or the EC2 API directly (for example RevokeSecurityGroupIngress).
• Each execution keeps a visual history of every step's input, output and error, which is the troubleshooting visibility the team asked for.
Why each option works or fails
• ✓ A. EventBridge starting Step Functions (correct): the CloudTrail event reaches EventBridge within seconds of the API call, and a state machine performs the notify and revoke steps while recording each execution step by step for later troubleshooting.
• ✗ B. Hourly Lambda scanning CloudTrail logs: an open SSH rule could stay in place for up to an hour, and CloudTrail log files are delivered to S3 in batches, so this can never meet a "within seconds" goal.
• ✗ C. Config custom rule doing everything: a change-triggered Config rule depends on the configuration recorder noticing the change, which is typically slower than the EventBridge event, and one Lambda that evaluates, messages Slack and remediates gives no per-step execution history.
• ✗ D. Config periodic rule every 24 hours: a daily evaluation leaves the port open for up to a day, far outside the seconds-level response required.
Question 5 of 5
A team currently manages a fleet of legacy application servers using AWS OpsWorks Stacks with custom Chef cookbooks for configuration management. They are evaluating whether to continue investing in OpsWorks-based automation or migrate configuration management responsibilities to AWS Systems Manager, using State Manager, Run Command, and Automation. Which consideration should most influence this decision?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: AWS OpsWorks, AWS Systems Manager, AWS Config
The state of AWS OpsWorks
AWS OpsWorks (Stacks, and OpsWorks for Chef Automate and Puppet Enterprise) ran configuration management with Chef or Puppet, often needing a Chef or Puppet server or OpsWorks-managed agents. AWS has ended support for all OpsWorks offerings (OpsWorks Stacks reached end of life in May 2024), so continued investment there is a dead end.
What Systems Manager offers instead
Systems Manager is agent-based through the SSM Agent, which is already installed on many AWS-provided AMIs, and needs no separate configuration server:
• State Manager keeps instances in a desired configuration on a schedule.
• Run Command runs ad hoc commands across a fleet.
• Automation runs multi-step runbooks.
It manages EC2 and, through hybrid activations, on-premises servers and VMs. SSM documents can even run existing Ansible playbooks or Chef recipes (for example AWS-ApplyChefRecipes), which makes a gradual move away from OpsWorks easier.
Why each option works or fails
• ✗ A. OpsWorks is the recommended default: OpsWorks has reached end of life, so it is not recommended for any new configuration management work.
• ✓ B. Systems Manager, no Chef or Puppet server; plan migration (correct): SSM is native to AWS, needs no configuration server, and OpsWorks is no longer supported, so the decision should be driven by a planned move of the cookbooks' logic into SSM documents and associations.
• ✗ C. SSM cannot manage on-premises servers: Systems Manager manages hybrid and on-premises machines through hybrid activations, so this is not a reason to stay on OpsWorks.
• ✗ D. Cookbooks run unmodified in Automation: Automation runbooks are SSM documents with their own schema; Chef recipes can be run through a dedicated SSM document, but OpsWorks-specific stack and lifecycle behavior does not carry over, so the two are not equivalent.
🎯 What to remember
• Gradual, alarm-guarded, automatically rolled-back configuration or feature flag changes are what AppConfig is built for; Parameter Store and Secrets Manager only store values.
• To roll a change across a large fleet safely, set MaxConcurrency to stagger it and MaxErrors to stop it early; alarms and schedules are not concurrency controls.
• Manage Identity Center permission sets and assignments with infrastructure as code for consistent, reviewable access.
• For seconds-level reaction to a specific API call, trigger on the CloudTrail event in EventBridge and orchestrate the steps in Step Functions; periodic scans and Config schedules are far slower.
• OpsWorks is end of life; Systems Manager (State Manager, Run Command, Automation) is the native, server-less replacement, including for hybrid fleets.
🔗 Keep practicing on this blog
• All DOP-C02 practice sets
• Every exam on this blog
📚 Keep studying DOP-C02
More DOP-C02 questions: https://hyunhp.github.io/cert-bank/#exam=DOP-C02
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=DOP-C02
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment