CloudFormation vs Terraform awareness in AWS - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding State Management Differences

Which statement correctly describes a key difference in how AWS CloudFormation and Terraform manage infrastructure state?

A Terraform requires explicit state file management, whereas CloudFormation automatically manages state within AWS services.

B Both CloudFormation and Terraform require manual state file uploads to AWS S3 buckets.

C CloudFormation stores state locally on the user's machine, while Terraform stores state in the cloud by default.

D Terraform does not use any state files, but CloudFormation uses state files stored in AWS Lambda.

💡 Hint

Think about where each tool keeps track of the resources it manages.

CloudFormation automatically manages the state of your infrastructure within AWS itself, so you don't have to handle state files. Terraform, however, uses a state file that you must manage, often stored remotely in places like AWS S3 for team collaboration.

❓ Architecture

intermediate

Multi-Cloud Support Comparison

Which option correctly identifies the multi-cloud support capabilities of CloudFormation and Terraform?

A CloudFormation supports multiple cloud providers natively, while Terraform only supports AWS.

B Both CloudFormation and Terraform support multi-cloud deployments equally.

C Terraform supports multiple cloud providers, but CloudFormation is limited to AWS services.

D Neither CloudFormation nor Terraform support multi-cloud deployments.

💡 Hint

Consider which tool is designed specifically for AWS and which is more flexible.

CloudFormation is an AWS-specific service designed to manage AWS resources only. Terraform supports many cloud providers, including AWS, Azure, Google Cloud, and others, making it suitable for multi-cloud environments.

❓ security

advanced

Handling Secrets in Infrastructure as Code

When managing sensitive information like passwords or API keys in CloudFormation and Terraform, which practice is most secure and recommended?

A Embed secrets directly in the template files for both CloudFormation and Terraform for simplicity.

B Encrypt secrets only in Terraform state files; CloudFormation does not support secret encryption.

C Store secrets in plain text files alongside Terraform state files and CloudFormation templates.

D Use AWS Secrets Manager or Parameter Store with CloudFormation, and use external secret management tools with Terraform.

💡 Hint

Think about how each tool integrates with AWS services for secret management.

CloudFormation integrates well with AWS Secrets Manager and Parameter Store to reference secrets securely without embedding them in templates. Terraform can also integrate with external secret managers or AWS services but requires explicit configuration. Storing secrets in plain text or embedding them directly is insecure.

✅ Best Practice

advanced

Managing Infrastructure Drift

Which approach best helps detect and manage infrastructure drift when using CloudFormation and Terraform?

A Use CloudFormation drift detection feature and Terraform plan/apply commands regularly.

B Rely on manual inspection of resources in the AWS console for both tools.

C Ignore drift as both tools automatically fix it without user intervention.

D Delete and recreate all resources frequently to avoid drift.

💡 Hint

Consider built-in features and commands each tool provides to check for changes outside their control.

CloudFormation offers a drift detection feature to identify changes made outside of its management. Terraform uses the plan command to show differences between the current state and desired configuration before applying changes. Manual inspection or deleting resources are not practical or recommended.

❓ service_behavior

expert

Impact of Resource Dependencies on Deployment Order

Given a CloudFormation template and a Terraform configuration both defining an AWS VPC and an EC2 instance that depends on the VPC, how do these tools handle deployment order?

A Terraform automatically infers dependencies and deployment order; CloudFormation requires explicit DependsOn declarations for all dependencies.

B Both CloudFormation and Terraform automatically manage resource creation order based on declared dependencies or references.

C Neither tool manages deployment order; users must deploy resources in the correct sequence manually.

D CloudFormation automatically determines resource creation order based on dependencies; Terraform requires manual ordering of resource blocks.

💡 Hint

Think about how each tool understands resource relationships.

Both CloudFormation and Terraform analyze resource references and dependencies to determine the correct order of creation automatically. CloudFormation uses intrinsic functions and references, and Terraform uses resource references in configuration. Explicit DependsOn is only needed in CloudFormation for special cases.

Practice

1. Which statement best describes the main difference between AWS CloudFormation and Terraform?

easy

A. CloudFormation works only with AWS, while Terraform supports multiple cloud providers.

B. Terraform is only for AWS, CloudFormation supports all clouds.

C. Both tools only work with AWS services.

D. CloudFormation supports multiple clouds, Terraform is AWS-only.

Solution

1. Step 1: Understand CloudFormation scope

   CloudFormation is designed specifically for AWS and manages AWS resources only.

2. Step 2: Understand Terraform scope

   Terraform supports many cloud providers like AWS, Azure, Google Cloud, and more.

3. Final Answer:

   CloudFormation works only with AWS, while Terraform supports multiple cloud providers. -> Option A

4. Quick Check:

   CloudFormation = AWS-only, Terraform = multi-cloud [OK]

Hint: CloudFormation = AWS-only; Terraform = many clouds [OK]

Common Mistakes:

• Thinking Terraform only works with AWS
• Believing CloudFormation supports multiple clouds
• Confusing both as identical tools

2. Which of the following is the correct way to define a resource in AWS CloudFormation?

easy

A. resource "aws_ec2_instance" "web" {}

B. resource "aws_instance" "web" {}

C. AWS::EC2::Instance:

D. resource "ec2_instance" "web" {}

Solution

1. Step 1: Identify CloudFormation syntax

   CloudFormation uses YAML or JSON with resource types like 'AWS::EC2::Instance'.

2. Step 2: Recognize Terraform syntax

   Terraform uses 'resource "aws_instance" "name" {}'.

3. Final Answer:

   CloudFormation resource types use 'AWS::Service::Resource' format. -> Option C

4. Quick Check:

   CloudFormation uses AWS:: notation [OK]

Hint: CloudFormation uses AWS::Service::Resource format [OK]

Common Mistakes:

• Confusing Terraform resource syntax with CloudFormation
• Using Terraform resource blocks in CloudFormation
• Misnaming resource types

3. Given this Terraform snippet:

resource "aws_s3_bucket" "bucket" {
  bucket = "my-unique-bucket"
  acl    = "private"
}

What will happen when you run terraform apply?

medium

A. Creates a public S3 bucket named 'my-unique-bucket' in AWS.

B. Fails because bucket names cannot be unique.

C. Throws a syntax error due to missing region.

D. Creates a private S3 bucket named 'my-unique-bucket' in AWS.

Solution

1. Step 1: Analyze Terraform resource block

   The resource defines an AWS S3 bucket with name 'my-unique-bucket' and ACL set to 'private'.

2. Step 2: Understand Terraform apply behavior

   Terraform will create the bucket with the specified name and private access control.

3. Final Answer:

   Creates a private S3 bucket named 'my-unique-bucket' in AWS. -> Option D

4. Quick Check:

   ACL 'private' means private bucket [OK]

Hint: ACL 'private' means bucket is private [OK]

Common Mistakes:

• Assuming default ACL is public
• Expecting syntax error without region (region is set elsewhere)
• Thinking bucket names cannot be unique (they must be unique)

4. You wrote this CloudFormation snippet:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-bucket
      AccessControl: PublicRead

But deployment fails with an error about bucket name. What is the likely cause?

medium

A. BucketName must be globally unique and 'my-bucket' is already taken.

B. AccessControl property is invalid in CloudFormation.

C. Resource type AWS::S3::Bucket is incorrect.

D. BucketName cannot be specified in CloudFormation.

Solution

1. Step 1: Understand S3 bucket naming rules

   S3 bucket names must be globally unique across all AWS accounts.

2. Step 2: Analyze error cause

   If 'my-bucket' is already used, deployment fails due to name conflict.

3. Final Answer:

   BucketName must be globally unique and 'my-bucket' is already taken. -> Option A

4. Quick Check:

   S3 bucket names are global and unique [OK]

Hint: S3 bucket names must be globally unique [OK]

Common Mistakes:

• Thinking AccessControl is invalid (it is valid)
• Assuming resource type is wrong
• Believing BucketName is optional or disallowed

5. Your team wants to manage infrastructure across AWS, Azure, and Google Cloud with one tool. Which approach is best?

hard

A. Use AWS CloudFormation for all clouds to keep consistency.

B. Use Terraform because it supports multiple cloud providers.

C. Use separate CloudFormation stacks for each cloud provider.

D. Use manual console setup for each cloud to avoid tool complexity.

Solution

1. Step 1: Identify tool cloud support

   CloudFormation only supports AWS, so it cannot manage Azure or Google Cloud.

2. Step 2: Choose tool for multi-cloud management

   Terraform supports AWS, Azure, Google Cloud, and others in one tool.

3. Step 3: Evaluate other options

   Separate CloudFormation stacks or manual setup increase complexity and reduce automation benefits.

4. Final Answer:

   Use Terraform because it supports multiple cloud providers. -> Option B

5. Quick Check:

   Terraform = multi-cloud support [OK]

Hint: Terraform supports many clouds; CloudFormation is AWS-only [OK]

Common Mistakes:

• Assuming CloudFormation works outside AWS
• Thinking manual setup is simpler for multi-cloud
• Believing separate CloudFormation stacks can manage non-AWS clouds