DOP-C02 Configuration Management and IaC Practice Question

An organization uses AWS Elastic Beanstalk to deploy a web application. They need to ensure that configuration changes (e.g., environment variables, instance types) are version-controlled and can be rolled back. Which approach meets these requirements?

⚠ Common exam trap

A common mix-up: candidates confuse storing individual parameters (Parameter Store) with capturing the entire environment configuration, or they overcomplicate the solution with custom scripts when Elastic Beanstalk provides a built-in, versionable saved configuration feature that directly meets the requirement.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use Elastic Beanstalk saved configurations to capture environment settings and store the configuration files in a version control system.

Elastic Beanstalk saved configurations allow you to capture the complete environment settings (including environment variables, instance types, and other configuration options) as a YAML or JSON file. By storing these configuration files in a version control system (e.g., Git), you achieve version-controlled configuration that can be applied to recreate or roll back an environment to a known state using the `eb config` command or the AWS Management Console.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use AWS Systems Manager Parameter Store to store configuration values.
Why it's wrong here
Parameter Store is a secure key-value store, but Elastic Beanstalk does not natively read from it when provisioning or updating an environment. You would need custom software on the instances or lifecycle hooks to fetch and apply those values, leaving environment definition incomplete. Since the goal is to capture the full environment configuration for reproducibility, Parameter Store alone is insufficient.
✗
Create a custom script that uses the Elastic Beanstalk API to apply configuration and store the script in a Git repository.
Why it's wrong here
Writing a custom script that calls the Elastic Beanstalk API (e.g., UpdateEnvironment) to re-apply settings introduces a second source of truth and continuous maintenance burden. API calls require hard-coded credentials, careful ordering, and custom error handling, and they are unable to capture every environment attribute as cleanly as a saved configuration. The script may be versioned, but the desired environment state is still not declaratively defined.
✓
Use Elastic Beanstalk saved configurations to capture environment settings and store the configuration files in a version control system.
Why this is correct
Elastic Beanstalk saved configurations capture environment option settings into a JSON or YAML template that can be downloaded and committed to version control. These templates can be applied to new or existing environments with a direct API/CLI call, enabling repeatable deployment and rollback to a known good state. Because the configuration file is just a file in your repository, you get code review, history, and drift detection naturally.
✗
Manually record all configuration changes in a spreadsheet.
Why it's wrong here
Manually tracking configuration changes in a spreadsheet is error-prone, lacks an audit trail, and has no automated way to be applied to an environment. It does not capture all settings accurately, cannot be validated against a template, and introduces friction that makes rollback unreliable. This approach violates Infrastructure as Code principles and should never be used for environment management.

Go deeper

DOP-C02 Configuration Management and IaC Practice Question

Why each option matters

Option-by-option breakdown

Related to this question