DOP-C02 Configuration Management and IaC Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  As environment properties in the Elastic Beanstalk environment

  Why this is correct

  Elastic Beanstalk's native Environment Properties are key-value pairs defined at the environment level and injected directly into the operating system as environment variables on each EC2 instance, or as container environment variables for ECS-based platforms. This allows platform-managed settings to be consumed by your application with no extra code, and they are automatically updated on configuration changes without requiring a new deployment. They also support encrypted values when set through the AWS CLI or saved configurations with KMS, making them the standard, service-supported approach.

• ✗

  In the EC2 User Data script

  Why it's wrong here

  An EC2 User Data script executes only once during initial instance bootstrap, and any environment variables it exports are confined to that shell session, disappearing on reboot or after the process exits. Using it to configure your app would also duplicate logic across instances and fail on instance replacements during rolling or immutable deployments, as Elastic Beanstalk would not apply those variables to the new fleet. Furthermore, it is not a declarative configuration mechanism, offers no centralized management, and can accidentally expose secrets in the system log.

• ✗

  In the instance metadata

  Why it's wrong here

  Instance metadata (IMDS) is a service provided by the AWS hypervisor that offers immutable facts about the instance—such as instance ID, AMI ID, instance type, and network info—but it does not automatically include any custom application configuration or user-defined key-value pairs. While you could write a script to publish your own data to an instance metadata endpoint, that is not a supported or scalable pattern on Elastic Beanstalk, and the feature is intended for AWS-internal data, not app settings. Reading metadata also requires retrieval code and does not integrate with Elastic Beanstalk's health, rollback, or update mechanisms.

• ✗

  In the application code

  Why it's wrong here

  Embedding configuration values directly in the application source code couples your software to a specific environment, so promoting a build from staging to production requires modifying, recompiling, and redeploying the artifact, which negates the benefit of immutable deployment pipelines. It also bypasses Elastic Beanstalk's configuration management features, prevents operations teams from adjusting settings without code review, and creates a security risk if secrets are committed to version control. According to the twelve-factor app methodology, environment-specific configuration must be externalized to the runtime environment, not hard-coded.

Go deeper

Related to this question