DOP-C02 SDLC Automation Practice Question
A large enterprise uses a multi-account AWS strategy with a centralized DevOps account. The DevOps account hosts an AWS CodePipeline that deploys a critical application to production account (111111111111) using AWS CodeDeploy. The pipeline has three stages: Source (CodeCommit), Build (CodeBuild), and Deploy (CodeDeploy). The deploy stage uses a cross-account role (arn:aws:iam::111111111111:role/CrossAccountDeployRole) to perform the deployment. The trust policy on that role allows the DevOps account's CodePipeline service role (arn:aws:iam::222222222222:role/CodePipelineServiceRole) to assume it. The pipeline has been working for months, but after a recent security audit, the security team tightened permissions. Now the deploy stage fails with the error: 'User: arn:aws:sts::222222222222:assumed-role/CodePipelineServiceRole/AWS-CodePipeline-xxx is not authorized to perform: codedeploy:CreateDeployment on resource: arn:aws:codedeploy:us-east-1:111111111111:deploymentgroup:MyApp/MyDG'. The DevOps team has verified that the CrossAccountDeployRole has a permissions policy that allows 'codedeploy:*' on all resources. The CodePipelineServiceRole has a permissions policy that allows 'sts:AssumeRole' on the CrossAccountDeployRole. What is the most likely cause and what action should be taken to resolve the issue?
⚠ Common exam trap
Many exam-takers assume the error is due to missing sts:AssumeRole or trust policy misconfiguration, but the role was already assumed successfully (as shown by the assumed-role ARN in the error), so the real issue is a permissions boundary or service control policy limiting the role's effective permissions.
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
✓
Check the permissions boundary on CrossAccountDeployRole and add a boundary that allows CodeDeploy actions.
The error indicates that the assumed role (CrossAccountDeployRole) is not authorized to perform codedeploy:CreateDeployment, despite having a permissions policy that allows codedeploy:* on all resources. This typically occurs when a permissions boundary is attached to the role that restricts the effective permissions, overriding the permissions policy. Adding a permissions boundary that allows CodeDeploy actions resolves the issue by ensuring the role's effective permissions include the necessary CodeDeploy operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add 'sts:AssumeRole' to the permissions policy of CodePipelineServiceRole.
Why it's wrong here
Adding 'sts:AssumeRole' to the CodePipelineServiceRole permissions policy addresses only the ability to request credentials for the cross-account role. Once CrossAccountDeployRole is assumed, the effective permissions are determined by that role's identity-based policy and any permissions boundary, not by the pipeline role's permissions. The service role already has this permission in a properly configured pipeline, so it would not resolve the CodeDeploy authorization failure.
- ✗
Create the deployment group in the production account again to reset permissions.
Why it's wrong here
Recreating the deployment group in the production account creates a new CodeDeploy resource configuration but does not modify any IAM policies or boundaries. The authorization error occurs during the deployment action when CrossAccountDeployRole attempts to invoke codedeploy APIs, which is controlled by IAM permission evaluation. Resetting the resource has no effect on the role's effective permissions, so the same failure will recur immediately.
- ✓
Check the permissions boundary on CrossAccountDeployRole and add a boundary that allows CodeDeploy actions.
Why this is correct
A permissions boundary on CrossAccountDeployRole acts as an additional filter on the role's effective permissions, and if it does not explicitly allow CodeDeploy actions, those actions are denied even when the role's permissions policy grants them. Because the effective permission is the intersection of the identity-based policy and the boundary, the boundary must include all required codedeploy:* or specific actions. Adding or updating the boundary to allow CodeDeploy actions is the correct way to restore authorization in this cross-account deployment.
- ✗
Update the trust policy of CrossAccountDeployRole to include the DevOps account ID.
Why it's wrong here
Updating the trust policy of CrossAccountDeployRole to include the DevOps account ID only governs which principals are allowed to assume the role, not what actions the role can perform after being assumed. Since CodePipeline is already assuming the role successfully and making CodeDeploy API calls, the trust policy is not the source of the failure. The denial is happening at the action level due to the permissions boundary, so adjusting the trust policy would have no impact.
Visual reference
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.