DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS CloudFormation StackSets to deploy a VPC with subnets across multiple accounts and regions. Recently, a new account was added to the organization, and the DevOps team wants to deploy the stack set to this new account without affecting existing stacks. The stack set has self-managed permissions. The engineer creates a new stack instance for the account and region, but the operation fails with an 'Access Denied' error when CloudFormation tries to create resources in the new account. The engineer has verified that the stack set's IAM roles exist in the new account. What is the most likely cause?
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 trust policy of the IAM role in the target account does not grant permissions to the administrator account.
The error 'Access Denied' when CloudFormation tries to create resources in the new account indicates a permissions issue. With self-managed permissions, the IAM role in the target account must have a trust policy that allows the administrator account to assume it. Even if the role exists, if its trust policy does not grant the administrator account the necessary permissions, the operation will fail. Option B correctly identifies this as the cause. Option A is incorrect because self-managed permissions do not require a trust relationship; the administrator account needs to trust the target account role. Option C is irrelevant; service limits would produce a different error. Option D is incorrect because the role names are verified to exist.
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 stack set template contains a resource that is not supported in the target region.
Why it's wrong here
An unsupported resource in the template does not produce an AccessDenied error. When CloudFormation attempts to create a resource type that is not available in the targeted region, the stack instance fails with a resource-specific error such as 'Resource is not supported in this region' or a 'CREATE_FAILED' status, not an IAM authorization failure. AccessDenied indicates that the assumed IAM role lacks permission to perform an action, whereas a regional unsupported resource is a service availability constraint that is evaluated only after authorization succeeds.
- ✓
The trust policy of the IAM role in the target account does not grant permissions to the administrator account.
Why this is correct
This is the correct cause because StackSets with self-managed permissions require the administrator account to assume an IAM execution role in each target account using the sts:AssumeRole API. The target account execution role must include a trust policy that explicitly grants the administrator account (or the StackSets administration role) permission to assume it. If that trust relationship is missing or misconfigured, the administrator account receives an AccessDenied response even though the role exists and the execution role's permissions policy may be correct. Therefore, verifying the role exists is not sufficient; you must verify its trust policy.
- ✗
The target account has reached a service limit for VPCs.
Why it's wrong here
A VPC service limit would be reported as a LimitExceeded error from Amazon EC2, not as an AccessDenied from AWS Identity and Access Management. Service quotas are checked during resource creation after the caller has already been authorized, so the IAM role assumption succeeds and then the CreateVpc call fails due to capacity constraints. In a StackSets deployment, such a failure would appear as a stack instance with a FAILED status and an EC2-specific error message, which is different from the AccessDenied shown when the cross-account role cannot be assumed.
- ✗
The IAM roles in the target account are not named correctly.
Why it's wrong here
Because the engineer verified that the IAM roles exist in the target account, an incorrect role name cannot be the cause of the AccessDenied. If the role name were wrong, StackSets would fail with a NoSuchEntity error when it tries to find and assume the role, and the trust policy would never be evaluated. Here the role exists but the trust policy is the problem: without the administrator account listed as a trusted principal, the sts:AssumeRole call is denied. Renaming the role would not fix a trust-policy misconfiguration, so this option is incorrect.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,339 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 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.