SOA-C02 Deployment, Provisioning, and Automation Practice Question
A DevOps engineer is designing a CI/CD pipeline for a microservices application hosted on Amazon ECS with Fargate. The team wants to deploy updates to the services without downtime. The current pipeline builds a Docker image, pushes it to Amazon ECR, and updates the ECS service using AWS CodeDeploy with a blue/green deployment. However, during the deployment, the new tasks fail to start due to an incorrect environment variable. The engineer wants to validate the task definition before the actual deployment. What should the engineer do?
⚠ Common exam trap
The trap is that candidates focus on 'monitoring' or 'scaling' as the safety mechanism, missing that the question explicitly asks for pre-deployment validation, which only a CodeDeploy lifecycle hook can provide.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure CodeDeploy to use a validation hook with an AWS Lambda function that tests the new task definition before shifting traffic.
AWS CodeDeploy for ECS supports lifecycle event hooks, including a BeforeAllowTraffic hook that runs an AWS Lambda function before traffic is shifted to the replacement task set. The Lambda can inspect the new task definition, verify environment variables, and fail the deployment if validation fails, preventing the bad configuration from ever receiving production traffic. This directly addresses the requirement to validate the task definition before the actual deployment.
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 Amazon CloudWatch Synthetics canaries to monitor the health of the new tasks after deployment.
Why it's wrong here
Amazon CloudWatch Synthetics canaries run constantly after deployment to probe endpoints, capture visual regressions, and verify user flows, but they are not a deployment gate. A canary cannot be invoked synchronously during the CodeDeploy lifecycle to evaluate a new task set before it receives traffic. By the time a canary runs, the new task definition is already serving production traffic, so it does not provide pre-shift validation of the task definition.
- ✗
Run the Docker container locally using 'docker run' with the same environment variables to verify the configuration.
Why it's wrong here
Running the same container locally with `docker run` does not replicate the Fargate environment: the Linux kernel and runtime version, the network mode and VPC connectivity, IAM roles assumed through the task definition, security group rules, Amazon EFS access, or the exact CPU/memory limits are all different. A container that starts on a developer laptop can fail on Fargate because it lacks the necessary IAM permissions to retrieve secrets, or because its entrypoint expects an orchestrator-provided endpoint that does not exist locally. Therefore, local execution is an unreliable proxy for task definition validation and cannot catch issues that only appear in the actual ECS environment.
- ✗
Use Amazon ECS Service Auto Scaling to gradually increase the number of tasks and monitor CPU utilization.
Why it's wrong here
Amazon ECS Service Auto Scaling changes the desired count of tasks based on utilization metrics or a scheduled policy, and it is not a mechanism for validating a task definition. Even if you gradually increase the task count while watching CPU, the new tasks become part of the running service and receive traffic immediately; there is no isolated pre-flight stage. This approach does not test the container's health, configuration, or dependencies before the new task definition is fully exposed, so it cannot catch invalid definitions before deployment.
- ✓
Configure CodeDeploy to use a validation hook with an AWS Lambda function that tests the new task definition before shifting traffic.
Why this is correct
This is correct because CodeDeploy for Amazon ECS uses an AppSpec file that can define a `BeforeAllowTraffic` lifecycle hook, which invokes an AWS Lambda function after the new task set is registered with the target group but before any production traffic is shifted. The Lambda can perform an HTTP health check against the new task's endpoint, verify the container is listening on the expected port, or check internal state, and if it fails, CodeDeploy aborts the deployment and rolls back to the original task set. This provides a true pre-flight validation gate for the task definition within the actual Fargate environment, ensuring that only valid task definitions ever receive traffic.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.