DOP-C02 SDLC Automation Practice Question
An organization uses AWS CodePipeline to orchestrate deployments to multiple environments (dev, test, prod). Each environment uses a different AWS account. The pipeline uses cross-account actions with IAM roles. Recently, the pipeline failed at the deploy stage for the prod account with the error 'Access Denied' when assuming the cross-account role. The role ARN is correct and the trust policy allows the pipeline's service role. What is the MOST likely cause?
⚠ Common exam trap
The trap here is that candidates often focus on the cross-account role's trust policy or permissions, forgetting that the pipeline's service role also needs explicit `sts:AssumeRole` permission, which is a separate IAM policy requirement.
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 pipeline's service role lacks the `sts:AssumeRole` permission for the cross-account role.
The pipeline's service role must have an `sts:AssumeRole` permission on the cross-account role to perform the role assumption. Even if the trust policy on the cross-account role allows the pipeline's service role, the pipeline's service role itself needs an IAM policy granting `sts:AssumeRole` for the cross-account role ARN. Without this permission, the `AssumeRole` API call fails with 'Access Denied', which is the exact error described.
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 EC2 instances in the prod account do not have an appropriate instance profile.
Why it's wrong here
CodePipeline is a fully managed service whose actions run on AWS infrastructure, not on customer EC2 instances. The pipeline's cross-account role assumption is performed by the CodePipeline service role in the tooling account via the STS API, so the presence or validity of an instance profile on the production EC2 targets is irrelevant to the assumption failure. If the deployment action itself were using an EC2-based runner, the instance profile would matter, but CodePipeline does not operate that way. Thus, this option cannot explain why the role assumption fails.
- ✓
The pipeline's service role lacks the `sts:AssumeRole` permission for the cross-account role.
Why this is correct
For cross-account deployments, the pipeline service role in the source account must contain a policy that explicitly grants the `sts:AssumeRole` action on the ARN of the destination account's cross-account role. This is in addition to the trust policy on the cross-account role that allows the service role to assume it. Without this permission, CodePipeline's attempt to switch into the production account fails with a 403 AccessDenied at the AssumeRole step, which is exactly the described symptom. This is the root cause of the deployment failure.
- ✗
The cross-account role's permissions boundary denies the deploy action.
Why it's wrong here
A permissions boundary on the cross-account role only limits the maximum permissions the role can grant after it is successfully assumed; it does not affect the `sts:AssumeRole` call itself. Since the failure occurs precisely when CodePipeline is trying to assume the role, a boundary that limits deployment actions would not be evaluated during the assumption. Even if a boundary were misconfigured, the error would appear later, when the deploy action attempts to execute with the assumed role, not at the initial role switch. Therefore, this cannot be the reason for the assumption failure.
- ✗
The pipeline's service role does not have permission to perform the deploy action in the prod account.
Why it's wrong here
The pipeline's service role only operates in the tooling account; it does not directly perform deployment actions in the production account. All deployment operations in the prod account are performed by the cross-account role after it is assumed via `sts:AssumeRole`. If the service role lacks permission to assume the cross-account role, it never obtains the credentials needed to invoke the deploy action, so the failure is at the authorization step for `AssumeRole` and not tied to the deploy action permissions. Thus, this option misidentifies the phase where the failure occurs.
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-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 DOP-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 DOP-C02 exam.