SOA-C02 Deployment, Provisioning, and Automation Practice Question
A company deploys microservices on Amazon ECS using Fargate. The deployment is managed by AWS CodePipeline. The administrator notices that deployments sometimes fail because the new task definition is not registered before the deployment. Which THREE steps should the administrator take to resolve this issue? (Choose THREE.)
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
✓
Ensure that the task definition is registered in the CodePipeline build stage before the deploy stage.
The issue is that the task definition must be registered before the ECS service update. Option A is correct because registering the task definition in the build stage ensures it is available for the deploy stage. Option C is correct because the ECS deploy action in CodePipeline automatically handles task definition registration and service update. Option D is correct because adding a CLI or SDK step explicitly registers the task definition. Option B is incorrect because the task definition should be registered automatically, not manually. Option E is incorrect because ECR stores container images, not task definitions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Ensure that the task definition is registered in the CodePipeline build stage before the deploy stage.
Why this is correct
In CodePipeline, the Deploy stage's ECS deployment action expects an ARN of an already-registered task definition, typically passed via artifacts from the Build stage. If the build stage does not explicitly register the task definition (e.g., using aws ecs register-task-definition or the ECS deploy action's automatic registration), the deploy action may reference a stale or nonexistent revision, causing the deployment to fail or roll back. Registration must happen before the deploy stage consumes the artifact, ensuring the action has a valid family:revision to run.
- ✗
Manually update the ECS service with the new task definition after the pipeline runs.
Why it's wrong here
Manually updating the ECS service after the pipeline completes introduces a service-action gap: the pipeline reports success even though the actual deployment occurs outside of its automated validation, rollback, and approval gates. This defeats the purpose of CI/CD because changes are not tracked as part of the pipeline's execution history, and it allows configuration drift between what was tested and what is actually running. It also requires human intervention, increasing the risk of error, inconsistency, and lack of auditability—all unacceptable for a production microservices environment.
- ✓
Use the ECS deploy action in CodePipeline which automatically registers the task definition.
Why this is correct
CodePipeline's ECS-to-CodeDeploy action (deploy action) can be configured with the 'DeploymentControllerType' set to ECS, and it can be pointed to a task definition file (taskdef.json) stored as an artifact. In this mode, the deploy action itself invokes Amazon ECS to register the task definition from that file, so you do not need a separate registration step. This approach centralizes registration and deployment into one action, but it must be explicitly configured—using the wrong controller type or omitting the task definition file will cause the action to fail.
- ✓
Add a step in the pipeline to register the task definition using the AWS CLI or SDK.
Why this is correct
Adding an explicit pipeline step—such as an AWS CLI command (aws ecs register-task-definition --cli-input-json file://taskdef.json) or an SDK call—before the deploy stage allows full control over the registration process, including setting the correct family, network mode, and compatibility (FARGATE). This step must produce an artifact containing the registered task definition ARN for use by the deploy stage, and it should be placed after the build (image build) and before the actual ECS deployment. It is a valid automation pattern when the built-in ECS deploy action's automatic registration is not available or when you need custom logic.
- ✗
Store the task definition in Amazon ECR alongside the container image.
Why it's wrong here
Amazon ECR is a container image registry, not a store for ECS task definitions; it stores Docker images and OCI artifacts but has no native concept of task definitions. While you could technically store a JSON file in an image layer, doing so does not make it accessible to CodePipeline or ECS without a separate extraction and registration process. The correct place for a task definition is the ECS service itself (registered via API) or as an artifact in CodePipeline (e.g., S3), not inside ECR, which would add an unnecessary and unreferenced side channel.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.