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 stage that runs a performance or load test.

  Why this is correct

  Running a performance/load test stage (e.g., using AWS CodeBuild with Apache JMeter or Artillery against the deployed API endpoint) validates that the serverless application can sustain expected concurrency and throughput without exceeding Lambda concurrency limits or API Gateway throttling quotas. It catches issues like cold start latency, inadequate memory allocation, or downstream dependency bottlenecks that unit tests miss. In serverless, load tests also confirm that provisioned concurrency or auto-scaling behavior works as intended under spike traffic.

• ✗

  Add a stage that automatically rolls back the deployment if tests fail.

  Why it's wrong here

  Adding a stage that automatically rolls back on test failure conflates detection with remediation; rollback is a separate post-deployment safety mechanism (e.g., CodeDeploy auto-rollback or CloudFormation stack rollback), not a test that validates behavior. CodePipeline supports a callback-based rollback via Lambda only after a test/approval action signals a failure, but the stage itself doesn't exercise the application or produce evidence about quality. Furthermore, rolling back a serverless deployment can be complex if the stack update removed resources or if the prior version's environment variables/aliases changed, so it should be a codified deployment strategy (like canary) rather than a standalone stage.

• ✓

  Add a manual approval stage after testing before promoting to production.

  Why this is correct

  Inserting a manual approval step (using CodePipeline's Manual Approval action with SNS notification) after automated tests and before the production deployment provides a human checkpoint for reviewing test results, CloudWatch metrics, and cost or compliance implications of the serverless release. This is especially valuable in serverless because infrastructure changes (IAM permissions, event source mappings, VPC config) can have subtle cross-account effects that automated tests miss. The approval gate also serves as an audit trail for change management requirements, and it can require a group of approved users (via IAM) to prevent single-person releases.

• ✗

  Add a stage that deploys the application to a separate production environment.

  Why it's wrong here

  Deploying to a 'separate production environment' is a contradiction—the purpose of the pipeline is to promote to a controlled production; a second production environment creates unnecessary duplication and drift, and it does not validate the same infrastructure as the actual production deployment. In serverless, resources like DynamoDB tables, SQS queues, or Lambda versions have global names, so a second 'production' would either conflict or require different resource naming, making the test invalid. Testing must occur in a pre-production environment (dev/staging) that mirrors production configuration, not by creating another production environment.

• ✓

  Add a stage after deployment that runs integration tests against the deployed API.

  Why this is correct

  Running integration tests against the deployed API in CodePipeline (e.g., in a CodeBuild action that invokes the API Gateway endpoints with test payloads and asserts on status codes, schemas, and downstream data consistency) verifies that the deployed Lambda function, API Gateway routes, and IAM roles are correctly wired together. Unlike unit tests that run before deployment, these tests exercise the actual resource configuration in the target environment—catching things like missing environment variables, wrong alias/version ARNs, or misconfigured event source mappings. They also validate that the deployment configuration (e.g., CloudFormation output values plugged into the API) is correctly applied.

Go deeper

Related to this question