Why Infrastructure as Code matters in AWS - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a simple AWS S3 bucket using Infrastructure as Code.

AWS

Resources:
  MyBucket:
    Type: [1]

Drag options to blanks, or click blank then click option'

AAWS::EC2::Instance

BAWS::S3::Bucket

CAWS::Lambda::Function

DAWS::DynamoDB::Table

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong AWS resource type like EC2 instance or Lambda function.

Confusing resource types for different AWS services.

The resource type AWS::S3::Bucket defines an S3 bucket in AWS CloudFormation, which is a common Infrastructure as Code tool.

2fill in blank

medium

Complete the code to specify the bucket name property in the S3 bucket resource.

AWS

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: [1]

Drag options to blanks, or click blank then click option'

AMyBucket123

BInstanceType

CFunctionName

DTableName

Attempts:

3 left

💡 Hint

Common Mistakes

Using properties that belong to other AWS services.

Leaving the bucket name blank or invalid.

The BucketName property sets the name of the S3 bucket. It should be a string representing the bucket's name.

3fill in blank

hard

Fix the error in the following CloudFormation snippet by selecting the correct property key for enabling versioning on the S3 bucket.

AWS

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      [1]:
        Status: Enabled

Drag options to blanks, or click blank then click option'

AVersioningConfiguration

BVersionControl

CVersion

DVersioningStatus

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect property names like Version or VersionControl.

Misnaming the property causes deployment errors.

The correct property to enable versioning on an S3 bucket is VersioningConfiguration with a nested Status key.

4fill in blank

hard

Fill both blanks to create a CloudFormation output that shows the bucket's ARN after deployment.

AWS

Outputs:
  BucketArn:
    Description: "The ARN of the S3 bucket"
    Value: ![1] MyBucket.[2]

Drag options to blanks, or click blank then click option'

AGetAtt

BRef

CArn

DName

Attempts:

3 left

💡 Hint

Common Mistakes

Using Ref instead of GetAtt for ARN retrieval.

Using incorrect attribute names like Name.

The GetAtt function retrieves an attribute of a resource, and Arn is the attribute for the bucket's ARN.

5fill in blank

hard

Fill all three blanks to define an IAM role with a trust policy allowing Lambda service to assume it.

AWS

Resources:
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: [1]
            Action: [2]
      Policies:
        - PolicyName: LambdaPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action: [3]
                Resource: '*'

Drag options to blanks, or click blank then click option'

Alambda.amazonaws.com

Bsts:AssumeRole

Clogs:CreateLogGroup

Dec2.amazonaws.com

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong service principal like ec2.amazonaws.com.

Using incorrect action names for assume role or logging.

The Service principal for Lambda is lambda.amazonaws.com. The action to allow assuming the role is sts:AssumeRole. The policy action to allow creating logs is logs:CreateLogGroup.

Practice

1. Why is Infrastructure as Code (IaC) important when managing cloud resources?

easy

A. It requires manual configuration for every deployment.

B. It makes cloud setups repeatable and reduces manual errors.

C. It slows down the deployment process.

D. It prevents teams from collaborating on infrastructure.

Solution

1. Step 1: Understand IaC purpose

   IaC automates cloud setup, making it repeatable and consistent.

2. Step 2: Compare options

   Only It makes cloud setups repeatable and reduces manual errors. describes IaC benefits correctly; others describe drawbacks or false statements.

3. Final Answer:

   It makes cloud setups repeatable and reduces manual errors. -> Option B

4. Quick Check:

   Repeatable setup = A [OK]

Hint: IaC automates setup to avoid manual mistakes [OK]

Common Mistakes:

• Thinking IaC requires manual steps every time
• Believing IaC slows deployment
• Assuming IaC blocks team collaboration

2. Which of the following is the correct way to define an AWS S3 bucket using Infrastructure as Code in AWS CloudFormation?

easy

A. "Resources": { "MyBucket": { "Type": "AWS::S3::Bucket" } }

B. "Resources": { "MyBucket": { "Type": "AWS::EC2::Instance" } }

C. "Resources": { "MyBucket": { "Type": "AWS::Lambda::Function" } }

D. "Resources": { "MyBucket": { "Type": "AWS::DynamoDB::Table" } }

Solution

1. Step 1: Identify resource type for S3 bucket

   The correct CloudFormation type for an S3 bucket is "AWS::S3::Bucket".

2. Step 2: Match option with correct type

   "Resources": { "MyBucket": { "Type": "AWS::S3::Bucket" } } uses "AWS::S3::Bucket"; others use unrelated resource types.

3. Final Answer:

   "Resources": { "MyBucket": { "Type": "AWS::S3::Bucket" } } -> Option A

4. Quick Check:

   S3 bucket type = AWS::S3::Bucket [OK]

Hint: S3 bucket type always AWS::S3::Bucket in CloudFormation [OK]

Common Mistakes:

• Confusing resource types like EC2 or Lambda for S3
• Using incorrect syntax for resource definition
• Forgetting to include the "Resources" key

3. Given this AWS CloudFormation snippet:

{
  "Resources": {
    "MyBucket": {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": "my-unique-bucket-123"
      }
    }
  }
}

What will happen when this template is deployed twice without changes?

medium

A. The bucket will be created twice with different names.

B. The deployment will fail due to duplicate bucket name.

C. The deployment will succeed, leaving the existing bucket unchanged.

D. A new bucket with the same name will overwrite the old one.

Solution

1. Step 1: Understand idempotency in IaC

   CloudFormation is idempotent: deploying the same template to the same stack twice detects no changes and succeeds without modifying resources.

2. Step 2: Analyze bucket name uniqueness

   S3 bucket names must be unique globally, but CloudFormation tracks the resource by logical ID in the stack, recognizing the existing bucket on redeploy.

3. Step 3: Determine deployment behavior

   The second deployment succeeds without recreating or failing, as the state matches.

4. Final Answer:

   The deployment will succeed, leaving the existing bucket unchanged. -> Option C

5. Quick Check:

   Idempotent deployment succeeds without changes = B [OK]

Hint: Same template redeploy updates existing resources safely [OK]

Common Mistakes:

• Thinking duplicate buckets with same name can be created
• Assuming deployment fails on second run without changes
• Believing new bucket overwrites old one forcibly

4. You wrote this AWS CloudFormation snippet but deployment fails:

{
  "Resources": {
    "MyBucket": {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": 12345
      }
    }
  }
}

What is the error and how to fix it?

medium

A. Type value is incorrect; change to AWS::S3::BucketName.

B. BucketName cannot be set manually; remove the property.

C. Resources key is missing; add it at the root level.

D. BucketName must be a string, not a number; fix by quoting the name.

Solution

1. Step 1: Identify property type error

   BucketName must be a string; 12345 is a number causing syntax error.

2. Step 2: Correct the property value

   Fix by enclosing bucket name in quotes, e.g., "12345" or a valid string.

3. Final Answer:

   BucketName must be a string, not a number; fix by quoting the name. -> Option D

4. Quick Check:

   BucketName type string required = C [OK]

Hint: Bucket names must be strings in quotes [OK]

Common Mistakes:

• Using numbers without quotes for string properties
• Changing resource type incorrectly
• Removing required keys like Resources

5. A team wants to use Infrastructure as Code to manage their AWS environment. Which of these practices best supports collaboration and safe deployments?

hard

A. Store IaC templates in a shared version control system and review changes before deployment.

B. Manually update cloud resources directly in the AWS console to avoid template errors.

C. Allow each team member to deploy changes independently without coordination.

D. Avoid using version control to speed up deployments.

Solution

1. Step 1: Identify collaboration best practice

   Using version control allows tracking changes and team reviews.

2. Step 2: Evaluate deployment safety

   Reviewing changes before deployment prevents mistakes and conflicts.

3. Step 3: Compare options

   Only Store IaC templates in a shared version control system and review changes before deployment. supports collaboration and safe deployments; others increase risk or reduce control.

4. Final Answer:

   Store IaC templates in a shared version control system and review changes before deployment. -> Option A

5. Quick Check:

   Version control + reviews = safe collaboration [OK]

Hint: Use version control and reviews for safe IaC teamwork [OK]

Common Mistakes:

• Skipping version control for speed
• Deploying without team coordination
• Making manual changes outside IaC