Drift detection in CI/CD in Terraform - Commands & Configuration

Introduction

Infrastructure drift happens when the real cloud setup changes outside your code. Drift detection helps find these differences automatically during your CI/CD process to keep your setup reliable and consistent.

When you want to ensure your cloud resources match your Terraform code after manual changes.

When you run automated pipelines that deploy infrastructure and want to catch unexpected changes early.

When multiple team members manage infrastructure and you want to avoid conflicts or surprises.

When you want to maintain compliance by verifying infrastructure state regularly.

When you want to prevent outages caused by unnoticed configuration changes.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.3.0"
  backend "local" {}
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "example" {
  bucket = "example-drift-detection-bucket"
  acl    = "private"
}

This Terraform file sets up a simple AWS S3 bucket resource.

The terraform block specifies the required Terraform version and uses a local backend for state storage.

The provider block configures AWS region.

The aws_s3_bucket resource creates a private S3 bucket named example-drift-detection-bucket.

Commands

Initializes the Terraform working directory, downloads provider plugins, and prepares the backend.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.

Applies the Terraform configuration to create or update infrastructure without asking for confirmation.

Terminal

terraform apply -auto-approve

Expected Output

aws_s3_bucket.example: Creating...

aws_s3_bucket.example: Creation complete after 3s [id=example-drift-detection-bucket]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Skips interactive approval prompt to automate deployment.

Checks for any differences between the current infrastructure and the Terraform code to detect drift. The exit code helps CI/CD pipelines decide next steps.

Terminal

terraform plan -detailed-exitcode

Expected Output

No changes. Infrastructure is up-to-date.

→

-detailed-exitcode - Returns exit code 2 if there are changes, 0 if no changes, 1 if error.

Run this command again after manually changing the S3 bucket outside Terraform to detect drift.

Terminal

terraform plan -detailed-exitcode

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  ~ update in-place



Terraform will perform the following actions:



  # aws_s3_bucket.example will be updated in-place

  ~ acl = "private" -> "public-read"



Plan: 0 to add, 1 to change, 0 to destroy.

→

-detailed-exitcode - Detects drift by exit code 2 when changes are found.

Key Concept

If you remember nothing else from this pattern, remember: terraform plan with -detailed-exitcode lets your CI/CD detect infrastructure drift automatically.

Common Mistakes

Not using the -detailed-exitcode flag with terraform plan in CI/CD pipelines.

Without this flag, the pipeline cannot detect drift because terraform plan always returns exit code 0 even if changes exist.

Always use terraform plan -detailed-exitcode in your CI/CD to catch drift by checking the exit code.

Manually changing infrastructure without updating Terraform code.

This causes drift that can lead to unexpected behavior and deployment failures.

Make all infrastructure changes through Terraform code and pipelines to keep state consistent.

Not running terraform init before terraform plan or apply.

Terraform commands fail or behave unpredictably without initialization.

Run terraform init once before other commands in a new working directory.

Summary

Run terraform init to prepare your working directory and providers.

Use terraform apply -auto-approve to deploy infrastructure automatically.

Use terraform plan -detailed-exitcode in CI/CD to detect drift by checking for differences between code and real infrastructure.

Practice

1. What is the main purpose of drift detection in a Terraform CI/CD pipeline?

easy

A. To find differences between the Terraform code and the actual infrastructure

B. To speed up the deployment process by skipping validation

C. To automatically delete unused resources without approval

D. To generate documentation for the infrastructure

Solution

1. Step 1: Understand drift detection concept

   Drift detection compares the current real infrastructure state with the Terraform code to find differences.

2. Step 2: Identify the purpose in CI/CD

   In CI/CD, drift detection helps catch unexpected changes before applying new updates.

3. Final Answer:

   To find differences between the Terraform code and the actual infrastructure -> Option A

4. Quick Check:

   Drift detection = find differences [OK]

Hint: Drift detection = spot differences before apply [OK]

Common Mistakes:

• Thinking drift detection speeds deployment
• Assuming it deletes resources automatically
• Confusing it with documentation generation

2. Which Terraform command is commonly used in CI/CD pipelines to detect drift before applying changes?

easy

A. terraform plan

B. terraform apply

C. terraform init

D. terraform destroy

Solution

1. Step 1: Recall Terraform commands

   terraform plan shows the changes Terraform will make without applying them.

2. Step 2: Identify drift detection command

   terraform plan detects differences (drift) between code and real infrastructure before apply.

3. Final Answer:

   terraform plan -> Option A

4. Quick Check:

   Detect drift = terraform plan [OK]

Hint: Use terraform plan to preview changes [OK]

Common Mistakes:

• Using terraform apply which changes infrastructure
• Confusing terraform init with drift detection
• Using terraform destroy which deletes resources

3. Given the following Terraform plan output snippet in a CI/CD pipeline:

  # aws_instance.example will be updated in-place
  ~ tags = {
      - "Environment" = "dev"
      + "Environment" = "prod"
    }

What does this output indicate about drift?

medium

A. Terraform will ignore the tag change

B. The instance will be destroyed and recreated

C. No drift is detected; tags remain unchanged

D. The tag "Environment" has drifted from "dev" to "prod" and will be updated

Solution

1. Step 1: Analyze the plan output

   The '~' symbol means in-place update. The tag "Environment" changes from "dev" to "prod".

2. Step 2: Understand drift implication

   This shows drift: the real infrastructure tag differs from code and will be updated.

3. Final Answer:

   The tag "Environment" has drifted from "dev" to "prod" and will be updated -> Option D

4. Quick Check:

   ~ means update tag from dev to prod [OK]

Hint: Look for ~ symbol to spot in-place updates [OK]

Common Mistakes:

• Thinking resource will be destroyed instead of updated
• Ignoring tag changes as no drift
• Assuming Terraform ignores tag differences

4. You run terraform plan in your CI/CD pipeline but it does not detect drift even though manual changes were made outside Terraform. What is the most likely cause?

medium

A. Terraform automatically ignores manual changes

B. You forgot to run terraform apply first

C. Terraform state file is outdated or corrupted

D. The provider plugin is missing

Solution

1. Step 1: Understand drift detection dependency

   Terraform relies on the state file to compare real infrastructure with code.

2. Step 2: Identify cause of missed drift

   If the state file is outdated or corrupted, Terraform cannot detect manual changes (drift).

3. Final Answer:

   Terraform state file is outdated or corrupted -> Option C

4. Quick Check:

   State file outdated = missed drift detection [OK]

Hint: Check state file freshness if drift not detected [OK]

Common Mistakes:

• Assuming terraform apply affects drift detection
• Believing Terraform ignores manual changes by design
• Thinking missing provider causes drift detection failure

5. In a CI/CD pipeline, you want to automatically detect drift and fail the pipeline if any drift is found before applying changes. Which approach best achieves this?

hard

A. Run terraform apply directly and rely on errors to detect drift

B. Run terraform plan and parse its output to detect changes, then fail if changes exist

C. Skip drift detection and always apply changes

D. Manually check infrastructure outside the pipeline

Solution

1. Step 1: Understand CI/CD drift detection goal

   The goal is to detect drift and fail early before applying changes.

2. Step 2: Choose correct command and method

   terraform plan shows drift without applying; parsing its output allows pipeline to fail if drift exists.

3. Step 3: Evaluate other options

   Applying directly risks unwanted changes; manual checks are slow; skipping detection is unsafe.

4. Final Answer:

   Run terraform plan and parse its output to detect changes, then fail if changes exist -> Option B

5. Quick Check:

   Plan + parse output = fail on drift [OK]

Hint: Use terraform plan output to gate pipeline success [OK]

Common Mistakes:

• Applying without checking drift first
• Relying on manual checks in automated pipelines
• Ignoring drift detection to speed up deploys