Parameters for customization in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Parameter Store usage in AWS

Which of the following best describes the primary purpose of AWS Systems Manager Parameter Store?

A It stores and manages configuration data and secrets centrally for your applications.

B It is used to deploy EC2 instances automatically.

C It monitors network traffic between AWS services.

D It provides a database service for storing application data.

💡 Hint

Think about a service that helps keep configuration and secrets safe and easy to update.

AWS Systems Manager Parameter Store is designed to store configuration data and secrets centrally, so applications can retrieve them securely and consistently.

❓ Configuration

intermediate

Using CloudFormation Parameters for customization

Given the following CloudFormation snippet, what will be the value of the InstanceType property if the stack is launched without specifying any parameter overrides?

{
  "Parameters": {
    "InstanceTypeParam": {
      "Type": "String",
      "Default": "t3.micro",
      "AllowedValues": ["t3.micro", "t3.small", "t3.medium"]
    }
  },
  "Resources": {
    "MyEC2Instance": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "InstanceType": { "Ref": "InstanceTypeParam" },
        "ImageId": "ami-0abcdef1234567890"
      }
    }
  }
}

A t3.small

B t3.medium

C No value, stack creation will fail

D t3.micro

💡 Hint

Check the default value defined in the parameter section.

If no parameter override is provided, CloudFormation uses the default value specified in the parameter definition.

❓ Architecture

advanced

Designing parameter usage for multi-environment deployment

You want to deploy the same CloudFormation template to multiple environments (dev, test, prod) with different database endpoints. Which approach best uses parameters to achieve this?

A Define a parameter for the database endpoint with no default, and provide the endpoint value during stack creation for each environment.

B Use a single parameter with a default value set to the production database endpoint for all environments.

C Hardcode the database endpoint in the template for each environment and create separate templates.

D Use environment variables on the EC2 instance to set the database endpoint instead of parameters.

💡 Hint

Think about flexibility and reusability of the template across environments.

Using a parameter without a default forces you to provide the correct database endpoint per environment, making the template reusable and environment-specific.

❓ security

advanced

Securing sensitive parameters in AWS Systems Manager Parameter Store

Which option correctly describes how to securely store a database password in AWS Systems Manager Parameter Store?

A Store the password in an S3 bucket with public read access.

B Store the password as a String parameter and share the parameter ARN publicly.

C Store the password as a SecureString parameter encrypted with a KMS key and restrict access via IAM policies.

D Store the password in plain text in a String parameter and encrypt it manually in the application.

💡 Hint

Consider encryption and access control best practices.

SecureString parameters use encryption with AWS KMS and access can be controlled with IAM policies, ensuring the password is protected.

❓ service_behavior

expert

Behavior of parameter versioning in AWS Systems Manager Parameter Store

You update a SecureString parameter in AWS Systems Manager Parameter Store multiple times. What happens to the parameter versions and how can you retrieve the previous version?

A Each update overwrites the existing version; previous versions are lost and cannot be retrieved.

B Each update creates a new version number; you can retrieve previous versions by specifying the version number in the API call.

C Parameter Store keeps only the latest two versions; older versions are automatically deleted.

D Parameter versions are not tracked; you must manually backup parameter values to keep history.

💡 Hint

Think about version control and retrieval capabilities of Parameter Store.

Parameter Store assigns a new version number for each update and allows retrieval of previous versions by specifying the version number.

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