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.

• ✗

  Use AWS CloudFormation to update the environment with new configuration

  Why it's wrong here

  AWS CloudFormation can update and manage the Elastic Beanstalk environment's resource configuration—such as instance types, VPC settings, and environment variables—via an environment's option settings, but it cannot inject custom configuration files onto instance filesystems. When you update a CloudFormation stack that contains an Elastic Beanstalk environment, it changes the environment configuration, but it does not trigger a re-deployment of the application source bundle, so any files you need in the instance file system must already exist in the source code or be created by a deployment-time mechanism like .ebextensions.

• ✓

  Use .ebextensions configuration files in the application source bundle

  Why this is correct

  Files placed in the .ebextensions directory of your application source bundle are processed automatically by Elastic Beanstalk during each deployment lifecycle. A .config file in this directory can use the 'files' key to write configuration content directly to absolute paths on the instance, and it can also run commands or container_commands in sequence with deployment events. Because these configuration files are part of the versioned source bundle, they are associated with a specific application version and are re-applied consistently whenever that version is deployed, making this the correct way to inject a configuration file into each instance during deployment.

• ✗

  Use EC2 user-data scripts to download configuration from S3

  Why it's wrong here

  EC2 user-data scripts are executed only once when the EC2 instance first boots, not at every Elastic Beanstalk deployment event. If you provision an environment and later download a new configuration from Amazon S3 via user-data, already-running instances will not execute that script again to download the updated file, so the configuration would become stale after subsequent deployments or environment updates. Additionally, user-data is not tied to the application version or the deployment lifecycle, so it cannot reliably provide per-deployment configuration file injection in a repeatable, versioned manner.

• ✗

  Store configuration in AWS Systems Manager Parameter Store and retrieve it in the application

  Why it's wrong here

  AWS Systems Manager Parameter Store is an external configuration store that requires application-level code changes to retrieve values at runtime through the AWS SDK or CLI. It does not write or inject files onto the instance filesystem, so using Parameter Store would not satisfy a requirement to 'inject files' into the environment; instead it would require the application to be refactored to query parameter values and apply them in code. This runtime dependency also means configuration is not bundled with the application version, making it a different architectural pattern that is inappropriate for a file-injection use case.

Go deeper

Related to this question