Parameters for customization in AWS - Step-by-Step Execution

Process Flow - Parameters for customization

Define Parameter

↓

Use Parameter in Template

↓

Deploy Stack with Parameter Value

↓

CloudFormation Reads Parameter

↓

Resource Created Using Parameter

↓

Stack Ready with Custom Config

Parameters let you customize AWS CloudFormation stacks by defining inputs that change resource settings during deployment.

Execution Sample

AWS

Parameters:
  InstanceTypeParam:
    Type: String
    Default: t2.micro
Resources:
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceTypeParam

This template defines a parameter for EC2 instance type and uses it to set the instance type when creating the EC2 resource.

Process Table

Step	Action	Parameter Value	Resource Property Set	Result
1	Define parameter InstanceTypeParam	t2.micro (default)	N/A	Parameter ready for input
2	Deploy stack without override	t2.micro	InstanceType = t2.micro	EC2 instance will be t2.micro
3	Deploy stack with override 'm5.large'	m5.large	InstanceType = m5.large	EC2 instance will be m5.large
4	CloudFormation creates EC2 instance	m5.large	InstanceType = m5.large	EC2 instance launched with m5.large
5	Stack deployment complete	m5.large	InstanceType = m5.large	Stack ready with customized instance type

💡 Stack deployment ends after resource creation using parameter value

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
InstanceTypeParam	t2.micro (default)	t2.micro	m5.large	m5.large
MyEC2Instance.InstanceType	N/A	t2.micro	m5.large	m5.large

Key Moments - 2 Insights

Why does the EC2 instance type change when I deploy the stack with a different parameter value?

Because the parameter value overrides the default and is used in the resource property, as shown in execution_table step 3 where InstanceTypeParam changes from default to 'm5.large'.

What happens if I do not provide a parameter value during deployment?

The default parameter value is used, as shown in execution_table step 2 where the instance type remains 't2.micro'.

Visual Quiz - 3 Questions

Look at the execution table, what is the InstanceTypeParam value at step 3?

A m5.large

B t2.micro

C t3.medium

D No value set

💡 Hint

Check the 'Parameter Value' column at step 3 in the execution_table.

At which step does CloudFormation create the EC2 instance using the parameter value?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' column describing resource creation in the execution_table.

If you remove the default value from the parameter, what will happen during deployment without an override?

A Uses a random instance type

B Deployment fails due to missing parameter

C Uses t2.micro automatically

D Creates instance with no type

💡 Hint

Parameters without defaults require a value at deployment, see how default is used in step 2.

Concept Snapshot

Parameters let you customize AWS CloudFormation stacks.
Define parameters with type and optional default.
Use !Ref to insert parameter values into resources.
During deployment, provide values or use defaults.
Resources use these values to configure settings.
This enables flexible, reusable templates.

Full Transcript

Parameters in AWS CloudFormation allow you to customize your infrastructure by defining inputs that can change resource properties during deployment. You define a parameter with a type and optionally a default value. In your template, you use the parameter with !Ref to set resource properties. When deploying the stack, you can provide a value to override the default. CloudFormation reads the parameter value and creates resources accordingly. This process lets you reuse templates for different configurations without changing the template code itself.

Practice

1. What is the main purpose of using Parameters in AWS CloudFormation templates?

easy

A. To monitor cloud resource usage

B. To store large files in the cloud

C. To customize the template without changing its code

D. To create new AWS services automatically

Solution

1. Step 1: Understand the role of Parameters

   Parameters allow users to input values when launching a template, so the same template can be reused with different settings.

2. Step 2: Compare options with Parameters purpose

   Only To customize the template without changing its code describes customization without changing the template code, which is the key use of Parameters.

3. Final Answer:

   To customize the template without changing its code -> Option C

4. Quick Check:

   Parameters = Customize without code change [OK]

Hint: Parameters let you change settings without editing code [OK]

Common Mistakes:

• Thinking Parameters create resources automatically
• Confusing Parameters with monitoring tools
• Assuming Parameters store files

2. Which of the following is the correct syntax to define a string parameter named InstanceType with a default value of t2.micro in a CloudFormation template?

easy

A. "InstanceType": {"Default": "t2.micro"}

B. "InstanceType": {"Type": "Number", "Default": "t2.micro"}

C. "InstanceType": {"Type": "String", "Value": "t2.micro"}

D. "InstanceType": {"Type": "String", "Default": "t2.micro"}

Solution

1. Step 1: Identify correct parameter syntax

   Parameters require a Type and optionally a Default. The Type for instance types is String, and Default sets the default value.

2. Step 2: Check each option

   "InstanceType": {"Type": "String", "Default": "t2.micro"} correctly uses "Type": "String" and "Default": "t2.micro". "InstanceType": {"Type": "Number", "Default": "t2.micro"} wrongly uses Number type. "InstanceType": {"Type": "String", "Value": "t2.micro"} uses "Value" which is invalid. "InstanceType": {"Default": "t2.micro"} misses the Type field.

3. Final Answer:

   "InstanceType": {"Type": "String", "Default": "t2.micro"} -> Option D

4. Quick Check:

   Parameter syntax needs Type and Default [OK]

Hint: Parameters need Type and Default keys for customization [OK]

Common Mistakes:

• Using 'Value' instead of 'Default'
• Setting wrong Type like Number for strings
• Omitting the Type field

3. Given this parameter definition in a CloudFormation template:

"Parameters": {
  "EnvType": {
    "Type": "String",
    "AllowedValues": ["dev", "test", "prod"],
    "Default": "dev"
  }
}

What happens if a user tries to launch the stack with EnvType set to stage?

medium

A. The stack uses the default value 'dev' instead

B. The stack creation fails due to invalid parameter value

C. The stack accepts 'stage' and creates resources

D. The stack ignores the parameter and prompts again

Solution

1. Step 1: Understand AllowedValues effect

   The AllowedValues list restricts parameter inputs to only those values. Any value outside causes an error.

2. Step 2: Analyze input 'stage'

   'stage' is not in ["dev", "test", "prod"], so the stack creation will fail with a validation error.

3. Final Answer:

   The stack creation fails due to invalid parameter value -> Option B

4. Quick Check:

   AllowedValues restrict inputs = failure if invalid [OK]

Hint: AllowedValues block invalid inputs causing stack failure [OK]

Common Mistakes:

• Assuming default is used when invalid input given
• Thinking stack ignores invalid parameters
• Believing stack accepts any string

4. You have this parameter snippet:

"Parameters": {
  "DBPassword": {
    "Type": "String",
    "NoEcho": true
  }
}

What is the purpose of NoEcho here, and what common mistake might cause it to fail?

medium

A. NoEcho hides the parameter value in console; mistake is forgetting to set Type

B. NoEcho encrypts the value; mistake is using wrong parameter name

C. NoEcho hides the value in logs; mistake is setting NoEcho to false

D. NoEcho makes parameter optional; mistake is missing Default

Solution

1. Step 1: Understand NoEcho purpose

   NoEcho hides sensitive parameter values (like passwords) from being displayed in the AWS console or logs.

2. Step 2: Identify common mistake

   For NoEcho to work, the parameter must have a Type defined. Forgetting Type causes template errors.

3. Final Answer:

   NoEcho hides the parameter value in console; mistake is forgetting to set Type -> Option A

4. Quick Check:

   NoEcho hides sensitive info; Type is required [OK]

Hint: NoEcho hides secrets; always define Type [OK]

Common Mistakes:

• Not defining Type with NoEcho
• Assuming NoEcho encrypts data
• Setting NoEcho false expecting hiding

5. You want to create a CloudFormation template that asks for a list of availability zones but only allows zones in us-east-1. Which parameter configuration correctly enforces this restriction and allows multiple zones?

hard

A. "Parameters": { "AZList": { "Type": "List", "AllowedValues": ["us-east-1a", "us-east-1b", "us-east-1c"] } }

B. "Parameters": { "AZList": { "Type": "CommaDelimitedList" } }

C. "Parameters": { "AZList": { "Type": "List<String>", "Default": "us-east-1a,us-east-1b" } }

D. "Parameters": { "AZList": { "Type": "String", "AllowedValues": ["us-east-1a", "us-east-1b", "us-east-1c"] } }

Solution

1. Step 1: Identify parameter type for multiple AZs

   To accept multiple availability zones, use the type List with AWS::EC2::AvailabilityZone::Name for validation.

2. Step 2: Check AllowedValues for region restriction

   AllowedValues limits input to only the specified zones in us-east-1.

3. Step 3: Evaluate options

   "Parameters": { "AZList": { "Type": "List", "AllowedValues": ["us-east-1a", "us-east-1b", "us-east-1c"] } } uses correct List type and AllowedValues. "Parameters": { "AZList": { "Type": "CommaDelimitedList" } } uses CommaDelimitedList but lacks AllowedValues restriction. "Parameters": { "AZList": { "Type": "List<String>", "Default": "us-east-1a,us-east-1b" } } lacks AllowedValues restriction. "Parameters": { "AZList": { "Type": "String", "AllowedValues": ["us-east-1a", "us-east-1b", "us-east-1c"] } } uses String type which accepts only one value.

4. Final Answer:

   "Parameters": { "AZList": { "Type": "List", "AllowedValues": ["us-east-1a", "us-east-1b", "us-east-1c"] } } -> Option A

5. Quick Check:

   List type + AllowedValues restrict multiple inputs [OK]

Hint: Use List type with AllowedValues for multiple restricted inputs [OK]

Common Mistakes:

• Using String type for multiple values
• Using CommaDelimitedList without proper validation
• Not restricting AllowedValues to region zones