DevOps4UA

terraform certification #4

Jenkins

Source: Dev.to | Dec 18, 2025 (UTC)

Terraform Modules

1. What Problem Do Terraform Modules Solve?

Problem in real organizations

In mid to large companies:

  • Many teams (10, 50, 100+)
  • Each team writes their own Terraform code
  • All teams create similar resources (EC2, VPC, RDS, EKS)

Result without modules

  • Same EC2 code copied everywhere
  • Hard to maintain
  • No standards
  • Security risks
  • One change = update hundreds of files

2. DRY Principle (Foundation Concept)

DRY = Don’t Repeat Yourself

Meaning:

  • Do not duplicate logic
  • Write once, reuse everywhere

Why DRY matters

  • Smaller codebase
  • Easier maintenance
  • Fewer bugs
  • Consistent behavior

Terraform Modules are Terraform’s way to apply DRY.

3. Problem Without Modules (Team-Based Example)

Example: 10 Teams

Each team writes this:

resource "aws_instance" "ec2" { ami = "ami-123" instance_type = "t2.micro" }

Enter fullscreen mode

Exit fullscreen mode

Problems this causes

  1. Code repetition
  1. Mass changes
  1. No standardization
  1. Hard to manage
  1. Hard for developers

4. Solution: Terraform Modules

What is a Terraform Module?

A module is a reusable Terraform template that:

Think of a module as:

“A reusable Terraform blueprint”

5. Centralized Template Approach (Best Practice)

How organizations do it

Teams only reference the module

Instead of writing full EC2 code, teams write:

module "ec2" { source = "../modules/ec2" }

Enter fullscreen mode

Exit fullscreen mode

That’s it.

6. Simple Module Structure (Mental Model)

Folder structure

modules/ └── ec2/ ├── main.tf ├── variables.tf └── outputs.tf

Enter fullscreen mode

Exit fullscreen mode

main.tf (inside module)

resource "aws_instance" "this" { ami = var.ami instance_type = var.instance_type }

Enter fullscreen mode

Exit fullscreen mode

variables.tf

variable "ami" {} variable "instance_type" {}

Enter fullscreen mode

Exit fullscreen mode

7. How Teams Use the Module

Team’s Terraform code

module "team1_ec2" { source = "../modules/ec2" ami = "ami-0abc" instance_type = "t3.micro" }

Enter fullscreen mode

Exit fullscreen mode

Important point

8. What Happens During terraform plan?

EC2 is created even though EC2 code is not written in the root file.

9. Multiple Modules in One Project (Real-World)

A real project may use:

module "vpc" { source = "../modules/vpc" } module "ec2" { source = "../modules/ec2" } module "rds" { source = "../modules/rds" }

Enter fullscreen mode

Exit fullscreen mode

Benefits

10. Public Modules (Terraform Registry)

Terraform provides ready-made modules at:
👉 registry.terraform.io

Popular modules:

Example: EKS

Without module:

With module:

module "eks" { source = "terraform-aws-modules/eks/aws" }

Enter fullscreen mode

Exit fullscreen mode

Thousands of lines of code reused safely.

11. Why Modules Are Critical in Production

Key Benefits

12. Interview-Ready One-Line Answer

Terraform modules allow teams to reuse standardized infrastructure code, reduce duplication, enforce best practices, and simplify infrastructure management across multiple projects and teams.

13. When You Should Use Modules

Use modules when:

Avoid modules only for:

Terraform Modules – Practical Usage with Registry Modules

1. Goal of This Practical

Requirement:

Solution:
Use a ready-made Terraform module from the Terraform Registry.

2. Why Use Ready-Made Modules First?

Before creating custom modules, every Terraform engineer must understand:

This is exactly what this practical demonstrates.

3. Terraform Registry Overview

Website:
👉 registry.terraform.io

What you’ll find there:

Example:

This confirms:

Terraform modules are heavily used in real organizations.

4. Choosing the Right Module (Important Rule)

Do NOT blindly trust every module.

Best practices:

5. Selected Module for This Demo

Module chosen:

terraform-aws-modules/ec2-instance/aws

Enter fullscreen mode

Exit fullscreen mode

Why?

6. Project Setup (Clean Slate)

Create file

ec2.tf

Enter fullscreen mode

Exit fullscreen mode

Minimal module usage

module "ec2_instance" { source = "terraform-aws-modules/ec2-instance/aws" version = "~> 5.0" }

Enter fullscreen mode

Exit fullscreen mode

Key points:

7. Initialize Terraform

terraform init

Enter fullscreen mode

Exit fullscreen mode

What happens here?

This is the first major module workflow step.

8. Terraform Plan – First Error (Very Important Learning)

terraform plan

Enter fullscreen mode

Exit fullscreen mode

Error:

Multiple EC2 instances matched. Use additional constraints…

Meaning:

9. Fixing the Error – Provide Subnet ID

Why subnet_id is needed

Get subnet ID

AWS Console:

VPC → Subnets → Copy subnet-id

Enter fullscreen mode

Exit fullscreen mode

Update module

module "ec2_instance" { source = "terraform-aws-modules/ec2-instance/aws" version = "~> 5.0" subnet_id = "subnet-xxxxxxxx" }

Enter fullscreen mode

Exit fullscreen mode

10. Terraform Plan (Successful)

terraform plan

Enter fullscreen mode

Exit fullscreen mode

Terraform will show:

Resources to be created:

  1. EC2 instance
  2. Security group
  3. Security group rules

Important:
You never wrote EC2 or SG resources yourself — module did it.

11. Terraform Apply

terraform apply -auto-approve

Enter fullscreen mode

Exit fullscreen mode

Result:

12. Verify in AWS Console

Go to:

EC2 → Instances

Enter fullscreen mode

Exit fullscreen mode

You will see:

13. Where Is the Actual EC2 Code?

Local filesystem

.terraform/ └── modules/ └── ec2_instance/ └── main.tf

Enter fullscreen mode

Exit fullscreen mode

Open main.tf

This proves:

Registry modules are production-grade, not toy examples.

14. Registry Also Provides Examples

On registry page you’ll find:

You do NOT need GitHub for basic usage — registry mirrors examples.

15. Cleanup (VERY IMPORTANT)

Always destroy resources to avoid AWS charges:

terraform destroy -auto-approve

Enter fullscreen mode

Exit fullscreen mode

16. Why This Topic Is Extremely Important

Real World

Interviews

Common questions:

Terraform Professional Certification

17. One-Line Interview Answer

Terraform modules allow reusable, standardized infrastructure definitions that simplify deployment, enforce best practices, and scale across multiple teams and environments.

Terraform Modules — Choosing the Right Module & Creating Your Own

PART 1: How to Choose the Right Terraform Module

Why This Matters

Terraform Registry has hundreds of modules for the same service (EC2, IAM, VPC, etc.).
Choosing the wrong module can lead to:

1. Check Total Downloads (First Filter)

Why

Example

Rule

Always prefer modules with high adoption unless you have strong reasons not to.

2. Check the GitHub Repository (Critical Step)

Every serious module links to GitHub. Inspect it.

What to check:

a) Contributors

Why:

b) Issues (Open vs Closed)

Look at:

Good sign

Example:

3. Avoid Single-Maintainer Modules

Why

Risk

Rule

Avoid production use of modules maintained by one person.

4. Check Documentation Quality

Well-maintained modules always have:

Red flag

5. Check Version History

Why

Compare:

Rule

No version evolution = module likely abandoned.

6. Inspect Code Quality (Optional but Powerful)

Open main.tf:

Well-written modules look professional, not experimental.

7. Check Community Signals (Stars & Forks)

On GitHub:

Rule

Higher stars + forks = stronger community trust.

8. HashiCorp Partner Modules (Trusted Source)

Some modules are maintained by HashiCorp Partners:

However:

9. Security Warning (Very Important)

❌ Never use random modules blindly
❌ Never skip reading source code

Why

Rule

If unsure → read the code or don’t use the module.

10. What Do Real Organizations Do?

Most real organizations:

This ensures:

PART 2: Designing Your Own Module Structure

1. Why Create Your Own Modules?

Organizations need:

Hence, internal modules are preferred.

2. Base Folder Structure (Industry Standard)

kplabs-terraform-modules/ │ ├── modules/ │ ├── ec2/ │ ├── vpc/ │ ├── sg/ │ └── iam/ │ └── teams/ ├── team-a/ └── team-b/

Enter fullscreen mode

Exit fullscreen mode

3. Purpose of Each Folder

modules/

teams/

4. How Teams Use Modules (Conceptual)

Example:

Teams do not write resources directly.

PART 3: Creating Your First Custom EC2 Module

1. Modules Are NOT Complex

Important clarity

A module is just normal Terraform code placed in a reusable folder.

No new syntax.
No extra complexity.

2. Creating EC2 Module

Step 1: Go to module folder

modules/ec2/

Enter fullscreen mode

Exit fullscreen mode

Step 2: Create main.tf

resource "aws_instance" "this" { ami = "ami-0abcdef" instance_type = "t2.micro" }

Enter fullscreen mode

Exit fullscreen mode

That’s it.
This is a valid Terraform module.

3. Common Question: “Is This Too Small for a Module?”

Answer: YES, it’s perfectly valid.

Modules can be:

It depends on:

4. Why Public Modules Are Huge (600+ Lines)

Public modules:

Example EC2 options:

Internal modules:

5. Key Design Principle

Public modules = generic & flexible
Internal modules = opinionated & minimal

6. What Comes Next

Next logical step:

This will complete the full module lifecycle.

Interview-Ready Summary (One Paragraph)

Terraform modules help standardize infrastructure, reduce duplication, enforce security and best practices, and allow teams to reuse infrastructure code efficiently. In production, organizations typically fork or create their own internal modules instead of relying directly on public registry modules, ensuring better control, stability, and security.

Terraform Module Sources & Referencing (Complete Guide)

PART 1: What Is a Module Source?

A module source tells Terraform where the module code lives.

Terraform supports multiple source locations, including:

  1. Terraform Registry
  2. Local filesystem (local path)
  3. Git repositories (GitHub, GitLab, Bitbucket)
  4. HTTP URLs
  5. S3 buckets
  6. Private registries

Regardless of source type:

PART 2: Basic Module Syntax (Always the Same)

module "ec2" { source = "LOCATION_OF_MODULE" }

Enter fullscreen mode

Exit fullscreen mode

Only the source value changes, depending on where the module is stored.

PART 3: Common Module Source Types (With Examples)

1. Terraform Registry (Most Common)

module "eks" { source = "terraform-aws-modules/eks/aws" version = "18.8.0" }

Enter fullscreen mode

Exit fullscreen mode

Used when:

2. Local Path (Most Common in Organizations)

Rule (EXAM IMPORTANT):

Local paths must start with ./ or ../

Example:

module "ec2" { source = "../../modules/ec2" }

Enter fullscreen mode

Exit fullscreen mode

Meaning:

3. GitHub Repository

Correct format:

module "ec2" { source = "github.com/zealvora/sample-kplabs-terraform-ec2-module" }

Enter fullscreen mode

Exit fullscreen mode

❌ Incorrect:

source = "https://github.com/..."

Enter fullscreen mode

Exit fullscreen mode

Why?

4. Generic Git Repositories

module "ec2" { source = "git::https://example.com/my-module.git" }

Enter fullscreen mode

Exit fullscreen mode

Used for:

5. HTTP URLs

module "ec2" { source = "https://example.com/modules/ec2.zip" }

Enter fullscreen mode

Exit fullscreen mode

Less common but supported.

6. S3 Buckets

module "ec2" { source = "s3::https://s3.amazonaws.com/mybucket/ec2-module.zip" }

Enter fullscreen mode

Exit fullscreen mode

Used in:

PART 4: How to Know the Correct Source Format?

Answer: Terraform Documentation

Terraform provides exact syntax for each source type:

📌 Never guess source format — always check docs

PART 5: Using Version Constraint (VERY IMPORTANT)

Why version matters

Example:

module "eks" { source = "terraform-aws-modules/eks/aws" version = "18.8.0" }

Enter fullscreen mode

Exit fullscreen mode

Meaning:

PART 6: Referencing Internal Modules Using Local Path

Folder Structure Recap

kplabs-terraform-modules/ │ ├── modules/ │ └── ec2/ │ └── main.tf │ └── teams/ └── team-a/ └── module.tf

Enter fullscreen mode

Exit fullscreen mode

team-a/module.tf

module "ec2" { source = "../../modules/ec2" }

Enter fullscreen mode

Exit fullscreen mode

Explanation:

Terraform Commands

terraform init terraform plan

Enter fullscreen mode

Exit fullscreen mode

Terraform will:

PART 7: First Module Improvement – Hardcoded Values (MAJOR ISSUE)

Problem

Module contains hardcoded values:

resource "aws_instance" "this" { ami = "ami-123" instance_type = "t2.micro" }

Enter fullscreen mode

Exit fullscreen mode

Result

instance_type = "t2.large" ❌

Enter fullscreen mode

Exit fullscreen mode

Terraform error:

argument not expected

Rule (EXAM & REAL WORLD)

Hardcoded values inside modules are a big NO

Especially for:

PART 8: Second Module Improvement – Provider Hardcoding (CRITICAL)

Problematic Code

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

Enter fullscreen mode

Exit fullscreen mode

Issues:

What Happens If Caller Tries to Override?

Caller:

provider "aws" { region = "ap-south-1" }

Enter fullscreen mode

Exit fullscreen mode

Terraform behavior:

PART 9: Correct Way to Handle Providers in Modules

DO NOT define provider with region in module

Instead use required_providers

terraform { required_providers { aws = { source = "hashicorp/aws" version = ">= 5.5" } } }

Enter fullscreen mode

Exit fullscreen mode

This means:

PART 10: Key Improvements Summary (Must Remember)

❌ Avoid in modules

✅ Use instead

Interview & Exam One-Liners

Module source

Terraform module source defines where Terraform fetches module code from, such as registry, local path, Git, S3, or HTTP.

Local path rule

Local module sources must begin with ./ or ../.

Provider best practice

Modules should declare required providers but not hardcode provider configuration like region.

Why version block matters

Module version ensures predictable and stable infrastructure behavior.

Terraform Modules – Variables & Provider Best Practices

PART 1: Why Variables Are Mandatory in Modules

The Problem with Hard-Coding

When values are hard-coded inside a module:

Example (❌ bad):

resource "aws_instance" "this" { ami = "ami-0abc" instance_type = "t2.micro" }

Enter fullscreen mode

Exit fullscreen mode

If a team needs:

PART 2: Solution – Use Variables

Convert Hard-Coded Values to Variables

Example (✅ good):

resource "aws_instance" "this" { ami = var.ami instance_type = var.instance_type }

Enter fullscreen mode

Exit fullscreen mode

Now:

PART 3: Why Professional Modules Use Many Variables

If you open any production-grade EC2 module:

Reason:

Thousands of users → thousands of requirements

PART 4: Do ALL Values Need to Be Variables?

❌ No — not always.

Best Practice Rule

Use variables intentionally, not blindly.

PART 5: Provider Hard-Coding Problem in Modules

❌ Bad Practice (Hard-coded provider)

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

Enter fullscreen mode

Exit fullscreen mode

Why This Is Dangerous

PART 6: Correct Way – required_providers

✅ Best Practice for Modules

Remove provider block
Add required_providers instead

terraform { required_providers { aws = { source = "hashicorp/aws" version = ">= 5.50" } } }

Enter fullscreen mode

Exit fullscreen mode

What This Does

PART 7: Refactoring the EC2 Module (Practical)

modules/ec2/main.tf

resource "aws_instance" "this" { ami = var.ami instance_type = var.instance_type }

Enter fullscreen mode

Exit fullscreen mode

Variable Declarations (same file for simplicity)

variable "ami" { type = string } variable "instance_type" { type = string } variable "region" { type = string }

Enter fullscreen mode

Exit fullscreen mode

In production, variables should be in variables.tf

PART 8: What Happens After Adding Variables?

Run:

terraform plan

Enter fullscreen mode

Exit fullscreen mode

Terraform error:

Missing required argument ami instance_type region

Enter fullscreen mode

Exit fullscreen mode

✅ This is expected
Now the caller must pass values

PART 9: Team Overrides Values (Caller Side)

teams/team-a/module.tf

provider "aws" { region = "ap-south-1" } module "ec2" { source = "../../modules/ec2" ami = "ami-123" instance_type = "t2.micro" }

Enter fullscreen mode

Exit fullscreen mode

PART 10: Verifying Overrides

Change value:

instance_type = "t2.large"

Enter fullscreen mode

Exit fullscreen mode

Run:

terraform plan

Enter fullscreen mode

Exit fullscreen mode

✔ Output shows:

PART 11: Key Improvements Achieved

Before

After

PART 12: Critical Best-Practice Summary (EXAM + INTERVIEW)

Variables

Modules should avoid hard-coded values and use variables to allow caller customization.

Provider

Modules should declare required_providers and never hard-code provider configuration like region.

Flexibility

A good module balances flexibility with simplicity, based on organizational needs.

Interview-Ready One-Liners

Why variables in modules?

To make modules reusable and allow teams to override configuration values.

Why not hard-code provider in module?

Because it prevents callers from controlling region and credentials.

What does required_providers do?

It declares provider compatibility without enforcing configuration.

Terraform Modules – Outputs, Root vs Child, Structure & Multiple Providers

PART 1: Module Outputs – Why They Matter

The Real Problem Modules Solve

In real organizations:

To make this work, data must flow between modules.

That is exactly what module outputs enable.

PART 2: What Is a Module Output?

A module output:

Conceptually:

Module outputs work exactly like Terraform outputs — just across module boundaries.

PART 3: The Challenge Without Module Outputs

Scenario

Attempt (❌ does NOT work)

instance = module.ec2.id

Enter fullscreen mode

Exit fullscreen mode

Error

Terraform cannot access:

PART 4: Solution – Define Outputs in the Child Module

Child module (modules/ec2/outputs.tf)

output "instance_id" { value = aws_instance.myec2.id }

Enter fullscreen mode

Exit fullscreen mode

This exposes:

PART 5: Using Module Outputs in Root Module

Root module

resource "aws_eip" "this" { instance = module.ec2.instance_id }

Enter fullscreen mode

Exit fullscreen mode

Syntax to remember:

module.<module_name>.<output_name>

Enter fullscreen mode

Exit fullscreen mode

✔ Cross-module dependency now works
✔ Terraform understands ordering automatically

PART 6: Why Module Outputs Are Critical in Production

Module outputs enable:

Without outputs:

PART 7: Root Module vs Child Module (EXAM FAVORITE)

Root Module

terraform init terraform apply

Enter fullscreen mode

Exit fullscreen mode

Example:

module "ec2" { source = "../../modules/ec2" }

Enter fullscreen mode

Exit fullscreen mode

Child Module

Example:

modules/ec2/

Enter fullscreen mode

Exit fullscreen mode

📌 Every Terraform configuration has exactly one root module
📌 All other modules are child modules

PART 8: Standard Terraform Module Structure (Best Practice)

Minimal Recommended Structure

module-name/ ├── main.tf ├── variables.tf ├── outputs.tf └── README.md

Enter fullscreen mode

Exit fullscreen mode

Why This Structure Matters

PART 9: What Each File Does

main.tf

variables.tf

outputs.tf

README.md

PART 10: Designing Modules for Real Organizations

❌ Wrong approach

✅ Correct approach

Example:

Benefits:

PART 11: Multiple Provider Configurations with Modules

Default Behavior

PART 12: When You Need Multiple Providers

Example:

Both resources live inside the same module.

Default inheritance is not enough.

PART 13: Step 1 – Define Multiple Providers in Root Module

provider "aws" { region = "us-east-1" } provider "aws" { alias = "mumbai" region = "ap-south-1" }

Enter fullscreen mode

Exit fullscreen mode

PART 14: Step 2 – Pass Providers to Module

module "network" { source = "./modules/network" providers = { aws.prod = aws.mumbai } }

Enter fullscreen mode

Exit fullscreen mode

📌 Provider aliases are NOT inherited automatically

PART 15: Step 3 – Declare Configuration Aliases in Child Module

terraform { required_providers { aws = { source = "hashicorp/aws" configuration_aliases = [aws.prod] } } }

Enter fullscreen mode

Exit fullscreen mode

PART 16: Step 4 – Use Provider Meta-Argument in Resources

resource "aws_security_group" "prod" { provider = aws.prod }

Enter fullscreen mode

Exit fullscreen mode

Result:

PART 17: Critical Rules (MUST REMEMBER)

Provider Passing Rules

Providers vs Resource Provider

provider = aws.prod

Enter fullscreen mode

Exit fullscreen mode

providers = { aws.prod = aws.mumbai }

Enter fullscreen mode

Exit fullscreen mode

Module uses a map because:

PART 18: Interview & Exam One-Liners

What is a module output?

A module output exposes values from a child module so other modules or the root module can consume them.

What is a root module?

The root module is the main working directory where Terraform is executed.

Are provider aliases inherited by child modules?

No, provider aliases must be explicitly passed to child modules.

Why follow standard module structure?

It improves readability, reusability, and maintainability.

PART 1: Publishing a Module to Terraform Registry (Theory)

1. What Is Terraform Registry?

Terraform Registry is a central place to discover and share Terraform modules.

It provides:

2. Who Can Publish Modules?

Anyone can publish a public module to Terraform Registry.

Important notes:

3. High-Level Publishing Flow

  1. Create a public GitHub repository
  2. Follow naming conventions
  3. Follow standard module structure
  4. Add semantic version tags
  5. Sign in to Terraform Registry with GitHub
  6. Publish module

4. Mandatory Requirements for Publishing (EXAM IMPORTANT)

1. GitHub (Mandatory)

2. Repository Naming Convention (VERY IMPORTANT)

Format:

terraform-<PROVIDER>-<NAME>

Enter fullscreen mode

Exit fullscreen mode

Examples:

❌ Invalid:

3. Repository Description

4. Semantic Version Tags (X.Y.Z)

Terraform Registry uses Git tags for versions.

Valid examples:

❌ Invalid:

Registry reads tags, not branches.

5. Standard Module Structure (Mandatory)

Terraform strongly recommends a standard module layout.

5. Standard Module Structure (Best Practice)

Minimal Module Structure

. ├── README.md ├── main.tf ├── variables.tf └── outputs.tf

Enter fullscreen mode

Exit fullscreen mode

This is the minimum requirement for reusable modules.

Complete Module Structure

. ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf ├── versions.tf ├── modules/ │ └── nested-module/ ├── examples/ │ └── basic/

Enter fullscreen mode

Exit fullscreen mode

Used for:

6. Why Standard Structure Matters

7. Real-World Module Design (Important Best Practice)

❌ Bad approach

✅ Correct approach

Example:

This allows:

8. Exam Summary (Publishing Modules)

You must remember:

PART 2: Terraform Workspaces (Theory + Practical)

1. What Is a Terraform Workspace?

Terraform Workspace allows:

Think of it as:

Same code, different environments, separate states

2. Problem Without Workspaces

Without workspaces:

3. What Workspaces Solve

With workspaces:

Example:

4. Workspace Concept Diagram (Mental Model)

Same Terraform Code | Terraform Workspace | ------------------- | | | default dev prod state state state

Enter fullscreen mode

Exit fullscreen mode

5. Workspace Commands (EXAM IMPORTANT)

List workspaces

terraform workspace list

Enter fullscreen mode

Exit fullscreen mode

Show current workspace

terraform workspace show

Enter fullscreen mode

Exit fullscreen mode

Create workspace

terraform workspace new dev terraform workspace new prod

Enter fullscreen mode

Exit fullscreen mode

Switch workspace

terraform workspace select dev terraform workspace select prod

Enter fullscreen mode

Exit fullscreen mode

6. Workspace State Storage

Terraform creates:

terraform.tfstate.d/ ├── dev/ │ └── terraform.tfstate ├── prod/ │ └── terraform.tfstate

Enter fullscreen mode

Exit fullscreen mode

Default workspace:

7. Key Workspace Behavior (VERY IMPORTANT)

8. Workspace + Environment-Specific Configuration

Real Requirement

9. Using terraform.workspace with locals

Example Code

locals { instance_type = { default = "t2.nano" dev = "t2.micro" prod = "m5.large" } }

Enter fullscreen mode

Exit fullscreen mode

Use in Resource

resource "aws_instance" "example" { ami = "ami-123456" instance_type = local.instance_type[terraform.workspace] }

Enter fullscreen mode

Exit fullscreen mode

10. Result

Workspace

Instance Type

default

t2.nano

dev

t2.micro

prod

m5.large

Same code. Different environments.

11. Advantages of Workspaces

12. Important Limitations (Interview Point)

Workspaces are not recommended for:

In such cases:

13. Exam & Interview One-Liners

What is Terraform Workspace?

A Terraform feature that allows managing multiple state files for the same configuration.

Does each workspace have its own state file?

Yes, each workspace has a separate state file.

How do you access current workspace name?

terraform.workspace

Where are workspace state files stored?

In terraform.tfstate.d/<workspace>/

For further actions, you may consider blocking this person and/or reporting abuse

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Читайте також