Terraform Interview Questions: Hướng dẫn toàn diện về Infrastructure as Code

Trong lĩnh vực quản lý hạ tầng đám mây hiện đại, Terraform đã trở thành công cụ Infrastructure as Code (IaC) được sử dụng rộng rãi nhất. Các nhà tuyển dụng ngày càng yêu cầu ứng viên DevOps và Platform Engineering phải thành thạo Terraform để xây dựng và quản lý hạ tầng một cách có hệ thống. Bài viết này tổng hợp những câu hỏi phỏng vấn Terraform thường gặp nhất trong năm 2026, từ các khái niệm cơ bản đến những chủ đề nâng cao.

Các Khái Niệm Cốt Lõi của Terraform

Terraform là gì và tại sao nó quan trọng?

Terraform là một công cụ mã nguồn mở được phát triển bởi HashiCorp, cho phép định nghĩa và cung cấp hạ tầng đám mây thông qua các file cấu hình sử dụng ngôn ngữ HashiCorp Configuration Language (HCL). Điểm mạnh của Terraform nằm ở khả năng làm việc với nhiều nhà cung cấp dịch vụ đám mây khác nhau như AWS, Azure, Google Cloud Platform và hàng trăm provider khác.

Terraform sử dụng phương pháp tiếp cận khai báo (declarative approach), nghĩa là người dùng mô tả trạng thái mong muốn của hạ tầng và Terraform sẽ tự động xác định các bước cần thiết để đạt được trạng thái đó. Điều này khác biệt hoàn toàn so với phương pháp mệnh lệnh (imperative approach) truyền thống.

Quy trình làm việc cơ bản với Terraform

Terraform hoạt động theo một quy trình ba bước rõ ràng: Write (viết cấu hình), Plan (lập kế hoạch thay đổi), và Apply (áp dụng thay đổi). Dưới đây là các lệnh cơ bản mà mọi kỹ sư DevOps cần nắm vững:

# 1. Initialize - downloads providers and modules
terraform init

# 2. Plan - shows what will change without modifying anything
terraform plan -out=tfplan

# 3. Apply - executes the planned changes
terraform apply tfplan

# 4. Destroy - tears down all managed resources
terraform destroy

Lệnh terraform init khởi tạo working directory, tải về các provider và module cần thiết. Lệnh terraform plan tạo execution plan để xem trước những thay đổi sẽ được thực hiện. Lệnh terraform apply thực thi các thay đổi đã được lên kế hoạch.

Quản Lý State trong Terraform

State file là gì và tại sao nó quan trọng?

Terraform state file (terraform.tfstate) là một file JSON chứa thông tin mapping giữa cấu hình Terraform và các tài nguyên thực tế trên cloud. State file giúp Terraform theo dõi những gì đã được tạo, phát hiện sự khác biệt giữa cấu hình mong muốn và trạng thái hiện tại, đồng thời tối ưu hóa hiệu suất bằng cách cache các thuộc tính của tài nguyên.

Quản lý State trong môi trường Production

Trong môi trường sản xuất, việc lưu trữ state file locally là không khả thi vì nhiều người cần truy cập và làm việc với cùng một hạ tầng. Remote backend như S3 với DynamoDB locking là giải pháp tiêu chuẩn được khuyến nghị:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/networking/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Cấu hình trên sử dụng S3 bucket để lưu trữ state file với mã hóa, kết hợp với DynamoDB table để implement state locking, ngăn chặn nhiều người cùng thay đổi hạ tầng đồng thời.

Các best practices khi quản lý State

Một số nguyên tắc quan trọng cần tuân thủ bao gồm: luôn sử dụng remote backend cho môi trường team, bật encryption cho state file, sử dụng state locking để tránh race conditions, không bao giờ commit state file vào version control, và phân chia state theo môi trường hoặc component để giảm blast radius.

Modules trong Terraform

Modules hoạt động như thế nào?

Modules là containers chứa một nhóm các resources được sử dụng cùng nhau. Chúng cho phép tái sử dụng code, đóng gói logic phức tạp, và tạo abstraction layers cho các pattern hạ tầng phổ biến. Một module có thể gọi các modules khác, tạo nên cấu trúc phân cấp linh hoạt.

# main.tf - calling a module
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.16.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

Nguyên tắc thiết kế Module hiệu quả

Một module được thiết kế tốt cần tuân thủ các nguyên tắc sau: có tài liệu rõ ràng với README và examples, sử dụng semantic versioning để quản lý phiên bản, định nghĩa đầy đủ input variables với descriptions và validations, expose outputs cần thiết cho các modules khác sử dụng, và tránh hardcode các giá trị có thể thay đổi theo môi trường.

Workspaces, Environments và Cấu Trúc Dự Án

Các pattern phổ biến cho multi-environment

Có hai pattern chính để quản lý nhiều môi trường trong Terraform:

| Pattern | Ưu điểm | Nhược điểm | |---------|---------|------------| | Terraform Workspaces | Đơn giản, ít code duplication | Tất cả môi trường chia sẻ backend, khó áp dụng permissions khác nhau | | Directory-based | Hoàn toàn tách biệt, dễ quản lý permissions | Có thể dẫn đến code duplication nếu không dùng modules |

Workspace vs Directory Isolation

Workspaces phù hợp cho các môi trường có cấu hình tương tự nhau và team size nhỏ. Directory isolation được khuyến nghị cho production environments nơi cần kiểm soát chặt chẽ quyền truy cập và có quy trình CI/CD riêng biệt cho từng môi trường.

Cấu trúc thư mục được khuyến nghị cho dự án lớn:

• environments/ - chứa cấu hình cho từng môi trường (dev, staging, prod)
• modules/ - chứa các reusable modules nội bộ
• shared/ - chứa cấu hình dùng chung như provider configuration

Providers, Data Sources và Resource Lifecycle

Cấu hình Providers

Providers là plugins cho phép Terraform tương tác với các API của cloud providers, SaaS providers và các dịch vụ khác. Mỗi provider cần được khai báo và cấu hình:

# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
      Team        = var.team_name
    }
  }
}

Việc sử dụng default_tags giúp đảm bảo tất cả resources được tạo đều có các tags chuẩn, hỗ trợ cost allocation và governance.

Data Sources vs Resources

Data sources cho phép Terraform query thông tin về các tài nguyên đã tồn tại mà không quản lý chúng. Điều này khác với resources, vốn được Terraform tạo, cập nhật và xóa:

# Data source - reads an existing AMI, does not create anything
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }
}

# Resource - creates an EC2 instance using the data source
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Các Chủ Đề Nâng Cao

Import và Moved Blocks

Terraform 1.5 giới thiệu import blocks, cho phép import existing resources vào Terraform state một cách khai báo:

# import.tf
import {
  to = aws_s3_bucket.legacy_data
  id = "my-legacy-bucket-name"
}

resource "aws_s3_bucket" "legacy_data" {
  bucket = "my-legacy-bucket-name"
}

Moved blocks giúp refactor code mà không làm mất state tracking:

# Renamed a resource from "web" to "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Testing trong Terraform

Terraform 1.6 đã thêm native testing framework, cho phép viết integration tests cho modules:

# tests/vpc.tftest.hcl
run "creates_vpc_with_correct_cidr" {
  command = plan

  assert {
    condition     = aws_vpc.main.cidr_block == "10.0.0.0/16"
    error_message = "VPC CIDR block does not match expected value"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Expected 3 private subnets"
  }
}

Chạy tests với terraform test sẽ thực thi tất cả các file .tftest.hcl trong thư mục tests/.

Terraform trong CI/CD Pipelines

Việc tích hợp Terraform vào CI/CD pipeline đòi hỏi một số best practices quan trọng. Đầu tiên, luôn chạy terraform plan trong pipeline và yêu cầu manual approval trước khi apply cho production. Sử dụng separate service accounts với quyền hạn tối thiểu cần thiết cho mỗi môi trường.

Pipeline tiêu chuẩn bao gồm các bước: checkout code, setup Terraform, terraform init, terraform validate, terraform plan, và cuối cùng là terraform apply với approval gates phù hợp. Lưu plan output dưới dạng artifact để đảm bảo apply đúng những gì đã được review.

Sử dụng tools như Terragrunt hoặc Atlantis có thể đơn giản hóa việc quản lý Terraform workflows trong môi trường team lớn, cung cấp các tính năng như automatic plan comments trên pull requests và locking mechanism tích hợp.

Kết Luận

Terraform là một công cụ không thể thiếu trong bộ kỹ năng của mọi kỹ sư DevOps và Platform Engineering. Việc nắm vững các khái niệm từ cơ bản đến nâng cao sẽ giúp ứng viên tự tin trong các buổi phỏng vấn và áp dụng hiệu quả trong công việc thực tế.

Những điểm then chốt cần ghi nhớ bao gồm: hiểu rõ quy trình làm việc init-plan-apply, quản lý state một cách an toàn với remote backend, thiết kế modules có thể tái sử dụng, và tích hợp Terraform vào CI/CD pipeline với các approval gates phù hợp.

Để tiếp tục học hỏi và chuẩn bị cho phỏng vấn DevOps, hãy tham khảo thêm các bài viết về câu hỏi phỏng vấn DevOps cơ bản và triển khai ứng dụng đầu tiên trên Kubernetes.