DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS Elastic Beanstalk to deploy a web application. They want to ensure that configuration changes (e.g., environment variables, instance type) are version-controlled and can be rolled back. Which strategy should they use?
⚠ Common exam trap
It's easy for candidates to confuse saved configurations (Option B) with version-controlled configurations, but saved configurations are not tied to application versions and cannot be rolled back automatically with a source code deployment.
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
✓
Store configuration in a configuration file (e.g., .ebextensions) included with the application source code.
Storing configuration in .ebextensions files (YAML/JSON) within the application source bundle allows version control of environment settings (e.g., environment variables, instance type) alongside the code. When the application is deployed or updated, Elastic Beanstalk applies these configuration files automatically, enabling consistent rollback by redeploying a previous source bundle version. This approach integrates configuration management with the application lifecycle, ensuring that changes are tracked and reversible.
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 CloudFormation to manage the Beanstalk environment outside of Beanstalk.
Why it's wrong here
Elastic Beanstalk already creates and owns a dedicated AWS CloudFormation stack for each environment; managing that stack directly bypasses Beanstalk's lifecycle logic and can cause stack drift, failed environment updates, or orphaned resources. CloudFormation templates written outside Beanstalk are not automatically synchronized with deployed application versions, so you lose the ability to roll back the application and its configuration as a single cohesive unit. This approach is unsupported and risks breaking the environment.
- ✗
Use Elastic Beanstalk saved configurations to store environment settings.
Why it's wrong here
Elastic Beanstalk saved configurations are simply named snapshots of environment option settings, such as instance type, environment variables, and health check URLs, that you can manually export and later apply to another environment. However, they are stored as artifacts independent of the application source bundle and are not automatically associated with a specific application version, meaning a code deployment or rollback does not carry the corresponding configuration with it. This makes them useful for environment cloning but unsuited for keeping application and configuration versioned as a single deployable unit.
- ✓
Store configuration in a configuration file (e.g., .ebextensions) included with the application source code.
Why this is correct
Configuration files placed in the .ebextensions directory of your application source bundle are processed by Elastic Beanstalk during environment creation and every deployment, allowing you to define option settings, environment variables, packages, and custom resources declaratively. Because these files live in source control alongside your application code, every versioned build contains its exact configuration, so rolling back to a previous application version also restores the matching configuration automatically. This versioned, source-code-integrated approach is the recommended method for environment configuration.
- ✗
Manually change environment configuration using the Elastic Beanstalk console when needed.
Why it's wrong here
Manually changing configuration in the Elastic Beanstalk console mutates the live environment settings without any record in source control, versioned code, or reusable artifact, so the environment's configuration becomes opaque and unreproducible. These ad-hoc changes are also at risk of being silently overwritten when a subsequent deployment re-applies the environment's saved platform settings. Additionally, they cannot be rolled back as a unit with the application code, making it impossible to audit who changed what or to recreate the environment consistently.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.