DOP-C02 SDLC Automation 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.

• ✓

  Add a DependsOn attribute in the CloudFormation template to ensure the IAM role is created before the Lambda function.

  Why this is correct

  DependsOn is the correct CloudFormation mechanism to explicitly control resource creation order when there is no implicit dependency. Even though CloudFormation automatically creates a dependency when you use Ref or GetAtt in a resource property, there are cases where the Lambda function's IAM role ARN is substituted indirectly (e.g., via a parameter or a Fn::Sub in a string), so CloudFormation cannot infer the ordering. Adding DependsOn: IamRole to the Lambda function resource guarantees that the IAM role is fully created before the Lambda function is provisioned, preventing the deployment failure that occurs when Lambda tries to use a role that does not yet exist.

• ✗

  Create the IAM role in a separate CodeBuild action before the deploy stage.

  Why it's wrong here

  Creating the IAM role in a separate CodeBuild action before the deploy stage moves infrastructure provisioning outside of CloudFormation, which breaks IaC best practices and introduces drift. The CodeBuild action would require privileged IAM credentials to call iam:CreateRole and would not be idempotent or rollback-safe, so re-running the pipeline could fail if the role already exists. It also fragments the dependency chain, as the Lambda function in the CloudFormation stack assumes the role is already present, whereas a DependsOn attribute keeps the ordering logical and scoped inside the same stack.

• ✗

  Add a wait condition in the CloudFormation template.

  Why it's wrong here

  Wait conditions are designed to make CloudFormation pause indefinitely until an external signal is sent via a pre-signed URL or a CloudFormation wait condition handle, typically from an EC2 or on-premises process. They do not influence the relative creation order of resources inside the template; the Lambda function and IAM role would still be created in whatever order the resource scheduler chooses. Adding a wait condition would add a timeout and complexity without solving the dependency, and it is entirely the wrong tool for an internal ordering constraint.

• ✗

  Separate the IAM role into a nested stack and reference it.

  Why it's wrong here

  Nested stacks do not introduce any ordering guarantee between resources in the parent stack and resources in the nested stack unless the parent stack explicitly uses DependsOn on the nested stack resource. Merely moving the IAM role into a nested stack and referencing its output means the parent stack's Lambda function may be created before the nested stack finishes deploying the role. To actually enforce ordering, you would still need to add a DependsOn on the nested stack, which is more complex than simply using DependsOn on the Lambda function directly within the same stack.

Go deeper

Related to this question