DOP-C02 - Configuration Management and Infrastructure as Code (17% of the exam) - Section 2.3

Provision and govern infrastructure across accounts and Regions using AWS CloudFormation StackSets, AWS Service Catalog and AWS Resource Access Manager.

Provision infrastructure consistently across multiple accounts and Regions using AWS CloudFormation StackSets, and govern approved configurations by publishing products through AWS Service Catalog. Use AWS Resource Access Manager to share resources across accounts without duplicating them.

AWS CloudFormation StackSetsAWS Service CatalogAWS Resource Access ManagerCross-account provisioning

Practice question for this objective

Free sampleConfiguration Management and Infrastructure as Codehard

A central team owns a portfolio of "AWS Service Catalog" products and must let 40 member accounts across an "AWS Organizations" structure launch the products, with new accounts gaining access automatically and removed accounts losing access, all without the central team importing each account individually. The products must stay centrally versioned so a new product version reaches every consuming account. Which sharing approach BEST meets these requirements?

AExport each product template to "Amazon S3" and grant the member accounts read access so their administrators import and launch the templates themselves.
BShare the portfolio with the organisational unit using "AWS Organizations" integration so member accounts gain access automatically and version updates propagate from the shared portfolio. Correct
CShare the portfolio individually with each of the 40 account IDs and add new account IDs to the share whenever an account is created.
DDeploy the portfolio's products into every account with a service-managed "AWS CloudFormation StackSets" operation so each account holds a local copy of the products.

Share an AWS Service Catalog portfolio to an organisational unit so member accounts gain access automatically and receive central product version updates. AWS Service Catalog integrates with AWS Organizations to let a management or delegated administrator account share a portfolio with an organisational unit or the whole organisation. Accounts that belong to the shared organisational unit automatically gain access to the portfolio's products, and because the products remain centrally owned, new product versions propagate to all consuming accounts without per-account imports or manual ID lists.

Why A is wrong: Copying templates to S3 breaks central versioning because each account imports its own copy, and it provides no automatic access for new accounts or removal for departed ones, defeating the governance goal.

Why B is correct: Sharing a Service Catalog portfolio to an organisational unit grants every member account access automatically as accounts join or leave, and product version updates flow from the shared portfolio, meeting central versioning and automatic membership.

Why C is wrong: Per-account sharing does centralise products but requires manually adding each new account ID, so access is not automatic for accounts that join the organisational unit, missing the hands-off requirement.

Why D is wrong: StackSets would replicate stacks, not share a governed self-service catalogue, so end users could not browse and launch versioned products and central version propagation through a portfolio is lost.

See more DOP-C02 practice questions, answers explained.

Exam traps in Configuration Management and Infrastructure as Code

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Use "AWS CloudFormation StackSets" to deploy an identical VPC and subnet into each application account and peer every VPC back to the hub account.
Why it is wrong: Replicating a VPC per account with peering duplicates NAT and routing costs and creates a heavy peering mesh to maintain, which contradicts the single shared subnet and low-administration requirement.
Grant each team a permission boundary that allows only the CloudFormation actions needed and let them deploy approved templates from a shared "Amazon S3" bucket.
Why it is wrong: A permission boundary plus shared templates still requires each team to hold the underlying resource permissions and offers no versioned product catalogue or constrained launch, so it does not deliver governed self-service.
Publish a nested stack template to an Amazon S3 location and have each team add an AWS::CloudFormation::Stack resource that points at the shared template URL to compose the logging bucket into their stacks.
Why it is wrong: Nested stacks compose templates by URL reference but they are not registered resource types, so teams declare an AWS::CloudFormation::Stack rather than a native-looking type and version upgrades require editing the referenced URL.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.