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 saved configurations to create reusable environment templates

  Why this is correct

  Saved configurations serialize an environment's settings—such as instance type, autoscaling limits, environment variables, and security group rules—into a reusable template. A DevOps team can save a tuned production environment's configuration and then apply that exact template when creating a new environment, either through the Elastic Beanstalk console or the eb config save command. This ensures consistency across environments, but it should not be used for deploying code; it only captures environment-level options.

• ✗

  Create a custom AMI with the desired configuration

  Why it's wrong here

  While a custom AMI can bake in a desired OS configuration, Elastic Beanstalk platforms are managed by AWS, and replacing the base AMI leaves the instance outside the platform's managed update path. Custom AMIs also prevent seamless platform version upgrades, and scripts/configuration in .ebextensions or platform hooks would be applied on top of a non-standard base image, leading to unpredictable results. Elastic Beanstalk explicitly advises using platform hooks and .ebextensions for custom configuration instead of building custom AMIs.

• ✗

  Use OpsWorks to manage the instances

  Why it's wrong here

  AWS OpsWorks is a separate configuration management service that uses Chef or Puppet cookbooks to manage instances, and it has no native integration with the Elastic Beanstalk environment lifecycle. Beanstalk already provides its own orchestration for deployment, patching, and scaling, so introducing OpsWorks as an external management layer would duplicate and conflict with EB's managed operations. The correct approach is to use Beanstalk's built-in customization mechanisms rather than pulling in a completely different service.

• ✓

  Use .ebextensions configuration files

  Why this is correct

  The .ebextensions directory in your application source bundle can contain YAML or JSON configuration files that instruct Elastic Beanstalk to install packages, create files, run commands, and define services—all during the instance provisioning process. Because these files are versioned with your application code, the same configuration is reproducibly applied across every deployment, which is far more predictable than manually configuring a base AMI. For settings that depend on the environment, you can reference Beanstalk resource names via Ref and other intrinsic functions within these config files.

• ✓

  Use platform hooks to run custom scripts during deployment

  Why this is correct

  Platform hooks are shell scripts placed under the .platform/hooks directory (for example, appdeploy/predeploy and appdeploy/postdeploy subfolders) that Elastic Beanstalk executes at specific lifecycle events, giving you precise control over what happens before and after each deployment. Unlike .ebextensions commands that run at a single stage of provisioning, these hooks run at defined phases of the deployment flow—making them ideal for database migrations or clearing caches immediately before new code goes live. They are the recommended, script-friendly mechanism because they are easy to debug and are automatically retained even as the underlying platform version updates.

Go deeper

Related to this question