Use a service-managed StackSet on the root OU and deploy a separate stack in the management account
A company uses an organization in AWS Organizations to manage 10 AWS accounts. All features are enabled, and trusted access for AWS CloudFormation is enabled. A DevOps engineer needs to use CloudFormation to deploy an IAM role to the Organizations management account and all member accounts in the organization. Which solution will meet these requirements with the LEAST operational overhead?
Community Votes
59% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
StackSets deliberately does not deploy stack instances to the organization's management account, which is the fact that decides this question and forces the separate-stack step (B). Service-managed permissions are the lower-overhead choice because StackSets uses the AWS Organizations trusted access to assume roles in target accounts automatically, whereas self-managed permissions would require the administrator to create and maintain those roles in all ten accounts (B over D). Option A omits the management-account stack and therefore leaves the management account without the IAM role; option C adds self-managed permissions on top of the root target, adding manual role management for no benefit.
CloudFormation StackSets does not create stack instances in the Organizations management account, even when the organization root is a deployment target, so the management account must be handled separately. A StackSet with service-managed permissions requires no manual IAM role setup because AWS Organizations integration lets StackSets assume the roles it needs in target accounts, and setting the root OU as the target covers every member account. Because the management account is excluded from StackSets deployment, a separate CloudFormation stack is deployed there for the IAM role.
Setting the root OU as the StackSet deployment target and expecting the management account to be included (option A) — AWS documentation states that StackSets does not deploy stack instances to the organization's management account even if it is included in the OU structure, so the management account would silently never receive the stack. Choosing self-managed permissions (C and D) — self-managed permissions require the administrator to create and maintain the IAM roles StackSets assumes in each target account, whereas service-managed permissions leverage the AWS Organizations integration to do this automatically, so it is the lower-overhead choice.
Community Discussion (7 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Two facts determine the answer. First, AWS documentation states that CloudFormation StackSets does not deploy stack instances to the organization's management account, even when the management account sits within the organization structure addressed by the deployment target. Second, service-managed permissions let StackSets automatically assume roles in target accounts through its AWS Organizations integration, avoiding any manual role creation. The solution is therefore a StackSet with service-managed permissions targeting the root OU, which deploys to all member accounts, plus a separate CloudFormation stack deployed to the management account for the IAM role, since the StackSet cannot reach it (B).Why the Other Options Are Wrong
A creates a service-managed StackSet targeting the root OU but does not deploy any stack to the management account. Because StackSets does not deploy stack instances to the management account, the IAM role would never be created there, so the requirement to deploy to the management account and all member accounts is not met. C creates a StackSet with self-managed permissions targeting the root OU. In addition to missing the separate management-account stack, self-managed permissions require the administrator to create and maintain in every target account the IAM roles that StackSets assumes, which is unnecessary manual work when service-managed permissions can use the trusted access already enabled in this organization. D does add the separate management-account stack but keeps self-managed permissions, so it carries the same unnecessary role-management overhead as C while the question asks for the least operational effort. B is the correct answer.Community Comment Notes
Community voted B (59), with A a 41 percent minority. CHRIS12722222 supplied the decisive documentation reference and its quoted text, that StackSets does not deploy stack instances to the organization's management account even when it is included, which is what makes the separate stack necessary. Impromptu and jojewi8143 reasoned the same way, with jojewi8143 putting it succinctly as StackSets not being able to deploy to the management account. spring21 and Srikantha favored A, reasoning that service-managed permissions with the root target should cover everything, which overlooks the management-account exclusion.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →