DOP-C02 Configuration Management and IaC Practice Question
A DevOps engineer is creating an AWS Elastic Beanstalk environment and needs to ensure that configuration changes are tracked and can be reverted. Which THREE steps should the engineer take to achieve this? (Choose THREE.)
⚠ Common exam trap
Many candidates confuse lifecycle policies (which manage application versions) with configuration versioning, and assuming the console automatically retains configuration history when in fact you must explicitly save configurations as versions.
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
✓
Enable configuration drift detection using AWS Config.
AWS Config can be used to track configuration changes to Elastic Beanstalk resources (e.g., the underlying EC2 instances, security groups, and load balancers) by recording configuration items and detecting drift from the desired state. This allows the DevOps engineer to audit changes and revert to a compliant configuration if needed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable configuration drift detection using AWS Config.
Why this is correct
AWS Config can be enabled to record configuration changes to Elastic Beanstalk environments and their underlying AWS resources (such as EC2 instances, security groups, and load balancers). By authoring or using managed Config rules, you can compare the actual environment settings to the desired baseline and receive SNS notifications or trigger SSM remediation when drift is detected. This provides a continuous, auditable change history and alerts you to unauthorised or accidental configuration modifications, allowing you to restore the correct settings quickly.
- ✗
Use Elastic Beanstalk lifecycle policies to automatically retain old configurations.
Why it's wrong here
Elastic Beanstalk lifecycle policies are specifically used to manage application versions by deleting old ones based on a maximum count or a retention period, thereby preventing storage and quota issues. They do not retain, version, or revert environment configuration settings (option settings, environment variables, or platform configurations). Therefore, lifecycle policies are irrelevant for tracking or restoring previous configuration states—the correct way to do that is with saved configurations (configuration templates).
- ✗
Store configuration templates in the Elastic Beanstalk console, which automatically keeps version history.
Why it's wrong here
The Elastic Beanstalk console allows you to load or save configuration templates, but it does not automatically keep a version history of every configuration change. Each saved configuration must be explicitly created by the user with a unique name; there is no automatic, timestamped snapshot taken when changes are made. Without manual saves, you cannot access previous settings, so relying on the console's 'saved configurations' functionality without deliberately saving each change does not provide automatic versioning.
- ✓
Enable enhanced health reporting and detailed CloudWatch metrics.
Why this is correct
Enhanced health reporting adds detailed environment and instance-level health metrics (such as latency, CPU, and custom metrics) and publishes them to Amazon CloudWatch, enabling you to monitor the operational impact of configuration changes. By combining these metrics with CloudWatch alarms, you can detect sudden degradation or anomalies that may result from a bad configuration change, effectively helping you identify and react to problematic modifications. While it is not a versioning or drift-detection mechanism itself, it provides the observability needed to correlate configuration changes with health effects.
- ✓
Save configuration versions as saved configurations in Elastic Beanstalk.
Why this is correct
Saved configurations (formerly known as configuration templates) in Elastic Beanstalk are immutable snapshots of an environment's option settings—including instance type, environment variables, scaling triggers, and security settings—that you can manually save under a descriptive name. You can later use a saved configuration to create a new environment or update an existing one, effectively reverting to the exact previous settings even after many other changes have been made. Because these snapshots are stored explicitly and can be versioned by name or timestamp, they are the primary built-in way to restore a known-good configuration state.
Go deeper
Related to this question
About these practice questions
One of 1,298 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.