Infrastructure as Code (IaC) Lab

Modern cloud engineers do not just configure infrastructure—they define, deploy, validate, and manage infrastructure through code.

Welcome to Lab 23 of the CompTIA Cloud+ practical lab sequence.

In the previous lab, you learned how automation and scripting can perform repetitive cloud operations:

Requirement
     ↓
Script
     ↓
Cloud CLI / API
     ↓
Resource Operation
     ↓
Validation

That works well for operational tasks.

But imagine building an entire environment containing:

Virtual Network

Subnets

Security Groups

Virtual Machines

Storage

Load Balancer

Database

Monitoring

Creating every component manually introduces:

Manual Configuration
        ↓
Inconsistency
        ↓
Configuration Drift
        ↓
Deployment Errors
        ↓
Operational Risk

Infrastructure as Code provides another approach:

Infrastructure Definition
        ↓
Version Control
        ↓
Validation
        ↓
Deployment
        ↓
Cloud Infrastructure

In this lab, you will learn how to define and manage cloud infrastructure as code.

🎯 Mission Information

Item	Details
Lab	23 — Infrastructure as Code (IaC) Lab
Difficulty	Intermediate
Estimated Time	150–210 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Infrastructure as Code
Previous Lab	22 — Cloud Automation and Scripting Lab
Career Alignment	Cloud Administrator, Cloud Engineer, DevOps Engineer, Cloud Architect
Major Skills	IaC, Templates, Variables, Dependencies, Validation, Drift, Version Control
Deliverable	IaC Template + Deployment Plan + Validation Report

🏢 Scenario

Your organization currently deploys cloud environments manually.

A typical deployment requires:

Engineer
   ↓
Create Network
   ↓
Create Subnets
   ↓
Configure Security
   ↓
Create VM
   ↓
Configure Storage
   ↓
Create Load Balancer
   ↓
Configure Monitoring

Different engineers perform these tasks differently.

For example:

Environment A

10.10.0.0/16
Encryption Enabled
Correct Tags
Monitoring Enabled

while another deployment contains:

Environment B

10.20.0.0/16
Encryption Enabled
Missing Tags
Monitoring Disabled

The environments are intended to be identical.

But they are not.

Your organization wants:

Standard Architecture
        ↓
Repeatable Deployment
        ↓
Consistent Configuration
        ↓
Version Control
        ↓
Auditable Changes

Your mission is to build a basic Infrastructure as Code workflow.

🎯 Lab Objectives

By completing this lab, you should be able to:

explain Infrastructure as Code
understand declarative infrastructure
compare imperative and declarative approaches
understand IaC templates
understand resources
use variables and parameters
understand outputs
understand dependencies
understand desired state
understand deployment planning
understand infrastructure state
understand configuration drift
create reusable infrastructure definitions
understand modules
validate IaC configurations
identify insecure IaC configurations
understand secrets management
understand version control
understand deployment testing
understand rollback
understand immutable infrastructure
understand infrastructure lifecycle management
build an IaC deployment workflow

01 — Understand Infrastructure as Code

Infrastructure as Code means:

Defining and managing infrastructure using machine-readable configuration rather than relying entirely on manual configuration.

Traditional approach:

Engineer
   ↓
Cloud Portal
   ↓
Click
   ↓
Configure
   ↓
Deploy

IaC approach:

Engineer
   ↓
Infrastructure Code
   ↓
IaC Engine
   ↓
Cloud API
   ↓
Infrastructure

02 — Why Infrastructure as Code Matters

IaC can provide:

Consistency

Repeatability

Automation

Version Control

Standardization

Auditability

Scalability

Instead of asking:

How was this environment configured?

you can inspect:

Infrastructure Definition

03 — Understand the IaC Workflow

A common workflow is:

Requirement
     ↓
Architecture
     ↓
IaC Definition
     ↓
Validation
     ↓
Plan
     ↓
Approval
     ↓
Deployment
     ↓
Verification

04 — Manual Deployment vs IaC

Manual:

Engineer
   ↓
Portal
   ↓
Resource

IaC:

Template
   ↓
IaC Engine
   ↓
Cloud API
   ↓
Resources

Compare:

Manual	IaC
Human-driven	Code-driven
Harder to reproduce	Repeatable
Difficult to review	Reviewable
Configuration differences likely	Standardized
Limited version history	Version controlled
Manual rollback	Version-based recovery possible

05 — Understand Imperative Infrastructure

Imperative automation describes:

How to perform the operation.

Example:

Create Network

Create Subnet

Create Security Group

Create VM

Attach Storage

The instructions define the sequence.

06 — Understand Declarative Infrastructure

Declarative IaC describes:

What the desired infrastructure should look like.

Example:

Desired State

Network Exists
Subnet Exists
VM Exists
Storage Attached

The IaC engine determines how to reach that state.

07 — Imperative vs Declarative

IMPERATIVE

Do Step A
    ↓
Do Step B
    ↓
Do Step C

versus:

DECLARATIVE

Desired State
     ↓
IaC Engine
     ↓
Required Changes

08 — Understand IaC Tools

Common IaC technologies include:

Terraform

AWS CloudFormation

Azure ARM Templates

Azure Bicep

Google Cloud Infrastructure Manager

The syntax differs.

The fundamental concepts remain similar:

Resources

Variables

Dependencies

Outputs

State

Deployment

09 — Choose Your Lab Tool

For this lab, you can use an IaC tool available in your environment.

Record:

IaC Tool:

Version:

Cloud Platform:

Environment:

Authentication Method:

10 — Verify the IaC Tool

Terraform example:

terraform version

Record the version.

11 — Create Your Lab Directory

Create:

cloudplus-iac-lab/

Example:

mkdir cloudplus-iac-lab
cd cloudplus-iac-lab

Your project may eventually contain:

cloudplus-iac-lab/
│
├── main.tf
├── variables.tf
├── outputs.tf
└── README.md

12 — Understand IaC Resources

A resource represents infrastructure that should exist.

Examples:

Virtual Network

Subnet

Virtual Machine

Security Group

Storage

Database

Load Balancer

Conceptually:

resource "resource_type" "resource_name" {

    configuration = "value"

}

13 — Create Your First Terraform Configuration

Create:

main.tf

A safe local example:

terraform {
  required_version = ">= 1.0.0"
}

This allows you to practice the IaC workflow without immediately creating cloud resources.

14 — Initialize the IaC Project

For Terraform:

terraform init

The initialization process prepares the working directory.

Conceptually:

Configuration
      ↓
Initialize
      ↓
Providers / Modules
      ↓
Working Environment

15 — Validate the Configuration

Run:

terraform validate

Expected:

Configuration Valid

If validation fails:

Error
   ↓
Review Configuration
   ↓
Correct
   ↓
Validate Again

16 — Understand Formatting

Consistent formatting improves readability.

Terraform:

terraform fmt

IaC is code.

Therefore:

Readability and maintainability matter.

17 — Understand Providers

IaC tools need a mechanism for interacting with infrastructure platforms.

Conceptually:

IaC Configuration
      ↓
Provider
      ↓
Cloud API
      ↓
Cloud Resources

Examples may include providers for:

AWS

Azure

Google Cloud

Kubernetes

18 — Understand Authentication

The provider must authenticate.

IaC Tool
   ↓
Identity
   ↓
Authentication
   ↓
Authorization
   ↓
Cloud API

19 — Avoid Administrator Credentials

Do not automatically use:

Global Administrator

Root Account

Owner

for routine IaC deployments.

Instead:

Deployment Requirements
       ↓
Required Permissions
       ↓
Least-Privilege Identity

20 — Never Hardcode Cloud Credentials

Poor:

access_key = "SECRET"
secret_key = "SECRET"

Avoid embedding credentials directly in infrastructure definitions.

Prefer approved authentication mechanisms.

21 — Understand Variables

Without variables:

environment = "development"
region      = "region-a"

repeated throughout the configuration.

Variables allow:

Input
   ↓
Reusable Configuration

22 — Create variables.tf

Example:

variable "environment" {
  description = "Deployment environment"
  type        = string
  default     = "development"
}

23 — Add Another Variable

variable "project_name" {
  description = "Project name"
  type        = string
  default     = "cloudplus"
}

24 — Understand Variable Types

Common types include:

string

number

bool

list

map

object

Example:

variable "enable_monitoring" {
  type    = bool
  default = true
}

25 — Understand Parameterization

Instead of maintaining:

development-template

testing-template

production-template

you may use:

Reusable Template
      ↓
Parameters
      ↓
Different Environment

26 — Example Environment Variables

environment

region

network_cidr

instance_size

instance_count

enable_monitoring

backup_enabled

27 — Understand Outputs

Outputs expose useful deployment information.

Examples:

VM IP Address

Load Balancer Address

Resource ID

Network ID

28 — Create outputs.tf

Example:

output "environment" {
  value = var.environment
}

output "project_name" {
  value = var.project_name
}

29 — Understand Dependencies

Cloud resources frequently depend on other resources.

Example:

Network
   ↓
Subnet
   ↓
VM

A VM cannot be placed into a subnet that does not exist.

30 — Build the Dependency Graph

Virtual Network
      ↓
Subnet
      ↓
Security Controls
      ↓
Compute
      ↓
Load Balancer

IaC tools can often infer dependencies from resource references.

31 — Explicit vs Implicit Dependencies

Implicit:

Resource B
references
Resource A

Therefore:

A
↓
B

Explicit dependencies may be defined when the relationship cannot be inferred automatically.

32 — Understand Desired State

Suppose the code defines:

VM Count:
2

Current environment:

VM Count:
1

The IaC engine compares:

Current State
      ↓
Desired State
      ↓
Difference

and determines the required action.

33 — Understand Deployment Planning

One of the most important IaC practices is reviewing intended changes before deployment.

Terraform:

terraform plan

Conceptually:

Configuration
      ↓
Current State
      ↓
Comparison
      ↓
Proposed Changes

34 — Never Treat the Plan as Noise

A plan may indicate:

+ Create

~ Modify

- Delete

Deletion deserves particular attention.

35 — Review Before Apply

Use:

Write
   ↓
Validate
   ↓
Plan
   ↓
Review
   ↓
Apply

not:

Write
   ↓
Apply Immediately

36 — Understand Apply

Terraform example:

terraform apply

This can modify real infrastructure.

Only apply configurations in:

Authorized Lab Environments

and review the plan first.

37 — Build a Safe Deployment Workflow

Code
  ↓
Format
  ↓
Validate
  ↓
Security Check
  ↓
Plan
  ↓
Review
  ↓
Approval
  ↓
Apply
  ↓
Verify

38 — Verify Deployment

Do not assume:

IaC Apply Successful
=
Application Working

Validate:

Resources Exist

Network Correct

Security Correct

Application Reachable

Monitoring Enabled

39 — Understand IaC State

Some IaC tools maintain information about deployed resources.

Terraform commonly uses:

State

Conceptually:

Configuration
      +
State
      +
Real Infrastructure
      ↓
Change Calculation

40 — Understand Terraform State

State helps Terraform map:

Code Resource

to:

Real Cloud Resource

This makes state operationally important.

41 — Protect State

State may contain:

Resource IDs

Infrastructure Details

Configuration Values

Potentially Sensitive Information

Therefore:

Treat state as sensitive operational data.

42 — Do Not Commit Sensitive State Carelessly

For Terraform projects, review whether files such as:

terraform.tfstate

should be stored in the source repository.

Generally, infrastructure code and infrastructure state require different handling.

43 — Understand Remote State

Teams may centrally store state to improve:

Collaboration

Consistency

Availability

Controlled Access

Conceptually:

Engineer A
      \
       → Remote State
      /
Engineer B

44 — Understand State Locking

Imagine:

Engineer A
Changes Network

Engineer B
Changes Network

Same Time

This can create conflicts.

State locking can help prevent concurrent modifications where supported.

45 — Understand Configuration Drift

Suppose IaC defines:

Firewall Rule:
Port 443

An administrator manually changes the environment:

Firewall Rule:
Port 443
Port 22

Now:

Code
≠
Actual Environment

This is:

Configuration drift.

46 — Common Causes of Drift

Manual Changes

Emergency Changes

Unmanaged Resources

Incomplete Automation

Multiple Management Tools

47 — Detect Drift

Use:

Desired Configuration
        ↓
Compare
        ↓
Actual Infrastructure
        ↓
Difference

A planning operation may help reveal unexpected differences.

48 — Do Not Automatically Correct Every Drift

Example:

Emergency Security Change
      ↓
IaC Reverts Change

That could be dangerous.

Investigate:

Why Did Drift Occur?

Was It Authorized?

Should Code Be Updated?

Should Infrastructure Be Reverted?

49 — Build the Drift Workflow

Detect Drift
     ↓
Investigate
     ↓
Authorized?
  /        \
YES         NO
 ↓           ↓
Update      Restore
Code        Desired State

50 — Understand Reusable Infrastructure

Poor design:

1000 Lines
Repeated
Repeated
Repeated

Better:

Reusable Component
      ↓
Parameters
      ↓
Multiple Deployments

51 — Understand Modules

A module packages reusable infrastructure configuration.

Example:

Network Module

Compute Module

Database Module

Monitoring Module

52 — Build a Module Architecture

Production Environment
        |
        +---- Network Module
        |
        +---- Compute Module
        |
        +---- Database Module
        |
        +---- Monitoring Module

53 — Why Modules Matter

Modules can improve:

Reusability

Consistency

Maintainability

Standardization

54 — Avoid Giant IaC Templates

Poor:

one-file.tf
5000 Lines

Better:

main.tf

variables.tf

outputs.tf

network.tf

compute.tf

security.tf

or appropriately structured modules.

55 — Understand Naming Standards

Define predictable names.

Example:

cloudplus-dev-web-01

cloudplus-dev-db-01

cloudplus-prod-web-01

A possible structure:

Project
-
Environment
-
Workload
-
Number

56 — Automate Tags Through IaC

Instead of manually adding:

Environment

Owner

CostCenter

define them through code.

Conceptually:

tags = {
  Environment = "development"
  Owner       = "cloud-team"
  CostCenter  = "IT"
}

57 — Why IaC Tagging Matters

Every deployed resource can inherit consistent:

Ownership

Environment

Cost Allocation

Governance Metadata

This connects directly to:

Lab 21 — Cloud Cost Optimization Lab

58 — Build a Standard Tag Set

Environment

Application

Owner

CostCenter

ManagedBy

Example:

ManagedBy = IaC

59 — Understand IaC Security

IaC can create insecure infrastructure very quickly.

Example:

Insecure Template
      ↓
Deploy
      ↓
100 Insecure Resources

Therefore:

Security validation must happen before deployment whenever possible.

60 — Identify Insecure Network Definitions

Look for configurations that allow:

0.0.0.0/0
      ↓
Administrative Port

Examples might include unnecessary public exposure of:

SSH

RDP

Database Ports

61 — Identify Unencrypted Storage

Check templates for:

Encryption Disabled

where organizational policy requires encryption.

62 — Identify Public Storage

Look for:

Public Access Enabled

where it is not required.

63 — Identify Excessive IAM Permissions

Poor:

Action = "*"

Resource = "*"

where the workload requires only limited permissions.

64 — Identify Hardcoded Secrets

Search IaC files for:

password

secret

token

api_key

private_key

Do not assume every occurrence is a secret, but investigate them.

65 — Use Secret Management

Prefer:

IaC
 ↓
Secret Reference
 ↓
Secret Management System

instead of:

IaC
 ↓
Plaintext Secret

66 — Understand Sensitive Variables

Some IaC tools allow values to be marked sensitive.

This can help reduce accidental display.

But remember:

Marking a variable sensitive does not automatically solve secret storage.

67 — Understand IaC Scanning

IaC security tools can evaluate configurations before deployment.

Conceptually:

IaC Code
   ↓
Scanner
   ↓
Policy / Security Rules
   ↓
Findings

68 — Example IaC Findings

Public Storage

Open Security Group

Encryption Disabled

Missing Logging

Missing Tags

Excessive Permissions

69 — Build an IaC Security Checklist

[ ] No hardcoded secrets
[ ] Encryption enabled
[ ] Public exposure minimized
[ ] Least privilege applied
[ ] Logging enabled
[ ] Monitoring enabled
[ ] Backups configured
[ ] Required tags present
[ ] Network rules reviewed
[ ] Production safeguards applied

70 — Understand Policy as Code

Organizations may define infrastructure rules programmatically.

Example:

Infrastructure Definition
       ↓
Policy Check
       ↓
Compliant?
    /        \
 YES          NO
  ↓            ↓
Deploy       Block

71 — Example Policies

Storage Must Be Encrypted

Public Databases Prohibited

Required Tags Must Exist

Approved Regions Only

Administrative Ports Restricted

72 — Understand Version Control

IaC should generally be managed as source code.

Example:

Developer
   ↓
Git
   ↓
Repository
   ↓
Review
   ↓
Deployment

73 — Initialize Git

Example:

git init

Check:

git status

74 — Create .gitignore

Terraform projects commonly exclude generated or sensitive local artifacts as appropriate.

Example:

.terraform/
*.tfstate
*.tfstate.*
*.tfvars

Review exclusions according to your project’s requirements.

75 — Do Not Blindly Ignore Every Variable File

A variable file might contain:

Region

Environment

Instance Size

or:

Passwords

Secrets

Understand what the file contains before deciding how it should be stored.

76 — Create Your First Commit

Example:

git add .
git commit -m "Create initial Cloud+ IaC lab"

77 — Understand Change History

Version control allows:

Version 1
   ↓
Version 2
   ↓
Version 3

You can determine:

Who Changed It?

What Changed?

When?

Why?

78 — Use Code Review

Production IaC should not rely only on:

Author
   ↓
Deploy

A stronger workflow:

Author
   ↓
Pull Request
   ↓
Review
   ↓
Validation
   ↓
Approval
   ↓
Deployment

79 — Review IaC Changes

Review:

Resource Creation

Resource Modification

Resource Deletion

Network Exposure

IAM Changes

Encryption Changes

Backup Changes

80 — Treat Deletion Carefully

A change from:

Database Exists

to:

Database Removed

may result in destructive action.

Before approval:

Review Data

Review Backup

Review Dependencies

Review Retention

Confirm Approval

81 — Understand Deployment Testing

Before production:

Code
   ↓
Validate
   ↓
Test Environment
   ↓
Deploy
   ↓
Verify

82 — Build an IaC Test Environment

Where practical:

Development

or

Sandbox

Use smaller and lower-cost resources when possible.

83 — Test Repeatability

Deploy:

Environment A

using the template.

Then deploy:

Environment B

using the same reusable definition with different parameters.

Compare:

Architecture

Security

Tags

Monitoring

Configuration

84 — Test Idempotency

Run the deployment again without changing the code.

Ideally:

Desired State
=
Current State

therefore:

No Unnecessary Changes

85 — Test Variable Changes

Change:

instance_count = 1

to:

instance_count = 2

Run the planning operation.

Observe the proposed infrastructure change before applying it.

86 — Test Resource Removal

Remove a test resource from the configuration.

Run:

terraform plan

Observe:

Resource Destruction Proposed

Do not apply unless the lab resource can safely be destroyed.

87 — Understand Infrastructure Lifecycle

Infrastructure commonly moves through:

Define
   ↓
Validate
   ↓
Deploy
   ↓
Operate
   ↓
Modify
   ↓
Replace
   ↓
Destroy

IaC can manage this entire lifecycle.

88 — Understand Resource Replacement

Some configuration changes cannot happen in place.

The IaC tool may need to:

Destroy Old Resource
      ↓
Create New Resource

or:

Create Replacement
      ↓
Transition
      ↓
Remove Old Resource

Review plans carefully.

89 — Understand Immutable Infrastructure

Traditional:

Server
   ↓
Modify
   ↓
Modify
   ↓
Patch
   ↓
Modify

Immutable approach:

New Configuration
      ↓
Build New Resource
      ↓
Validate
      ↓
Replace Old Resource

90 — Benefits of Immutable Infrastructure

Potential benefits include:

Consistency

Predictability

Reduced Drift

Repeatable Deployment

91 — Understand Rollback

Suppose:

IaC Version 2
      ↓
Deployment
      ↓
Application Failure

You need a recovery strategy.

Conceptually:

Failure
   ↓
Rollback / Forward Fix
   ↓
Validated State

92 — Version Control Is Not the Entire Rollback Plan

Simply reverting code may not automatically restore:

Deleted Data

Database Contents

Stateful Resources

Therefore consider:

Backups

Snapshots

Data Recovery

State

Dependencies

93 — Build an IaC Rollback Plan

Document:

Change:

Resources Affected:

Failure Condition:

Rollback Method:

Backup Required:

State Impact:

Data Impact:

Validation:

Owner:

94 — Understand IaC and CI/CD

A mature workflow may look like:

Developer
   ↓
Git Commit
   ↓
CI Pipeline
   ↓
Formatting
   ↓
Validation
   ↓
Security Scan
   ↓
Plan
   ↓
Review
   ↓
Approval
   ↓
Deployment

95 — Understand CI

Continuous Integration can automatically perform:

Syntax Validation

Formatting Checks

Security Scanning

Policy Validation

Testing

96 — Understand CD

Continuous Delivery/Deployment can help automate infrastructure releases after required checks.

Conceptually:

Approved IaC
      ↓
Deployment Pipeline
      ↓
Cloud Environment

97 — Do Not Automatically Deploy Every Change to Production

High-risk infrastructure changes may require:

Review

Approval

Maintenance Window

Rollback Plan

98 — Separate Environments

Avoid mixing:

Development

Testing

Production

without appropriate boundaries.

Use:

Separate Parameters

Separate State

Separate Accounts / Projects / Subscriptions

where architecture requires.

99 — Understand Environment Promotion

A possible workflow:

Development
      ↓
Testing
      ↓
Staging
      ↓
Production

Use the same validated infrastructure patterns where appropriate.

100 — Understand IaC Documentation

Your project should explain:

Purpose

Architecture

Prerequisites

Variables

Deployment

Validation

Rollback

Cleanup

101 — Create README.md

Include:

# Cloud+ IaC Lab

## Purpose

## Architecture

## Prerequisites

## Variables

## Deployment Steps

## Validation

## Security Considerations

## Cleanup

102 — Build Your Lab Architecture

Create a simple architecture:

                    Internet
                       |
                       v
                 Load Balancer
                       |
               +-------+-------+
               |               |
               v               v
            Web-01          Web-02
               |               |
               +-------+-------+
                       |
                       v
                    Database

Infrastructure components may include:

Network

Public Subnet

Private Subnet

Security Controls

Compute

Load Balancer

Database

103 — Define the Network

Conceptually:

Network
CIDR:
10.20.0.0/16

104 — Define Subnets

Example:

Public:
10.20.1.0/24

Private:
10.20.10.0/24

105 — Define Security Controls

Design:

Internet
   ↓
HTTPS
   ↓
Load Balancer
   ↓
Application
   ↓
Database

Avoid unnecessary:

Internet
   ↓
Database

106 — Define Compute

Parameters:

Instance Size

Instance Count

Image

Subnet

Security Controls

Tags

107 — Define Storage

Consider:

Capacity

Performance

Encryption

Backup

Lifecycle

108 — Define Monitoring

Include where appropriate:

Metrics

Logs

Alerts

Resource Health

Infrastructure should not become:

Deploy
   ↓
Forget

109 — Define Backup Requirements

Consider:

Backup Enabled

Retention

Recovery Requirements

This connects with previous Cloud+ labs.

110 — Add Cost Governance

Include:

Environment

Owner

CostCenter

Application

ManagedBy

tags.

111 — Build the Desired Architecture

                        IaC Repository
                              |
                              v
                         Validation
                              |
                              v
                            Plan
                              |
                              v
                          Approval
                              |
                              v
                           Deploy
                              |
                              v
                    +------------------+
                    | Cloud Environment |
                    +------------------+
                              |
            +-----------------+-----------------+
            |                 |                 |
            v                 v                 v
         Network           Compute          Storage
            |                 |                 |
            +-----------------+-----------------+
                              |
                              v
                          Monitoring

112 — Run Formatting

Terraform:

terraform fmt -recursive

Review changes.

113 — Run Validation

terraform validate

Record:

Validation:

PASS / FAIL

114 — Run Security Review

Check:

[ ] No plaintext credentials
[ ] No unnecessary public access
[ ] Encryption enabled
[ ] IAM permissions reviewed
[ ] Logging configured
[ ] Monitoring configured
[ ] Required tags present
[ ] Backup requirements considered

115 — Generate the Deployment Plan

terraform plan

Review:

Resources to Add:

Resources to Change:

Resources to Destroy:

116 — Review Destructive Changes

If:

Destroy > 0

ask:

Why?

Expected?

Data Impact?

Backup?

Approved?

117 — Deploy to the Lab Environment

Only after validation and review:

terraform apply

Use only resources authorized for the lab.

118 — Validate the Deployed Environment

Verify:

[ ] Network exists
[ ] Subnets correct
[ ] Compute deployed
[ ] Security rules correct
[ ] Storage configured
[ ] Encryption enabled
[ ] Tags present
[ ] Monitoring operational
[ ] Application connectivity works

119 — Perform Drift Test

In a disposable lab environment, make a small authorized manual change.

For example:

Change a Non-Critical Tag

Then run:

terraform plan

Observe whether the IaC tool identifies the difference.

120 — Restore Desired State

Decide whether to:

Update Code

or:

Restore Infrastructure

For this controlled lab, restore the intended configuration.

121 — Test Repeat Execution

Run the plan again.

Expected:

No Unexpected Changes

This demonstrates:

Desired State
+
Idempotency

122 — Perform Cleanup

When the lab environment is no longer required:

terraform plan -destroy

Review carefully.

Then, if authorized:

terraform destroy

123 — Verify Cleanup

Do not assume everything disappeared.

Check:

Compute

Storage

Public IPs

Load Balancers

Databases

Snapshots

Network Resources

This is important because leftover resources may continue generating cost.

124 — Troubleshooting Scenario — Initialization Fails

Check:

Internet Connectivity

Provider Configuration

Tool Version

Authentication

Configuration Syntax

125 — Troubleshooting Scenario — Validation Fails

Investigate:

Syntax

Missing Arguments

Incorrect References

Invalid Variable Types

126 — Troubleshooting Scenario — Authentication Fails

Check:

Identity

Credential Source

Session

Account / Subscription / Project

Authentication Configuration

127 — Troubleshooting Scenario — Permission Denied

Authentication may be successful.

Authorization may not be.

Check:

Automation Identity
      ↓
Assigned Permissions
      ↓
Required API Operation

128 — Troubleshooting Scenario — Plan Wants to Delete Production Resource

Do not apply.

Investigate:

Code Change

State

Resource Address

Configuration Drift

Environment Selection

129 — Troubleshooting Scenario — Resource Already Exists

Determine whether it is:

Managed by IaC?

Created Manually?

Part of Another Deployment?

Do not blindly recreate or delete it.

130 — Troubleshooting Scenario — Deployment Partially Fails

Review:

Error

Created Resources

State

Dependencies

Cloud Audit Logs

Determine whether to:

Retry

Correct Configuration

Rollback

Perform Controlled Cleanup

131 — Troubleshooting Scenario — Infrastructure Changed Manually

Think:

Configuration drift.

Determine whether:

Manual Change Was Authorized

and whether:

Code

or:

Infrastructure

should become the authoritative desired state.

132 — Troubleshooting Scenario — Secret Found in Repository

Treat it as potential credential exposure.

Actions may include:

Stop Further Exposure
      ↓
Rotate Credential
      ↓
Remove Secret from Active Configuration
      ↓
Review Repository Exposure
      ↓
Investigate Usage

Follow organizational incident-response procedures.

133 — Troubleshooting Scenario — IaC Deployment Breaks Application

Use:

Deployment History

Plan

Logs

Monitoring

Application Health

Determine whether to:

Rollback

or

Forward Fix

134 — Troubleshooting Scenario — State File Missing

Do not immediately recreate infrastructure.

Investigate:

Remote State

Backups

Repository Configuration

Existing Infrastructure

State loss can create serious management problems.

135 — Troubleshooting Scenario — Two Engineers Deploy Simultaneously

Risk:

Conflicting Changes

Use appropriate:

State Locking

Change Control

Deployment Pipeline

136 — Troubleshooting Scenario — Destroy Leaves Resources Behind

Review:

Manually Created Resources

Dependencies

Protection Settings

Failed Deletions

External Resources

137 — Build the IaC Operational Framework

Remember:

DESIGN
   ↓
CODE
   ↓
FORMAT
   ↓
VALIDATE
   ↓
SCAN
   ↓
PLAN
   ↓
REVIEW
   ↓
APPROVE
   ↓
DEPLOY
   ↓
VERIFY
   ↓
MONITOR
   ↓
DETECT DRIFT
   ↓
UPDATE

138 — Build the IaC Findings Register

Finding	Risk	Recommendation	Priority
Manual Infrastructure Deployment	Configuration Differences	Implement IaC	High
Hardcoded Credential	Credential Exposure	Use Secure Authentication	Critical
Public Administrative Port	Unauthorized Access	Restrict Network Rule	Critical
Encryption Disabled	Data Exposure	Enable Encryption	High
Missing Tags	Governance Gap	Define Tags in IaC	Medium
No Version Control	Poor Change Tracking	Store IaC in Git	High
No Plan Review	Unintended Changes	Review Before Apply	High
State Stored Insecurely	Infrastructure Exposure	Secure State	High
Manual Changes	Configuration Drift	Implement Drift Management	Medium
No Rollback Plan	Recovery Risk	Document Rollback	High

139 — Create the IaC Deployment Runbook

Use:

Runbook:
Infrastructure as Code Deployment

Project:

Environment:

Cloud Platform:

IaC Tool:

Repository:

Deployment Identity:

Required Permissions:

State Location:

Variables:

Pre-Deployment Checks:

Formatting:

Validation:

Security Scanning:

Plan:

Plan Review:

Approval:

Deployment:

Post-Deployment Validation:

Monitoring:

Drift Detection:

Rollback:

Cleanup:

Escalation:

140 — Create the Final Lab Report

Use:

Lab:
Infrastructure as Code Lab

Cloud Platform:

IaC Tool:

Tool Version:

Environment:

Architecture:

Resources Defined:

Variables:

Outputs:

Dependencies:

Authentication:

Permissions:

State:

Version Control:

Validation Result:

Security Review:

Deployment Plan:

Resources Added:

Resources Changed:

Resources Destroyed:

Deployment Result:

Post-Deployment Validation:

Drift Test:

Idempotency Test:

Rollback Strategy:

Cleanup Result:

Findings:

Recommendations:

Lessons Learned:

🧪 Final Validation Checklist

Validation	Status
Infrastructure as Code understood
Imperative vs declarative understood
IaC tool verified
Project directory created
Configuration created
Initialization completed
Formatting completed
Validation completed
Resources understood
Providers understood
Authentication reviewed
Least privilege reviewed
Variables created
Outputs created
Dependencies understood
Desired state understood
Deployment planning completed
Destructive changes reviewed
State understood
State protection understood
Configuration drift understood
Modules understood
Naming standard defined
Tagging defined
Security configuration reviewed
Hardcoded secrets checked
IaC scanning understood
Policy as Code understood
Version control configured
Code review understood
Deployment testing performed
Idempotency tested
Infrastructure lifecycle understood
Immutable infrastructure understood
Rollback documented
CI/CD integration understood
Deployment validated
Drift test performed
Cleanup completed
Findings documented

🎯 Certification Connection

A Cloud+ scenario may say:

Multiple engineers manually create identical environments, but configurations are different.

Think:

Infrastructure as Code and standardized templates.

Another:

The organization wants infrastructure changes reviewed before resources are modified.

Think:

IaC planning and code review.

Another:

An engineer manually changes a firewall rule that is managed by IaC.

Think:

Configuration drift.

Another:

An infrastructure template contains a plaintext administrator password.

Think:

Secret-management failure.

Another:

Infrastructure code gives a workload unrestricted permissions.

Think:

Least-privilege failure.

Another:

Two engineers attempt to modify the same Terraform-managed infrastructure simultaneously.

Think:

Remote state, locking, and controlled deployment workflows.

Another:

The organization wants identical development, testing, and production architectures.

Think:

Reusable templates/modules with environment-specific parameters.

🎤 Interview Questions

Practice without notes.

1. What is Infrastructure as Code?

2. Why is IaC useful?

3. Imperative vs declarative infrastructure?

4. What is desired state?

5. What is an IaC provider?

6. What are variables?

7. What are outputs?

8. Why do dependencies matter?

9. What does `terraform init` do?

10. What does `terraform validate` do?

11. What does `terraform plan` do?

12. Why should you review a plan?

13. What is Terraform state?

14. Why should state be protected?

15. What is remote state?

16. What is state locking?

17. What is configuration drift?

18. What is an IaC module?

19. Why use version control for IaC?

20. How should secrets be handled?

21. What is IaC scanning?

22. What is Policy as Code?

23. What is immutable infrastructure?

24. How would you test an IaC deployment?

25. How would you safely deploy an infrastructure change?

🚨 Scenario Interview Question 1

Terraform proposes deleting a production database.

Do not immediately apply.

Review:

Configuration
      ↓
State
      ↓
Plan
      ↓
Database Data
      ↓
Backup
      ↓
Business Impact

🚨 Scenario Interview Question 2

The configuration says port 22 is restricted, but the cloud portal shows it open to the internet.

Think:

Configuration drift.

🚨 Scenario Interview Question 3

A developer commits a cloud access key to an IaC repository.

Treat it as:

credential exposure.

Rotate the credential and follow the organization’s response process.

🚨 Scenario Interview Question 4

Development and production need the same architecture but different VM sizes.

Use:

Reusable Infrastructure
        +
Environment Parameters

🚨 Scenario Interview Question 5

Every time the configuration is applied, unnecessary resources change.

Investigate:

Idempotency

Provider Behavior

Dynamic Values

State

Configuration

🚨 Scenario Interview Question 6

Engineers regularly change IaC-managed resources manually.

The organization needs stronger:

Change Management

Drift Detection

IaC Governance

🚨 Scenario Interview Question 7

A network module is used by 50 environments.

A change to that module requires:

Impact Analysis

Testing

Versioning

Controlled Rollout

🚨 Scenario Interview Question 8

The IaC deployment completes successfully, but users cannot access the application.

Remember:

Deployment Success
≠
Application Success

Perform post-deployment validation.

🧠 IaC Interview Framework

Remember:

REQUIREMENT
   ↓
ARCHITECTURE
   ↓
CODE
   ↓
VARIABLES
   ↓
SECURITY
   ↓
VALIDATE
   ↓
PLAN
   ↓
REVIEW
   ↓
APPROVE
   ↓
DEPLOY
   ↓
VERIFY
   ↓
MONITOR
   ↓
DRIFT
   ↓
LIFECYCLE

💬 Interview Tip

Avoid:

“IaC lets us deploy cloud resources automatically.”

A stronger answer is:

“Infrastructure as Code allows infrastructure to be defined in machine-readable configuration and managed through a repeatable software-style lifecycle. I would store the infrastructure definitions in version control, parameterize reusable components, validate and security-scan changes, generate and review the deployment plan, deploy using a least-privilege identity, verify the resulting infrastructure, protect the infrastructure state, monitor for configuration drift, and maintain rollback and recovery procedures for high-risk changes.”

That demonstrates Cloud Engineer and DevOps thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. IaC Repository

Include:

main.tf

variables.tf

outputs.tf

README.md

2. Architecture Diagram

Show:

Internet
   ↓
Load Balancer
   ↓
Compute
   ↓
Database

3. Deployment Plan

Document:

Add

Change

Destroy

operations.

4. IaC Security Review

Include:

Network Exposure

Encryption

IAM

Secrets

Logging

Tags

5. Drift Assessment

Demonstrate:

Desired State
      ↓
Manual Change
      ↓
Drift Detection
      ↓
Remediation

6. IaC Deployment Runbook

Document the complete deployment lifecycle.

7. IaC Findings Register

Include:

Finding

Risk

Recommendation

Priority

📝 Resume Examples

Instead of:

Worked with Terraform.

Use:

Built and validated Infrastructure as Code configurations to provision repeatable cloud environments using reusable variables, dependencies, standardized tagging, deployment planning, and configuration-drift management.

Or:

Implemented IaC deployment workflows incorporating version control, configuration validation, security review, change planning, least-privilege deployment identities, post-deployment verification, and rollback procedures.

Or:

Applied Infrastructure as Code practices to standardize cloud networking, compute, storage, security, monitoring, and governance configurations across repeatable cloud environments.

⭐ Job-Readiness Check

You should now be able to:

explain Infrastructure as Code
compare imperative and declarative approaches
understand desired state
understand IaC resources
work with variables
understand outputs
understand dependencies
initialize an IaC project
validate configurations
generate deployment plans
review destructive changes
understand infrastructure state
protect state
understand remote state
explain state locking
detect configuration drift
understand reusable modules
define naming standards
automate tagging
identify insecure IaC
identify hardcoded secrets
understand IaC scanning
understand Policy as Code
use version control
understand code review
test IaC deployments
test idempotency
understand infrastructure lifecycle
explain immutable infrastructure
design rollback procedures
understand CI/CD integration
validate deployments
safely clean up IaC resources

🏆 Mission Complete

You have progressed from:

Manual Infrastructure
      ↓
Individual Configuration
      ↓
Configuration Differences

to:

Infrastructure Definition
      ↓
Version Control
      ↓
Validation
      ↓
Security Review
      ↓
Plan
      ↓
Deployment
      ↓
Verification
      ↓
Drift Management

You now understand an important cloud engineering principle:

Infrastructure should be repeatable, reviewable, testable, and recoverable—not dependent on someone remembering which buttons they clicked in the cloud portal.

🚀 What’s Next?

You can now:

Automate Operations
        +
Define Infrastructure as Code

The next progression is bringing these capabilities into a controlled software delivery workflow.

Instead of:

Engineer
   ↓
Build Code
   ↓
Manually Test
   ↓
Manually Deploy

you will work toward:

Code
   ↓
Version Control
   ↓
Build
   ↓
Test
   ↓
Security Validation
   ↓
Deployment
   ↓
Monitoring

In the next lab, you will work with:

CI/CD fundamentals
source control workflows
build pipelines
automated testing
deployment pipelines
pipeline stages
artifacts
environment promotion
approvals
secrets management
pipeline security
deployment strategies
rollback
pipeline monitoring
cloud infrastructure integration

➡️ Next: Lab 24 — Cloud CI/CD Pipeline Lab