A company uses AWS CloudFormation to deploy a web application. The template currently hard-codes the EC2 instance type (e.g., t3.medium). The SysOps administrator wants to make the instance type configurable so that different environments (dev, test, prod) can use different instance types without modifying the template each time. Which CloudFormation feature enables this?
Parameters allow users to input values when creating or updating a stack, making the template reusable for different environments.
Why this answer
Option A is correct because CloudFormation Parameters allow you to pass custom values into a template at stack creation or update time. By defining a parameter for the instance type (e.g., with allowed values like t3.micro, t3.medium, t3.large), you can reuse the same template across dev, test, and prod environments without editing the template file itself.
Exam trap
The trap here is that candidates often confuse Mappings (which are static and environment-agnostic) with Parameters (which are dynamic and user-supplied), leading them to incorrectly choose Mappings as the way to make values configurable.
How to eliminate wrong answers
Option B is wrong because Mappings are static lookup tables (e.g., mapping environment names to instance types) that are hard-coded in the template and cannot be overridden at deployment time; they do not accept runtime input. Option C is wrong because Conditions control whether certain resources are created based on logical expressions (e.g., create a larger instance only in prod), but they do not make the instance type configurable as a deploy-time variable. Option D is wrong because Outputs are used to return information about deployed resources (e.g., instance ID or public IP) after stack creation; they do not accept input values.