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 CodeDeploy to deploy the Lambda function

  Why it's wrong here

  AWS CodeDeploy is a deployment service that manages traffic shifting and rollbacks for Lambda function versions, but it is not an S3 event source. CodeDeploy only acts when a deployment is explicitly initiated via the CLI, console, or a pipeline; it cannot detect a new object upload to an S3 bucket and automatically trigger a Lambda code update. Even if you ran a CodeDeploy deployment, CloudFormation's template state would remain unchanged, so the function could be updated outside of the stack, but that does not directly address the requirement to force a stack update when the S3 object changes. The fundamental problem here is CloudFormation's diff-based update detection, which CodeDeploy does not influence.

• ✓

  Reference the S3 object version in the Lambda function's Code property to force an update when the version changes

  Why this is correct

  In a CloudFormation template, the Lambda function's Code property, when referencing an S3 bucket, can include the S3ObjectVersion attribute. Because CloudFormation treats any template property change as a stack update trigger, explicitly specifying the object version creates a new template value whenever the zip file in S3 is modified. Without this version, CloudFormation compares only the bucket and key, both of which stay constant, so it considers the resource unrmodified and skips the Lambda update—even if the S3 object's contents were replaced. Adding the S3ObjectVersion forces a resource replacement or update, making it the simplest and most direct way to ensure the stack updates on code changes.

• ✗

  Add a DependsOn clause to the Lambda function resource

  Why it's wrong here

  The DependsOn attribute in CloudFormation is used to establish explicit resource creation or update ordering between resources within the same stack, such as creating a bucket before a custom resource. It gives CloudFormation no information about whether a Lambda function's source code has changed. With a Lambda function whose code lives in S3, CloudFormation's update detection relies entirely on changes to the resource properties—primarily the Code property—so a DependsOn clause does not supply a new property value or signal that the S3 object version has changed. Therefore, even with DependsOn, CloudFormation will still report no update when the zip file is re-uploaded to the same S3 key.

• ✗

  Use AWS CodePipeline to automatically update the stack when the S3 object changes

  Why it's wrong here

  AWS CodePipeline can orchestrate a full CI/CD workflow, including detecting S3 source changes and triggering a CloudFormation stack update, so it is technically feasible. However, it is a heavyweight solution when the core issue is that the template's Code property does not change when the S3 object's contents change; CodePipeline would invoke UpdateStack, but CloudFormation would still see the same bucket/key and skip the Lambda update. To make CodePipeline work, you'd still need to incorporate the S3 object version (or a similar unique identifier) into the template parameters or function code, which means the version reference is the true root-cause fix. Given the requirement asks for what the engineer should do directly with the template, adding the S3ObjectVersion is simpler and avoids unnecessary pipeline infrastructure.

Go deeper

Related to this question