DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS Elastic Beanstalk to deploy a web application. The operations team wants to ensure that the environment's configuration (e.g., instance type, scaling limits) is version-controlled and reproducible. Which practice should they adopt?
⚠ Common exam trap
The trap here is that candidates may overthink and choose CloudFormation (Option C) because it is a powerful IaC tool, but the question specifically asks for a practice within Elastic Beanstalk's own features to version-control its configuration, not to replace the deployment service entirely.
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 the Elastic Beanstalk saved configuration feature to download a configuration file and store it in version control.
Elastic Beanstalk's saved configuration feature allows you to download the environment's configuration as a YAML or JSON file, which can be stored in version control and used to recreate identical environments. This directly addresses the need for version-controlled, reproducible environment configuration without requiring additional infrastructure-as-code tools.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Manually recreate the environment from the Elastic Beanstalk console when needed.
Why it's wrong here
Manually recreating an Elastic Beanstalk environment from the console is a non-retroactive, error-prone process that depends on an engineer's memory of every setting. Each manual re-entry—instance types, environment variables, scaling triggers, and security settings—invites configuration drift, and no single versioned artifact captures the environment's state. This approach cannot be audited, reproduced exactly, or rolled back to a prior known-good state, so it fundamentally violates the reproducibility requirement.
- ✓
Use the Elastic Beanstalk saved configuration feature to download a configuration file and store it in version control.
Why this is correct
The Elastic Beanstalk saved configuration feature exports the current environment's settings into a YAML file via `eb config save`, which can be downloaded and committed to version control. This file captures the complete environment configuration—platform, instance type, environment variables, scaling limits, health-check settings, and other option settings—without including transient data like application versions. Storing this file in Git enables you to recreate the same environment later with `eb config put`, apply it across regions or accounts, and revert to older configurations through normal version-control history.
- ✗
Use AWS CloudFormation to define the environment and store the template in a Git repository.
Why it's wrong here
While CloudFormation is excellent for version-controlling infrastructure, it defines the *entire* AWS environment, not just the configuration of an existing Elastic Beanstalk application. It's tempting because it offers robust infrastructure-as-code capabilities and version control via Git, making it ideal for provisioning and managing AWS resources from scratch. However, Elastic Beanstalk has its own built-in mechanisms for managing application and environment configuration versions.
- ✗
Document the configuration in a wiki and apply it manually through the AWS Management Console.
Why it's wrong here
Wiki documentation is a static, human-authored artifact that is not tied to the live environment and is not subject to the same versioning or review workflow as code. Manually applying settings from a wiki through the AWS Management Console reintroduces the exact same risk of configuration drift and human error as option 1, because there is no automated mechanism to enforce the documented values against the actual environment. Unlike a saved configuration file, a wiki page cannot be directly executed by Elastic Beanstalk, and it has no built-in mechanism for validation, rollback, or differential comparison, so it fails as a reliable infrastructure-as-code practice.
Go deeper
Related to this question
About these practice questions
One of 1,013 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.