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.

• ✗

  Create separate StackSets for each CIDR range and assign accounts accordingly.

  Why it's wrong here

  Creating a separate StackSet per CIDR range multiplies the template and its drift configuration, so any future change to the base security rules must be pushed through multiple StackSets, increasing operational overhead and the risk of inconsistent states. It also rapidly exhausts StackSet limits (e.g., the 20,000 stack instance and 5,000 stack set per-account quotas) and forces you to manually track which accounts belong to which CIDR group, defeating the centralized governance that StackSets are designed to provide.

• ✗

  Create a nested stack for each account that overrides the default parameters.

  Why it's wrong here

  A nested stack approach for per-account overrides requires you to author a separate parent template or parameter mapping for each account, and CloudFormation StackSets cannot directly deploy nested stacks across target accounts without an additional orchestration layer. This obscures the final resource topology, makes drift detection and stack rollback more difficult because you must monitor both the parent and nested stacks, and it still requires maintaining per-account parameter files, so you end up with duplicate configuration data that introduces the same maintenance burden as multiple templates.

• ✓

  Use a single StackSet with parameters and pass account-specific parameter files via AWS CloudFormation parameter overrides in the StackSet instance.

  Why this is correct

  A single StackSet with a common template and per-account parameter overrides is the intended pattern for account-specific values like CIDR blocks. You can attach overrides to individual stack instances via CreateStackInstances or UpdateStackInstances, so each account receives the same standard security and network rules but with the exact CIDR range it needs, all through one API call. This approach centralizes updates and drift management—changing a rule once updates every account—while preserving per-account flexibility, and it integrates natively with Organizations' delegated administrator and automatic deployment for new accounts.

• ✗

  Maintain separate templates per account with hardcoded CIDR blocks.

  Why it's wrong here

  Maintaining separate templates with hardcoded CIDR blocks means every change to the underlying network or security policy must be manually replicated across all templates, which is error-prone and guarantees configuration drift as accounts are added or modified. You lose the ability to use StackSets' centralized deployment and update features, so auditing the organization-wide baseline becomes a manual reconciliation effort. This approach also increases the time to apply critical patches, because an engineer must edit N templates and execute N stack operations instead of updating a single StackSet.

Go deeper

Related to this question