DOP-C02 Configuration Management and IaC Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  You can use AWS Organizations to centrally manage accounts and use StackSets with trusted access.

  Why this is correct

  Enabling trusted access for AWS CloudFormation in AWS Organizations allows StackSets to use the organization's structure (accounts and OUs) to automatically determine the set of target accounts. With service-managed permissions, any account added to the organization or an OU is automatically included in deployments, removing the need to manually maintain account lists. This centralization is a best practice for multi-account infrastructure management.

• ✗

  CloudFormation can automatically create new AWS accounts using a template.

  Why it's wrong here

  CloudFormation templates are declarative documents that only manage resources that already exist within a single AWS account. There is no CloudFormation resource type that creates a new AWS account; account creation is performed by AWS Organizations using the CreateAccount API or during AWS Control Tower provisioning. Attempting to place account creation in a template would fail because the template has no valid resource type and no credentials to create the account outside the organization's management path.

• ✗

  Nested stacks can be used to deploy resources in different accounts from a single template.

  Why it's wrong here

  Nested stacks are stacks declared inside a parent stack, enabling modular and reusable templates. All resources in the parent and nested stacks are provisioned within the same AWS account and AWS region; there is no field or parameter that changes the target account or region for a nested stack. Therefore, nested stacks cannot deploy resources across multiple accounts, and trying to use them for that purpose will either fail or require a different mechanism such as AWS CloudFormation StackSets.

• ✓

  AWS CloudFormation StackSets can deploy stacks across multiple accounts.

  Why this is correct

  AWS CloudFormation StackSets is the native CloudFormation feature specifically designed to deploy identical stacks across multiple AWS accounts and regions. By creating a stack set and specifying target accounts (via self-managed permissions) or letting the organization control the target list (via service-managed permissions), you get consistent infrastructure across your entire organization from a single template. This is the correct way to achieve cross-account deployments with CloudFormation.

• ✗

  You can use cross-stack references to share resources between accounts.

  Why it's wrong here

  Cross-stack references allow a stack in the same account and region to export an output (for example, a VPC ID) and another stack to import it using the Fn::ImportValue intrinsic function. The export namespace is per account and per region, so a stack in another account cannot import that exported value; the import would fail because the value does not exist in that account's namespace. For sharing resources across accounts, you should use AWS Resource Access Manager (RAM) or StackSets to provision synchronized resources, not CloudFormation cross-stack references.

Go deeper

Related to this question