SOA-C02 Deployment, Provisioning, and Automation Practice Question
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?
⚠ Common exam trap
Watch out — 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.
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 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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Parameters
Why this is correct
Parameters are the only CloudFormation construct here that accept runtime input. When you create or update a stack, you supply values, either interactively, via CLI, or via a stack template, and those values are referenced with Ref to set resource properties. Because the same template can be reused with different parameter values, parameters are the correct way to make a stack deployable to multiple environments with different configuration.
- ✗
Mappings
Why it's wrong here
Mappings are static lookup tables defined in the template: they use Fn::FindInMap to select a value from a fixed set of keys, such as AMI IDs per AWS region. They are evaluated at stack creation/update and cannot be changed by caller-provided input — any change requires editing the template. Therefore, mappings are a configuration lookup mechanism, not a user-input mechanism.
- ✗
Conditions
Why it's wrong here
Conditions evaluate logical expressions (e.g., using Fn::Equals or Fn::If) to decide whether a resource is created or whether a property is set. They typically test parameter values or other template values, but they do not accept data from the person launching the stack. A condition is a gate, not a parameterization channel; it cannot itself gather environment-specific values.
- ✗
Outputs
Why it's wrong here
Outputs are the opposite of inputs: they surface values like the ARN of a created resource or a load balancer URL after the stack has been created or updated. These values can be exported and imported by other stacks, but they cannot influence what a user enters during creation or what properties resources get. Thus, outputs are informational and downstream-facing.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.