DOP-C02 Configuration Management and IaC Practice Question

A DevOps team is using AWS CloudFormation to manage infrastructure. They want to reuse the same template across multiple environments (dev, test, prod) with minor parameter variations. Which CloudFormation feature should they use to pass environment-specific values without modifying the template?

⚠ Common exam trap

DOP-C02 often tests the confusion between Parameters (inputs at deploy time) and Mappings (static in-template lookups) — candidates pick Mappings thinking they allow per-environment variation, but Mappings require editing the template, which the question explicitly forbids.

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

✓

Parameters

CloudFormation Parameters let you pass environment-specific values (like instance sizes, CIDR ranges, or environment names) into a template at stack creation or update time without modifying the template itself. This is exactly the use case described: one template, multiple environments, different values supplied at deploy time via the console, CLI, or a parameters file.

Answer analysis

Option-by-option breakdown

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

✗
Conditions
Why it's wrong here
Conditions are template-level logical expressions that determine whether resources are created or updated by evaluating against parameter values and pseudo parameters like AWS::Region. However, they only act as a gate for resource creation; they do not inject, transform, or pass values into the template. Because environment-specific values need to flow into the template, not gate it, Conditions are not the mechanism to use.
✗
Outputs
Why it's wrong here
Outputs are a read-only section of a CloudFormation template that returns values after the stack has been provisioned, such as resource IDs, DNS names, or computed attributes. They can be consumed by other stacks via Fn::ImportValue, but they are generated from the completed stack and cannot be used to pass input values into a template at creation time. Since the DevOps team needs to supply environment-specific values during deployment, Outputs are the wrong tool.
✗
Mappings
Why it's wrong here
Mappings are static key-value lookup tables that are hard-coded into the template and are resolved at stack creation based on matching a provided key (like AWS::Region or a custom key) to a fixed set of values. They are not dynamic inputs; every possible environment value must be known and written before deployment, and they cannot be modified by users without editing and re-uploading the template. Thus, for passing per-environment values at runtime, Mappings are unsuitable.
✓
Parameters
Why this is correct
Parameters are the designated CloudFormation feature for passing environment-specific values, such as instance types, AMI IDs, or environment names, into a template during stack creation or update. They are declared in the template and can be referenced via Ref or Fn::Sub, allowing users to supply input without editing the template, with optional constraints like AllowedValues, type validation, and NoEcho for sensitive data. This makes Parameters exactly what the DevOps team needs for dynamic per-environment configuration.

Visual reference

Go deeper

DOP-C02 Configuration Management and IaC Practice Question

Why each option matters

Option-by-option breakdown

Related to this question