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.

• ✓

  Use the AWS Serverless Application Model (SAM) with CodePipeline, and pass environment parameters as CloudFormation parameter overrides.

  Why this is correct

  SAM is the only option that natively pairs with CodePipeline for serverless deployments: the pipeline can run `sam build` and `sam package` in a CodeBuild stage, then use a CloudFormation change set via the `CreateReplaceChangeSet` action. By specifying a `ParameterOverrides` JSON file (e.g., `stageName`, `environment`, `vpcConfig`) on that action, each environment (dev, test, prod) reuses the same pipeline definition yet receives its own configuration without duplicating stages or using manual scripts. SAM also generates the Lambda function, event sources, and permissions as a CloudFormation template, so environment-specific values propagate consistently through `AWS::Serverless::Function` properties and `!Ref` parameters.

• ✗

  Use CodeBuild to package the Lambda code and then use CloudFormation with parameters for each environment.

  Why it's wrong here

  This approach can technically produce an environment-specific stack, but it bypasses CodePipeline's orchestration and audit trail: the engineer would need to manually trigger a CloudFormation create/update per environment or wire separate invocations outside the pipeline. Unlike SAM, there is no built-in `ParameterOverrides` mechanism tied to a deployment action, so passing parameters requires custom `--parameter-overrides` CLI calls or template modifications. It also forces a packaging step (e.g., `aws cloudformation package`) that replicates what SAM does implicitly, and it does not provide the same rollback or change-set visibility that CodePipeline's CloudFormation deployment action offers, making it a less integrated and more error-prone choice.

• ✗

  Use CodeDeploy with a deployment configuration that deploys to all environments sequentially.

  Why it's wrong here

  CodeDeploy is an application-deployment service that manages traffic shifting for EC2, Lambda, or ECS; it does not define CloudFormation stack parameters or select different template values per environment. A single deployment configuration (e.g., `AllAtOnce` or `Canary10Percent5Minutes`) is applied to a fixed set of deployment-group targets, not to per-environment infrastructure templates. You would need separate CodeDeploy applications and deployment groups for each environment anyway, and even then it cannot substitute for the parameter-driven CloudFormation template that the correct SAM pipeline uses. Thus it is a deployment-mechanism answer, not a configuration-management answer, and it ignores the core need to pass environment-specific parameters.

• ✗

  Use CodePipeline with separate CodeBuild projects for each environment.

  Why it's wrong here

  This option wrongly equates pipeline structure with configuration management: having a separate CodeBuild project per environment means duplicating buildspecs and logic, and you still have to decide where environment variables come from (e.g., hardcoded in each project's environment or in a parameter store). It does not leverage CloudFormation parameter overrides, so Lambda function configuration, environment variables, and resource properties would remain inconsistent or need manual syncing across projects. Moreover, it increases maintenance overhead and risks drift because a change to a shared build behavior must be applied to every project. A single CodePipeline with a parameterized SAM template is the standard way to reuse build/package logic while toggling environment settings.

Go deeper

Related to this question