DOP-C02 Configuration Management and IaC Practice Question

A company uses AWS Elastic Beanstalk for application deployments. They want to integrate infrastructure-as-code practices using AWS CloudFormation. Which approach allows them to manage the Elastic Beanstalk environment and underlying resources as part of a CloudFormation stack?

⚠ Common exam trap

DOP-C02 often tests whether candidates know that Elastic Beanstalk has first-class CloudFormation resource types — many assume a custom resource or import is needed because Beanstalk 'manages its own resources.'

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

✓

Define the Elastic Beanstalk environment in the CloudFormation template using the AWS::ElasticBeanstalk::Environment resource.

CloudFormation natively supports Elastic Beanstalk through the AWS::ElasticBeanstalk::Environment and AWS::ElasticBeanstalk::Application resource types. Defining the environment in the template lets CloudFormation create, update, and delete the environment and its underlying resources (EC2, ASG, ELB, security groups) as part of the stack, giving full IaC lifecycle management.

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 a custom resource backed by a Lambda function to create the Elastic Beanstalk environment.
Why it's wrong here
A custom resource backed by a Lambda function forces you to write and maintain custom provisioning logic, including create, update, and delete handlers, while also managing error handling and rollbacks. By contrast, AWS CloudFormation natively provides the AWS::ElasticBeanstalk::Environment resource type, so introducing a Lambda-backed custom resource adds unnecessary complexity, potential failure points, and makes your stack harder to review and maintain.
✗
Use the CloudFormation import feature to bring the existing Elastic Beanstalk environment into the stack.
Why it's wrong here
CloudFormation's import feature is designed only to adopt resources that are not currently managed by any stack, and it requires the resource type to be import-supported. An existing Elastic Beanstalk environment you want to manage would need to be imported before it can be referenced, but the purpose here is to define and provision the environment in a template; import does not let you author a resource from scratch, and AWS::ElasticBeanstalk::Environment is not a supported import type.
✗
Export the Elastic Beanstalk environment configuration as a CloudFormation template from the console.
Why it's wrong here
The Elastic Beanstalk console offers a 'Download' or 'Saved configuration' feature that produces an EB-specific configuration file (a YAML/JSON document using option settings), not a CloudFormation template. There is no console action that exports an environment's definition as an AWS::ElasticBeanstalk::Environment resource; attempting to use such a downloaded file in CloudFormation would fail, because it does not conform to the CloudFormation resource schema.
✓
Define the Elastic Beanstalk environment in the CloudFormation template using the AWS::ElasticBeanstalk::Environment resource.
Why this is correct
The correct approach is to declare the Elastic Beanstalk environment directly in your CloudFormation template with the AWS::ElasticBeanstalk::Environment resource. This native resource supports properties such as ApplicationName, SolutionStackName or PlatformArn, OptionSettings, and Tags, allowing CloudFormation to create and manage the environment as part of the stack. It integrates cleanly with other stack resources and avoids custom code or workarounds.

Go deeper

DOP-C02 Configuration Management and IaC Practice Question

Why each option matters

Option-by-option breakdown

Related to this question