DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS Elastic Beanstalk to deploy a web application. The application requires environment-specific configuration values (database URL, API keys) that must be stored securely and rotated automatically. The team uses AWS Secrets Manager. Which configuration management strategy should the team implement to securely inject secrets into the Elastic Beanstalk environment?
⚠ Common exam trap
A common mix-up: candidates assume CloudFormation dynamic references (Option D) are the best fit for automatic rotation, but they only inject secrets at deployment time and do not handle in-place rotation without a stack update, whereas platform hooks can be used to fetch the latest secret on every instance start or 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
✓
Use an Elastic Beanstalk platform hook script that retrieves secrets from Secrets Manager and sets them as environment variables.
Elastic Beanstalk platform hooks allow custom scripts to run during deployment, enabling retrieval of secrets from AWS Secrets Manager and setting them as environment variables before the application starts. This approach keeps secrets out of the environment configuration and supports automatic rotation by having the script fetch the latest secret value on each deployment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the secrets in the Elastic Beanstalk environment configuration as plain text under 'aws:elasticbeanstalk:application:environment'.
Why it's wrong here
Storing secrets as plain text under 'aws:elasticbeanstalk:application:environment' exposes them in the Elastic Beanstalk environment configuration, which can be viewed via the console, API, or configuration files in source control. Elastic Beanstalk does not encrypt these property values at rest, and they are passed as plaintext environment variables to each instance, where they can be read by any process or user with instance access. This directly violates secrets-management best practices and should be avoided.
- ✗
Configure Secrets Manager to automatically push secrets to Elastic Beanstalk environment properties.
Why it's wrong here
Secrets Manager provides neither a native push mechanism nor an integration that automatically writes secret values into Elastic Beanstalk environment properties. Its rotation and retrieval model is pull-based: applications call the GetSecretValue API to fetch secrets on demand. Even if you attempted to sync secrets to environment properties, Elastic Beanstalk environment variables are static for a deployment and would not update when secrets rotate, so this option is technically unworkable.
- ✓
Use an Elastic Beanstalk platform hook script that retrieves secrets from Secrets Manager and sets them as environment variables.
Why this is correct
An Elastic Beanstalk platform hook, such as a script in the .platform/hooks/postdeploy directory, runs on the instance during deployment and can call the AWS CLI or SDK to retrieve secrets from Secrets Manager using the instance role's IAM permissions. The script can then export the secret values as environment variables into the application runtime context (e.g., by writing to /etc/profile.d or a systemd environment file) before the app starts. This keeps secrets out of the environment configuration and source code, and it supports rotation by re-running the hook on subsequent deployments.
- ✗
Use AWS CloudFormation dynamic references to inject secrets into the Elastic Beanstalk environment.
Why it's wrong here
CloudFormation dynamic references like {{resolve:secretsmanager:...}} are only resolved for supported CloudFormation resource properties; Elastic Beanstalk environment options such as 'aws:elasticbeanstalk:application:environment' are configuration option settings, not resource properties that support dynamic reference resolution. When used in an AWS::ElasticBeanstalk::ConfigurationTemplate or Environment resource, the dynamic reference would be passed through as a literal string rather than being replaced with the secret value. Therefore this mechanism cannot inject secrets into an Elastic Beanstalk environment, making the option invalid.
Go deeper
Related to this question
About these practice questions
One of 1,487 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 →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An organization uses AWS Elastic Beanstalk to deploy a Node.js application. The application requires access to an Amazon RDS database. The database credentials are stored in AWS Secrets Manager. How should the Elastic Beanstalk environment be configured to securely retrieve the database credentials at runtime?
medium- A.In the Elastic Beanstalk environment properties, set the database password to the ARN of the secret in Secrets Manager.
- B.Configure the Elastic Beanstalk environment to use the Amazon RDS integration feature, and select the option to retrieve credentials from Secrets Manager in the environment's software configuration.
- ✓ C.Use a configuration file (.ebextensions) to define an option setting that retrieves the secret from Secrets Manager and sets it as an environment variable.
- D.Modify the EC2 instance profile of the Elastic Beanstalk environment to grant read access to the Secrets Manager secret, and use the AWS CLI in the application code to retrieve the secret.
Why C: The correct approach is to grant the EC2 instance profile permissions to read the Secrets Manager secret, and then have the application retrieve the secret at runtime using the AWS CLI or SDK. This avoids hardcoding credentials and supports dynamic retrieval, including secret rotation. Option C is flawed because .ebextensions option settings are static and cannot fetch secrets; scripts can fetch secrets but they run at deployment time, not at runtime, and cannot update environment variables dynamically for rotated secrets.
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.