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 .ebextensions configuration files in the application source bundle to install packages and run commands.

  Why this is correct

  Elastic Beanstalk automatically processes the .ebextensions directory inside your source bundle, passing any .config files (YAML/JSON) to the CreateStack operation as AWS::CloudFormation::Init metadata. The packages key lets you specify packages like yum, rpm, or gem, while the commands and container_commands keys execute shell commands at specific points in the deployment lifecycle. Because these run on every instance before the application is deployed, they give you a supported, idempotent way to install dependencies and tweak configuration without managing your own AMI. This is the most portable and preferred method for most customizations.

• ✗

  Use AWS OpsWorks to manage the instances instead of Elastic Beanstalk.

  Why it's wrong here

  AWS OpsWorks is a separate configuration-management service based on Chef or Puppet, not a feature inside Elastic Beanstalk. Moving your environment to OpsWorks would require you to rebuild your application stack, manage the EC2 instances, load balancers, and similar resources yourself, and you'd lose the managed deployment and scaling workflows that Elastic Beanstalk provides. The question is about customizing instances within an EB environment, so recommending a different service entirely does not answer it and would create extra operational overhead and risk.

• ✓

  Create a custom AMI and specify it in the Elastic Beanstalk environment configuration.

  Why this is correct

  You can launch a base instance from the Elastic Beanstalk platform AMI, install any packages or libraries you need, and then use EC2 create-image to bake a custom AMI. Specify that AMI via the 'Custom AMI' field on the environment configuration or by setting the 'aws:autoscaling:launchconfiguration' namespace's 'ami_id' option. This is a valid alternative to .ebextensions because it avoids repeated setup and makes instance scale-out faster, but you must keep the AMI patched and compatible with the underlying platform. If you then update the platform version, you must rebuild the AMI, so it's best for heavyweight dependencies that change rarely.

• ✗

  Add user data to the Auto Scaling group launch configuration that Elastic Beanstalk creates.

  Why it's wrong here

  Elastic Beanstalk creates and manages the Auto Scaling launch configuration on your behalf; there is no supported console or EB setting to inject raw user-data. If you were to use the EC2 API or CLI to patch the launch configuration with user data, your changes would not be reflected in the environment lifecycle, could be overwritten by the next platform update, and would not run at the right point in Elastic Beanstalk's own bootstrap sequence. The native user data script already contains the EB starting agent and any .ebextensions directives, so adding your own is not only unsupported but can break instance initialization. Prefer .ebextensions, which EB applies in a known order and idempotently.

• ✗

  Modify the CloudFormation template generated by Elastic Beanstalk directly.

  Why it's wrong here

  Elastic Beanstalk generates a nested AWS CloudFormation stack that it fully owns, and this template is not meant to be edited by customers. Directly modifying the template via the CloudFormation console or CLI causes stack drift, and EB will reject or overwrite your changes on the next configuration update, often leaving the environment in a failed state. The supported way to inject custom CloudFormation resources is to include an 'Resources' section inside .ebextensions configs or to use a custom resource for complex IaC. There is no way to persist edits to the root template, so it's not a valid approach.

Go deeper

Related to this question