DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS Elastic Beanstalk to deploy a Java web application. The DevOps team wants to ensure that configuration changes are tracked and can be rolled back if needed. Which Elastic Beanstalk feature should they use?
⚠ Common exam trap
Candidates often confuse configuration management with CI/CD pipeline tools, assuming that CodePipeline or CodeCommit can handle environment-specific rollbacks, when in fact Elastic Beanstalk's native saved configurations are the simplest and most direct mechanism for tracking and reverting environment settings.
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 restore them if needed.
Elastic Beanstalk saved configurations allow you to capture the environment's configuration settings (e.g., instance type, environment variables, platform version) as a JSON file stored in S3. This enables you to restore or recreate an environment with the exact same settings, providing a straightforward rollback mechanism for configuration changes without relying on external tools or pipelines.
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 CodeCommit to store configuration files and version them.
Why it's wrong here
AWS CodeCommit is a fully managed source control service that versions code and files. Storing configuration files there does not capture the active option settings of an Elastic Beanstalk environment, nor does Elastic Beanstalk automatically read or apply them at runtime. Versioning in CodeCommit only tracks file revisions; rolling back environment settings would require manually reapplying the files, not restoring the environment's configuration state. Thus, it lacks the native integration needed for configuration rollback.
- ✗
Use AWS CodePipeline with a manual approval stage to track changes.
Why it's wrong here
AWS CodePipeline with a manual approval stage provides a release automation workflow where changes wait for human sign-off before progressing. Approval gates are about process control and auditing who approved which build, not about recording or restoring Elastic Beanstalk option settings. Pipeline execution history may show artifacts deployed, but it does not expose the environment's configuration parameters or allow you to revert to a previous configuration state. The manual stage is for quality gates, not a configuration snapshot mechanism.
- ✗
Use AWS CloudFormation change sets to review changes before deployment.
Why it's wrong here
AWS CloudFormation change sets allow you to preview how a stack update will affect resources before executing it, which is useful for infrastructure-as-code. Elastic Beanstalk environments, however, are managed through the Beanstalk service, and changes made via the console, CLI, or API do not automatically correspond to CloudFormation stack changes, so change sets lack visibility into Beanstalk option settings. Even when a Beanstalk environment is within a CloudFormation stack, change sets only show the template-level resource modifications, not the granular environment settings like EC2 instance types or environment variables. Thus, they cannot capture or rollback environment configuration directly.
- ✓
Use Elastic Beanstalk saved configurations to capture environment settings and restore them if needed.
Why this is correct
Elastic Beanstalk saved configurations provide a native way to snapshot an environment's option settings, environment variables, and solution stack into a re-usable YAML file. You can save a known-good configuration using the console or `eb config save`, and later restore it to the same or a different environment to roll back any undesired changes. Because saved configurations are purpose-built for this scenario, they give you an auditable, restorable record of environment settings without requiring code deployments or external tools.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.