APURV
  • Home
  • Journey
  • Projects
  • Blogs
  • Interview
  • Exams
Resume
APURV

Building scalable, secure, and production-ready cloud infrastructure. Automation first.

NAVIGATION

HomeExperienceProjectsCertificationsSkills

TECH STACK

AWSGCPK8sCI/CDLinuxDocker

CONNECT

LinkedInGitHubEmailResume

© 2026 Apurv Gujjar. All rights reserved.
APURV
  • Home
  • Journey
  • Projects
  • Blogs
  • Interview
  • Exams
Resume
HomeInterview PortalTerraform
IaC • State • Modules
ALL HANDBOOKS
🎯Linux🐙Git & GitHub🤖GitHub Actions🌐Networking☁AWS🛠Terraform🐳Docker☸Kubernetes🔄GitOps📊Monitoring🛡DevSecOps⚙SRE🏗System Design💰Cost Optimization🚨Incident Scenarios👤HR & Behavioral☁GCP🐍Python☁AWS Architect
🛠

Terraform

// INTERVIEW & ARCHITECTURE HANDBOOK
IaC • State • Modules

Learn Terraform core architecture, production scenario-based questions, incident response, and real-world engineering solutions.

🛠️ Terraform IaC Advanced: Interactive Q&A Handbook#



🟢 Part 1: Core IaC Concepts & Workflows#

❓ Q1: What is Infrastructure as Code (IaC), and what actual problems does it solve for an operations team?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer: Infrastructure as Code (IaC) is the practice of provisioning, managing, and configuring IT infrastructure (servers, network topologies, storage, load balancers) using machine-readable configuration files or scripts ("code"), rather than relying on manual server configuration, physical hardware setups, or interactive GUI dashboard configurations.

Key Benefits:#

  • Version Control: Configuration files are stored in Git, tracking revisions, pull requests, and audit logs.
  • Automation: Environments can be spun up or destroyed consistently with a single command.
  • Consistency: Prevents "configuration drift" across development, staging, and production environments.
  • Speed: Drastically reduces the time required to provision infrastructure from days to minutes.

❓ Q2: How do you choose between a provisioning tool like Terraform and a configuration management tool like Ansible?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  • Provisioning & Orchestration (Terraform, CloudFormation):
    • Focus: Building and managing infrastructure architecture (VPCs, Subnets, Databases, IAM Roles).
    • Paradigm: Declarative. You define the desired end state, and the tool determines the API calls needed to achieve it.
  • Configuration Management (Ansible, Chef, Puppet):
    • Focus: Installing software, patching systems, and managing files/configurations on already provisioned virtual machines.
    • Paradigm: Often hybrid (procedural/declarative). Installs packages and adjusts software parameters on active compute instances.

❓ Q3: Walk me through the standard Terraform core workflow. What happens under the hood during each phase?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer: The standard Terraform core workflow consists of three primary phases:

  1. Write (terraform init & Coding): Author HCL configuration files defining the desired infrastructure. Run terraform init to download the required provider plugins (e.g., AWS, Azure) and initialize the backend.
  2. Plan (terraform plan): Compare the configuration against the real-world infrastructure and state file. Generate an execution plan showing what actions (create, update, destroy) will be performed.
  3. Apply (terraform apply): Execute the actions proposed in the plan. Terraform calls the provider APIs to provision the resources and updates the local or remote state file (terraform.tfstate).

🟡 Part 2: Advanced HCL Syntax & Logic#

❓ Q4: What is the difference between count and for_each? In what scenarios is for_each the safer choice?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  • count:
    • Iterates based on an integer count (e.g., count = 3).
    • Identifies resources by index in a list (aws_subnet.subnets[0]).
    • Risk: If you delete an item from the middle of the list, Terraform will destroy and shift all subsequent resources because their indexes shift. Use count only for identical, simple resources.
  • for_each:
    • Iterates based on a map or set of strings.
    • Identifies resources by a unique key (aws_subnet.subnets["public-1"]).
    • Safety: Removing an item from the map only destroys that specific resource without affecting others. Use for_each for complex configurations and variable maps.

❓ Q5: How do dynamic blocks work in Terraform, and can you give me an example of when they are necessary?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer: Dynamic Blocks allow you to generate repeated nested blocks within a resource or data source dynamically based on a variable list or map (e.g., dynamically creating multiple ingress ports in a security group):

resource "aws_security_group" "sg" {
  name = "dynamic-ports"
  dynamic "ingress" {
    for_each = var.ports
    content {
      from_port   = ingress.value
      to_port     = ingress.value
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

❓ Q6: How do you distinguish between input variables and local values? When should we use locals?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  • Variables (variable): Act as function arguments. They allow users to pass custom input parameters into your modules to customize execution (e.g., changing AMI IDs or environment tags).
  • Locals (locals): Act as local variables within a program. They are internal to the configuration, cannot be overridden externally, and are used to store intermediate calculations or avoid hardcoding repeated expressions.

❓ Q7: Can you explain the difference between a resource block and a data source block?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  • Resources (resource): Infrastructure components that Terraform creates, manages, updates, and destroys (e.g., creating a new EC2 instance).
  • Data Sources (data): Read-only queries used to fetch information from external APIs or pre-existing cloud resources (e.g., retrieving the latest AMI ID or querying an existing VPC ID).

🔵 Part 3: State Management & Recovery#

❓ Q8: What is the purpose of the Terraform state file, and what strategies do you implement to secure it in production?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer: The state file (terraform.tfstate) is Terraform's database mapping your HCL configurations to actual physical resources deployed in the cloud. It tracks metadata, dependencies, and resources.

Production Security Hardening:#

  1. Remote State Storage: Never commit terraform.tfstate to Git. Store it in a remote backend like Amazon S3 or Google Cloud Storage.
  2. Encryption: Enable default Server-Side Encryption (SSE) on the S3 bucket.
  3. State Locking: Use DynamoDB (for AWS S3 backend) or native Cloud Storage locks to prevent multiple administrators from running migrations simultaneously (preventing state file corruption).
  4. Access Isolation: Lock down S3 bucket IAM permissions. The state file can contain sensitive plaintext secrets (like database passwords or API keys).

❓ Q9: If our remote state file gets corrupted or accidentally deleted, how would you recover it?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  1. S3 Versioning Recovery: If utilizing an S3 remote backend, retrieve the previous version of the state file from bucket history.
  2. State Import: If the state is completely lost, write the matching HCL code for your cloud resources and rebuild the state file dynamically using terraform import commands.
  3. Local Backup: If you ran local updates, check for auto-generated terraform.tfstate.backup files.

❓ Q10: If our Terraform codebase grows into a monolithic state file, how would you split it into modular configurations?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer: A monolithic state file increases deployment risk and planning times. To split it:

  1. Write separate Terraform configurations for each layer (e.g., networking, database, app).
  2. Use terraform state mv to move resources from the old monolithic state to the new layer-specific state files.
  3. Deploy a Terraform Remote State data source (terraform_remote_state) in the application layer to fetch outputs (e.g., VPC IDs) from the networking state.

❓ Q11: How do you safely migrate a Terraform state file from a local backend to a remote backend?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  1. Update the backend block in your HCL code to point to the new backend configuration (e.g., switching from local to S3).
  2. Run terraform init.
  3. Terraform will detect the backend change and prompt: "Do you want to copy existing state to the new backend?".
  4. Type yes to upload the state database to the new remote storage automatically.

🏢 Part 4: Enterprise Terraform & GitOps#

❓ Q12: How do tools like Terragrunt, Terraform Cloud, and Atlantis help scale Terraform in an enterprise?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  • Terragrunt: A thin wrapper that provides extra tools for keeping your configurations DRY (Don't Repeat Yourself), managing remote state configurations, and executing Terraform commands across multiple directories simultaneously.
  • Terraform Cloud: A managed SaaS platform by HashiCorp that runs Terraform executions in a controlled remote environment, hosting state files, secrets, policy-as-code gates (Sentinel), and private registries.
  • Atlantis: An open-source application that runs Terraform commands directly inside your Git Pull Requests. When a developer submits a PR, Atlantis runs terraform plan and comments the output on the PR; once reviewed, the developer merges the PR by commenting atlantis apply.

❓ Q13: What is your approach to implementing a GitOps model for infrastructure delivery using Terraform?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  1. Store all Terraform HCL code in version-controlled repositories.
  2. Set up a GitOps controller (like Flux TF-Controller or Terraform Cloud) that polls the Git repository.
  3. When a commit is merged to main, the controller automatically runs terraform apply in a secure runner, keeping the cloud environment synced with Git without manual shell intervention.

❓ Q14: How does Terraform compare to AWS CloudFormation, and why might you prefer one over the other?#

Click on the dropdown below to reveal the technical answer.

💡 Reveal Technical Answer

Answer:

  • Terraform:
    • Scope: Multi-Cloud. Supports AWS, GCP, Azure, Kubernetes, and SaaS providers via providers.
    • Language: HashiCorp Configuration Language (HCL).
    • State: Managed explicitly by the user (locally or in remote backends).
  • AWS CloudFormation:
    • Scope: AWS Only. Deep, native integration with AWS services.
    • Language: JSON or YAML templates.
    • State: Managed automatically behind the scenes by AWS engine (free of charge).

AWSBack to PortalDocker
On This Page
Part 1: Core IaC Concepts & WorkflowsPart 2: Advanced HCL Syntax & LogicPart 3: State Management & RecoveryPart 4: Enterprise Terraform & GitOps
APURV

Building scalable, secure, and production-ready cloud infrastructure. Automation first.

NAVIGATION

HomeExperienceProjectsCertificationsSkills

TECH STACK

AWSGCPK8sCI/CDLinuxDocker

CONNECT

LinkedInGitHubEmailResume

© 2026 Apurv Gujjar. All rights reserved.