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.

• ✗

  Run a full integration test suite on every commit to the repository.

  Why it's wrong here

  Running a full integration test suite on every commit creates a long feedback loop because integration tests often require external dependencies like databases or message brokers and take significantly longer than unit tests. This practice consumes excessive CI resources and slows developer velocity without a corresponding increase in confidence. Best practice is to run fast unit tests on each commit and reserve full integration suites for merge requests, nightly runs, or only when the affected code paths change.

• ✓

  Separate the build stage from the deploy stage in the pipeline.

  Why this is correct

  Separating the build stage from the deploy stage ensures that a single immutable artifact—such as a Docker image or packaged JAR—is produced once and then promoted through environments (dev, staging, prod) without rebuilding. This eliminates configuration drift and makes the pipeline auditable, because the exact artifact tested can be deployed to production. It also enables independent validation and safe rollback: if a deployment fails, you can redeploy the previous artifact rather than re-running a build that may produce different output.

• ✗

  Build the Docker image in the deploy stage to ensure consistency.

  Why it's wrong here

  Building the Docker image inside the deploy stage conflates build-time concerns with deployment-time runtime concerns, breaking the principle of single-sourced artifacts. If the image is rebuilt separately for each environment, the same commit can yield different binaries depending on when or where the build ran, leading to undiagnosable environment-specific failures. It also prevents standard security practices like scanning the image once before promotion and complicates rollback because the previous production image may not be readily available. Always build and test the image earlier, store it in a registry like Amazon ECR, and then reference that exact tag during deployment.

• ✗

  Use a rolling update with a fixed number of tasks for deployment.

  Why it's wrong here

  Using a rolling update with a fixed number of tasks is risky because the deployment algorithm does not proactively manage capacity; if the new task set fails health checks, the deployment can stall or cause downtime, and the only recovery is a manual intervention or triggering another deployment. Rolling updates also lack fine-grained traffic control, forcing you to rely on instance-level draining rather than shifting percentage-based traffic, which makes rollback abrupt and error-prone. For zero-downtime production deployments, a blue/green strategy—especially when integrated with AWS CodeDeploy and an Application Load Balancer—is preferred because it keeps the old environment warm until the new fleet is fully healthy.

• ✓

  Use a blue/green deployment strategy for the ECS service.

  Why this is correct

  A blue/green deployment for an ECS service provisions a new task set beside the existing one, allowing the new tasks to register with the load balancer and pass health checks before any production traffic is shifted. AWS CodeDeploy orchestrates this by shifting traffic in configurable increments, then deleting the old task set only after successful verification. This gives you zero-downtime deployments and near-instant rollback—if the new version fails, you can switch 100% of traffic back to the blue task set without rebuilding or restarting services, which is a core advantage for ECS workloads that require high availability.

Go deeper

Related to this question