DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS CodePipeline to deploy a Node.js application to AWS Elastic Beanstalk. The pipeline includes a build stage using AWS CodeBuild. Developers notice that the deployed application occasionally crashes due to missing environment variables that were configured in the Elastic Beanstalk environment but not passed from CodeBuild. What is the MOST efficient way to ensure the environment variables are consistently applied?
⚠ Common exam trap
Many candidates assume runtime parameter retrieval (e.g., from Parameter Store or Secrets Manager) is the best practice for all scenarios, but for environment variables required at process startup in Elastic Beanstalk, .ebextensions provide a more reliable and simpler solution that avoids application code changes and ensures variables are set before the application runs.
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
✓
Define environment variables in the source code using .ebextensions configuration files.
Ebextensions configuration files allow you to define environment variables declaratively in the source code, ensuring they are consistently applied during every deployment via CodePipeline. This approach eliminates the dependency on runtime or manual steps, as the Elastic Beanstalk environment automatically reads these files during environment creation and updates. It integrates seamlessly with CodeBuild and CodePipeline, making it the most efficient and reliable method for maintaining environment variable consistency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Define environment variables in the source code using .ebextensions configuration files.
Why this is correct
Commit the variables in a .ebextensions/*.config file (e.g., option_settings for namespace aws:elasticbeanstalk:application:environment). CodePipeline packages the entire source into the application version, and the Elastic Beanstalk deployment agent processes this file automatically, injecting the values into the Node.js process's environment. This makes environment configuration declarative, versioned, and reproducible for every pipeline run, eliminating manual or post-deployment steps.
- ✗
Update the environment variables manually in the Elastic Beanstalk console after each deployment.
Why it's wrong here
Manually editing environment properties in the Elastic Beanstalk console after each pipeline execution breaks the automation guarantee of CodePipeline and introduces configuration drift—if the environment is rebuilt, cloned, or replaced, these values are lost. It also creates a window during which the running application has stale or incorrect variables, and there is no audit trail or easy rollback. Environment settings defined outside the source repository cannot be validated as part of the pipeline and are inherently error-prone.
- ✗
Use the aws elasticbeanstalk update-environment CLI command after the pipeline completes.
Why it's wrong here
Adding an aws elasticbeanstalk update-environment CLI invocation after the pipeline completes introduces a separate, post-deployment step that requires a custom action (e.g., a Lambda function or a CodeBuild stage) and makes the pipeline vulnerable to false success—the deployment can finish, but the update-environment call may fail or be delayed, leaving the environment inconsistent. This method also triggers an environment update after the code is already live, causing a second round of instance restarts and potential health-check flapping, and it does not version the configuration alongside the application artifact.
- ✗
Store environment variables in AWS Systems Manager Parameter Store and have the application retrieve them at runtime.
Why it's wrong here
Fetching variables from Systems Manager Parameter Store at runtime is a legitimate pattern for secrets, but it does not define Elastic Beanstalk environment variables—it pushes the retrieval responsibility into the Node.js application, requiring additional SDK dependencies, an instance role with Parameter Store permissions, and code modifications for every variable. It also fails the build stage of CodePipeline, because CodeBuild often needs environment values (e.g., NPM registry credentials, feature flags) before the artifact is assembled, and runtime retrieval is too late. As a result, the environment properties in the EB configuration remain unset, and any process or tooling that expects them in process.env will see undefined values.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 251 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.