SOA-C02 Deployment, Provisioning, and Automation Practice Question

A SysOps administrator is deploying a CloudFormation stack that includes an AWS::ECS::Service resource. The service uses a task definition that references a container image stored in Amazon ECR. The stack creation fails with the error: 'Unable to assume the service-linked role.' What is the MOST likely cause?

⚠ Common exam trap

SOA-C02 often tests IAM roles and permissions, and candidates may confuse the task execution role with the service-linked role; the trap is assuming the error is due to missing ECR permissions when it's actually about the ECS service-linked role.

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

✓

The ECS service-linked role does not exist in the account.

The error 'Unable to assume the service-linked role' indicates that the ECS service-linked role (AWSServiceRoleForECS) does not exist in the account. CloudFormation attempts to create the ECS service, which requires this role to manage resources on your behalf. If the role is missing, the stack creation fails. The most likely cause is that the role has not been created, perhaps because ECS was never used in this account before.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The task execution role does not have permissions to pull the container image from ECR.
Why it's wrong here
A missing or misconfigured task execution role would not block CloudFormation from creating the stack. CloudFormation only passes that role ARN into the ECS task definition; it does not evaluate whether the role can pull images. The failure would occur later at task launch as a `ResourceInitializationError` or `CannotPullContainerError` in the ECS service events, not as a formation-stack creation error.
✗
The CloudFormation service role does not have permission to create ECS resources.
Why it's wrong here
If the CloudFormation service role lacked `ecs:CreateCluster` or `ecs:CreateService`, the stack would fail with an `AccessDenied` error from the ECS API, and the 'status reason' would reference the missing action and the service role ARN. In contrast, a missing ECS service-linked role produces a dependency/role-not-found error during resource provisioning. The distinction is an IAM authorization failure versus an AWS service prerequisite failure.
✗
The ECR repository policy does not grant access to the ECS service.
Why it's wrong here
An ECR repository policy controls which IAM principals may pull images, typically for cross-account sharing; it does not interact with the ECS service-linked role. In the same account, the task execution role is what authorizes ECR pulls at container startup. A restrictive repository policy would still cause task-start `CannotPullContainerError` events, but it cannot be the reason CloudFormation itself fails while creating the ECS stack.
✓
The ECS service-linked role does not exist in the account.
Why this is correct
ECS requires the `AWSServiceRoleForECS` service-linked role so that the ECS service can manage resources such as ENIs, load balancer targets, and Auto Scaling groups on your behalf. If this role has never been created in the account, CloudFormation's calls to create the cluster or service return an error indicating that the service-linked role is not found, causing the stack to roll back. The role can be created with `iam:CreateServiceLinkedRole` or by a prior ECS console/API call; CloudFormation will not create it automatically for you.

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question