Pertanyaan Wawancara Terraform: Panduan Lengkap Infrastructure as Code

Terraform telah menjadi standar industri dalam Infrastructure as Code (IaC), memungkinkan tim DevOps untuk mendefinisikan, menyediakan, dan mengelola infrastruktur cloud dengan kode yang dapat direproduksi. Bagi kandidat yang mempersiapkan wawancara teknis, pemahaman mendalam tentang konsep Terraform sangat penting untuk mendemonstrasikan keahlian dalam manajemen infrastruktur modern.

Artikel ini menyajikan pertanyaan wawancara Terraform yang komprehensif, mulai dari konsep dasar hingga topik lanjutan seperti manajemen state, modul, dan integrasi CI/CD. Setiap pertanyaan disertai penjelasan mendalam untuk membantu pemahaman fundamental yang solid.

Konsep Dasar Terraform

Apa Itu Terraform dan Mengapa Penting?

Terraform adalah tool Infrastructure as Code open-source yang dikembangkan oleh HashiCorp. Tool ini memungkinkan pengguna untuk mendefinisikan infrastruktur menggunakan bahasa konfigurasi deklaratif bernama HCL (HashiCorp Configuration Language). Berbeda dengan pendekatan imperatif, Terraform menggunakan pendekatan deklaratif di mana pengguna mendeskripsikan state akhir yang diinginkan, dan Terraform akan menentukan langkah-langkah yang diperlukan untuk mencapai state tersebut.

Keunggulan utama Terraform meliputi kemampuan multi-cloud yang memungkinkan pengelolaan berbagai provider cloud dengan sintaks yang konsisten, version control untuk infrastruktur yang memungkinkan tracking perubahan dan rollback, serta automation yang mengurangi human error dalam provisioning infrastruktur.

Workflow Dasar Terraform

Terraform memiliki empat perintah utama yang membentuk workflow standar pengelolaan infrastruktur:

# 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

Perintah terraform init menginisialisasi working directory dengan mengunduh provider dan modul yang diperlukan. Perintah terraform plan menampilkan preview perubahan tanpa memodifikasi apapun, memungkinkan review sebelum eksekusi. Perintah terraform apply mengeksekusi perubahan yang telah direncanakan, sedangkan terraform destroy menghapus semua resource yang dikelola Terraform.

Manajemen State

Memahami Terraform State

Terraform state adalah komponen kritis yang menyimpan mapping antara konfigurasi Terraform dengan resource aktual di cloud provider. State file berisi metadata tentang resource yang dikelola, dependency antar resource, dan output values.

State memungkinkan Terraform untuk menentukan perubahan yang diperlukan dengan membandingkan konfigurasi yang diinginkan dengan state saat ini. Tanpa state yang akurat, Terraform tidak dapat mengetahui resource mana yang sudah ada dan perlu dimodifikasi atau dihapus.

Manajemen State untuk Produksi

Untuk environment produksi, penyimpanan state lokal tidak direkomendasikan karena risiko kehilangan data dan konflik saat bekerja dalam tim. Remote backend seperti S3 dengan DynamoDB locking menyediakan solusi yang lebih robust:

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

Konfigurasi ini menyimpan state di S3 bucket dengan enkripsi, menggunakan DynamoDB table untuk state locking yang mencegah concurrent modifications, dan mengorganisir state berdasarkan environment dan komponen.

Best Practices Manajemen State

Beberapa praktik terbaik dalam manajemen state meliputi penggunaan remote backend untuk semua environment non-development, implementasi state locking untuk mencegah race conditions, pemisahan state berdasarkan environment dan komponen untuk membatasi blast radius, serta never editing state file secara manual kecuali dalam situasi darurat dengan perintah terraform state.

Modul Terraform

Cara Kerja Modul

Modul adalah container untuk multiple resources yang digunakan bersama. Modul memungkinkan reusability, encapsulation, dan standardisasi konfigurasi infrastruktur. Setiap konfigurasi Terraform sebenarnya adalah root module, dan dapat memanggil child modules.

# 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
}

Contoh di atas menunjukkan penggunaan modul VPC dari Terraform Registry. Module source dapat berupa path lokal, URL Git, Terraform Registry, atau S3 bucket. Version pinning sangat direkomendasikan untuk mencegah breaking changes.

Prinsip Modul yang Baik

Modul yang well-designed mengikuti beberapa prinsip utama. Pertama, single responsibility di mana setiap modul harus memiliki satu tujuan yang jelas. Kedua, input validation menggunakan variable validation blocks untuk memastikan input yang valid. Ketiga, comprehensive outputs yang meng-expose semua nilai yang mungkin diperlukan oleh calling module. Keempat, documentation yang jelas melalui descriptions untuk semua variables dan outputs.

Workspaces, Environments, dan Struktur Proyek

Terraform menyediakan beberapa pendekatan untuk mengelola multiple environments. Pemilihan pendekatan yang tepat bergantung pada kompleksitas proyek dan kebutuhan isolasi.

| Pendekatan | Kelebihan | Kekurangan | |------------|-----------|------------| | Workspaces | Konfigurasi tunggal, switching mudah | State sharing, tidak ada isolasi kode | | Directory per Environment | Isolasi penuh, dapat berbeda signifikan | Duplikasi kode, maintenance lebih tinggi | | Terragrunt | DRY, inheritance, hooks | Tambahan dependency, learning curve | | Variables per Environment | Simple, satu codebase | Perlu kondisional kompleks |

Workspace vs Directory Isolation

Terraform workspaces memungkinkan multiple state files dalam satu konfigurasi, berguna untuk environment yang identik. Namun, untuk environment dengan perbedaan signifikan, directory isolation dengan shared modules memberikan fleksibilitas lebih besar. Kombinasi keduanya sering digunakan di mana modules di-share melalui versioned registry sementara root configurations terpisah per environment.

Providers, Data Sources, dan Resource Lifecycle

Konfigurasi Provider

Provider adalah plugin yang memungkinkan Terraform berinteraksi dengan cloud platforms dan services. Konfigurasi provider yang baik mencakup version constraints, default tags, dan region settings:

# 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
    }
  }
}

Default tags memastikan semua resources mendapat tagging yang konsisten untuk cost allocation dan governance.

Data Sources vs Resources

Perbedaan fundamental antara data sources dan resources perlu dipahami dengan baik. Data sources membaca informasi dari infrastruktur yang sudah ada tanpa membuat atau memodifikasi apapun. Resources mendefinisikan infrastruktur yang akan dibuat dan dikelola oleh Terraform.

# 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"
}

Data source dalam contoh ini mencari AMI Ubuntu terbaru, kemudian resource menggunakan ID AMI tersebut untuk membuat EC2 instance.

Topik Lanjutan

Import Resources yang Sudah Ada

Terraform import memungkinkan adopsi resources yang dibuat secara manual atau oleh tool lain. Terraform 1.5+ memperkenalkan import blocks yang lebih declarative:

# 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"
}

Import block mendefinisikan mapping antara resource Terraform dengan resource ID di cloud provider. Setelah import, Terraform akan mengelola resource tersebut sepenuhnya.

Moved Blocks untuk Refactoring

Moved blocks memfasilitasi refactoring konfigurasi tanpa menghapus dan membuat ulang resources:

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

Fitur ini sangat berguna saat reorganisasi kode atau mengganti nama resources tanpa downtime.

Testing dengan Terraform Test

Terraform 1.6+ memperkenalkan native testing framework yang memungkinkan validasi konfigurasi:

# 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"
  }
}

Testing framework ini memungkinkan validasi bahwa konfigurasi akan menghasilkan infrastruktur sesuai ekspektasi sebelum deployment aktual.

Terraform dalam Pipeline CI/CD

Integrasi Terraform dengan CI/CD pipelines adalah praktik standar dalam organisasi modern. Pipeline yang efektif biasanya mencakup beberapa tahapan kunci.

Tahap pertama adalah validation yang menjalankan terraform fmt -check dan terraform validate untuk memastikan kode memenuhi standar formatting dan sintaks valid. Tahap kedua adalah security scanning menggunakan tools seperti tfsec atau checkov untuk mendeteksi misconfiguration keamanan.

Tahap ketiga adalah plan generation yang menghasilkan plan file dan menyimpannya sebagai artifact. Plan ini kemudian ditampilkan sebagai comment di pull request untuk review. Tahap keempat adalah approval gate di mana tim melakukan review perubahan sebelum approval untuk apply.

Tahap kelima adalah apply yang mengeksekusi plan yang sudah di-approve, biasanya hanya dari branch utama. Tahap terakhir adalah post-deployment verification yang memvalidasi bahwa infrastruktur berfungsi sesuai ekspektasi.

Kesimpulan

Penguasaan Terraform memerlukan pemahaman yang solid tentang konsep deklaratif, manajemen state yang aman, desain modul yang reusable, dan integrasi dengan workflow DevOps modern. Pertanyaan wawancara Terraform sering berfokus pada kemampuan kandidat untuk menjelaskan trade-offs dan best practices berdasarkan pengalaman praktis.

Beberapa poin kunci yang perlu dikuasai meliputi workflow deklaratif Terraform dengan perintah init, plan, apply, dan destroy. Manajemen state dengan remote backend dan locking mechanism sangat penting untuk tim yang bekerja secara kolaboratif. Desain modul yang mengikuti prinsip single responsibility dan proper encapsulation memungkinkan reusability dan maintainability. Integrasi CI/CD dengan proper gates dan security scanning memastikan deployment yang aman dan terkontrol.

Untuk memperdalam persiapan wawancara DevOps, disarankan untuk mempelajari juga pertanyaan wawancara DevOps esensial dan memahami deployment aplikasi pertama di Kubernetes sebagai komplemen pengetahuan Infrastructure as Code.