Terraform Mülakat Soruları: Infrastructure as Code Kapsamlı Rehberi 2026

Terraform mülakat soruları, adayların bulut altyapısını deklaratif olarak yönetme, state dosyalarını güvenli şekilde kullanma ve yeniden kullanılabilir modüller tasarlama becerisini değerlendirir. Terraform 1.14'ün modül kaynaklarında değişken desteği sunması ve HCP Terraform'un yönetilen yürütme platformunu genişletmesiyle birlikte, 2026 yılında mülakatçılar adaylardan hem temel HCL bilgisini hem de gelişen IaC ekosisteminin farkındalığını göstermesini beklemektedir.

Her Adayın Bilmesi Gereken Temel Terraform Kavramları

Terraform nedir ve diğer IaC araçlarından farkı nedir?

Terraform, HCL (HashiCorp Configuration Language) ile yazılmış yapılandırma dosyaları aracılığıyla bulut kaynaklarını yöneten deklaratif bir Infrastructure as Code aracıdır. Ansible veya shell betikleri gibi imperatif araçların aksine, Terraform mevcut altyapıyı izleyen bir state dosyası tutar ve değişiklikleri uygulamadan önce bir fark ("plan") hesaplar.

Temel farklılıklar: Terraform bulut bağımsızdır (AWS, Azure, GCP ve yüzlerce provider'ı destekler), sürprizleri önleyen plan-sonra-apply iş akışı kullanır ve dahili yönlendirilmiş döngüsüz graf (DAG) aracılığıyla kaynak bağımlılıklarını yönetir.

Güçlü bir cevap ayrıca ekosistem değişimini de kabul eder: HashiCorp'un 2023'te BSL lisansını benimsemesinden bu yana, OpenTofu Linux Foundation altında açık kaynaklı bir fork olarak ortaya çıkmıştır. Her iki araç da aynı HCL sözdizimini paylaşır ancak özelliklerde ayrışmaktadır. Terraform 1.14 HCP ile platform entegrasyonuna odaklanırken, OpenTofu 1.9 state şifreleme ve dinamik backend'lere öncelik vermektedir.

Terraform iş akışını açıklayın: init, plan, apply, destroy

Dört temel komut, her Terraform operasyonunun yaşam döngüsünü oluşturur:

# 1. Başlatma - provider'ları ve modülleri indirir
terraform init

# 2. Plan - hiçbir şeyi değiştirmeden nelerin değişeceğini gösterir
terraform plan -out=tfplan

# 3. Apply - planlanan değişiklikleri uygular
terraform apply tfplan

# 4. Destroy - tüm yönetilen kaynakları kaldırır
terraform destroy

terraform init provider eklentilerini indirir ve backend'i başlatır. terraform plan istenen durumu (yapılandırma dosyaları) gerçek durumla (state dosyası) karşılaştırır ve bir değişiklik seti oluşturur. terraform apply bu değişiklik setini yürütür. Planın -out ile dosyaya kaydedilmesi, incelenen planın birebir uygulanmasını garanti eder; bu CI/CD pipeline'larında hayati önem taşır.

State Yönetimi: En Yaygın Mülakat Konusu

Terraform state nedir ve neden önemlidir?

Terraform state, yapılandırma kaynaklarını gerçek dünya altyapı nesneleriyle eşleştiren bir JSON dosyasıdır (terraform.tfstate). State olmadan Terraform neyin var olduğunu, neyin değiştiğini veya neyin silinmesi gerektiğini belirleyemez.

State dosyası kaynak kimliklerini, öznitelik değerlerini ve bağımlılık meta verilerini içerir. State'in kaybedilmesi, Terraform'un tüm yönetilen kaynakların kontrolünü kaybetmesi anlamına gelir; bu da her nesnenin manuel olarak import edilmesini veya daha kötüsü, maliyet oluşturmaya devam eden sahipsiz bulut kaynaklarını gerektirir.

Ekipler üretim ortamında state'i nasıl yönetmelidir?

Yerel state dosyaları ekip ortamları için kabul edilemez. Standart üretim yapılandırması, kilitleme mekanizmalı uzak bir backend kullanır:

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

Bu yapılandırma state'i sunucu tarafı şifreleme ile S3'te depolar ve state kilitleme için DynamoDB kullanır. Kilit, iki mühendisin (veya iki CI pipeline'ının) aynı anda apply çalıştırmasını engeller; bu durum state'i bozar.

HCP Terraform (eski adıyla Terraform Cloud), state depolama, kilitleme, çalıştırma geçmişi ve RBAC'yi ek altyapı gerektirmeden yöneten bir alternatif sunar. HashiCorp ekosistemine zaten yatırım yapmış organizasyonlar için S3 bucket'ları ve DynamoDB tabloları yönetme yükünü ortadan kaldırır.

State dosyası en iyi uygulamaları

• terraform.tfstate dosyasını asla sürüm kontrolüne eklememek gerekir. Düz metin olarak gizli bilgiler (veritabanı şifreleri, API anahtarları) içerebilir.
• Backend'de at-rest şifrelemenin etkinleştirilmesi gerekir (S3 SSE, GCS şifreleme veya Azure Storage şifreleme).
• Her ortam için ayrı state dosyaları kullanılmalıdır. Dev, staging ve üretim için tek bir state dosyası, kazara yıkım reçetesidir.
• State kilitlemenin uygulanması gerekir. Bunu destekleyen her uzak backend'de kilitleme etkin olmalıdır.
• State'i değiştirmeden incelemek için terraform state list ve terraform state show kullanılmalıdır.

Modüller: Yeniden Kullanılabilir Altyapı Bileşenleri

Terraform modülleri nasıl çalışır?

Bir modül, bir kaynak kümesini kapsülleyen .tf dosyaları içeren bir dizindir. Her Terraform yapılandırması teknik olarak bir modüldür (kök modül). Alt modüller, yeniden kullanımı teşvik etmek ve standartları uygulamak için kök modülden çağrılır.

# main.tf - modül çağırma
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
}

Terraform 1.14 önemli bir iyileştirme getirmiştir: değişkenler ve yerel değerler artık modül source ve version özniteliklerinde kullanılabilir. Bu, daha önce dinamik modül kaynağı belirleme için Terragrunt gibi geçici çözümler gerektiren sert bir kısıtlamaydı.

İyi tasarlanmış bir modülü ne tanımlar?

Üretim düzeyinde bir modül şu ilkelere uyar:

• Net girdiler ve çıktılar: Her değişkenin açıklaması, tip kısıtlaması ve uygun olduğunda mantıklı varsayılan değeri bulunur. Çıktılar, downstream modüllerin ihtiyaç duyduğu değerleri sunar.
• Minimal kapsam: Bir modül tek bir mantıksal bileşeni (bir VPC, bir veritabanı kümesi, bir Kubernetes namespace'i) yönetir, tüm ortamı değil.
• Sabit kodlanmış değer yok: Provider yapılandırması, bölge, hesap kimlikleri ve ortama özgü değerler değişkenlerden gelir, asla modül içindeki sabit değerlerden değil.
• Sürümlenmiş yayınlar: Yayınlanan modüller semantik sürümleme kullanır. version = "5.16.0" sabitleme, beklenmeyen kırıcı değişiklikleri önler.

Workspace'ler, Ortamlar ve Proje Yapısı

Birden fazla ortam nasıl yönetilmelidir?

Her biri farklı ödünleşimlere sahip üç yaygın kalıp mevcuttur:

| Kalıp | Mekanizma | En uygun | Risk | |-------|-----------|----------|------| | Workspace'ler | terraform workspace select prod | Basit projeler, ortam başına aynı yapılandırma | Paylaşımlı state backend'i, yanlış workspace'te apply çalıştırma kolaylığı | | Ortam-başına-dizin | Ayrı dev/, staging/, prod/ dizinleri | Ortamlar arası tam izolasyon | Dizinler arası kod tekrarı | | Terragrunt | Backend yapılandırmalarını üreten DRY sarmalayıcı | Büyük çoklu hesap kurulumları | Ek araç bağımlılığı |

Paylaşımlı modüllerle ortam-başına-dizin yaklaşımı üretimde en yaygın kullanılandır. Her ortam dizini, aynı modülleri farklı değişken değerleriyle çağıran bir main.tf içerir ve her birinin kendi izole state dosyası vardır.

terraform workspace ile dizin izolasyonu arasındaki fark nedir?

Workspace'ler aynı backend içinde adlandırılmış state dosyaları oluşturur. terraform workspace select staging ile workspace değiştirmek, Terraform'un hangi state dosyasını okuduğunu ve yazdığını değiştirir ancak yapılandırma aynı kalır.

Kısıtlama: workspace'ler aynı backend yapılandırmasını ve provider ayarlarını paylaşır. Dizin izolasyonu daha güçlü sınırlar sağlar — her ortam farklı bir AWS hesabı, farklı bir state backend'i hatta farklı provider sürümleri kullanabilir. Sıkı patlama yarıçapı kontrolü gerektiren düzenlemeye tabi ortamlarda dizin izolasyonu daha güvenli tercihtir.

Provider'lar, Veri Kaynakları ve Kaynak Yaşam Döngüsü

Provider'lar nedir ve nasıl yapılandırılır?

Provider'lar, HCL yapılandırmasını belirli platformlara yönelik API çağrılarına çeviren eklentilerdir. AWS provider'ı AWS API'sini çağırır, Kubernetes provider'ı Kubernetes API sunucusuyla iletişim kurar ve benzeri.

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

~> 5.80 sürüm kısıtlaması yama güncellemelerine (5.80.x) izin verirken minor sürüm atlamalarını engeller; stabilite ile güvenlik yamaları arasında denge kurar. default_tags bloğu, provider'ın oluşturduğu her kaynağa tutarlı etiketleme uygular — yönetişim ve maliyet tahsisi konusunda sık sorulan bir mülakat konusudur.

Veri kaynakları ile kaynaklar arasındaki farkı açıklayın

Kaynaklar (resource blokları) altyapıyı oluşturur, günceller ve siler. Veri kaynakları (data blokları) mevcut altyapıyı yönetmeden okur.

# Veri kaynağı - mevcut bir AMI'yi okur, hiçbir şey oluşturmaz
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-*"]
  }
}

# Kaynak - veri kaynağını kullanarak bir EC2 örneği oluşturur
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Veri kaynakları plan sırasında değerlendirilir; bu onları paylaşılan altyapıya referans vermek (başka bir ekip tarafından oluşturulan VPC'ler), dinamik değerleri aramak (en son AMI kimlikleri) veya harici yapılandırmayı okumak (SSM parametreleri, Vault secret'ları) için kullanışlı kılar.

İleri Düzey Konular: Import, Moved Blokları ve Test

terraform import nasıl çalışır ve ne zaman gereklidir?

terraform import, mevcut bir bulut kaynağını bir Terraform kaynak bloğuyla ilişkilendirir. Tipik senaryo: altyapı manuel olarak (ClickOps) veya başka bir araçla oluşturulmuştur ve ekip artık Terraform ile yönetmek istemektedir.

Terraform 1.5+ yalnızca CLI tabanlı iş akışının yerini alan import bloklarını doğrudan yapılandırmada sunmuştur:

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

Bu blokla terraform plan çalıştırmak, mevcut bucket'ı state'e alan bir plan üretir. Bu deklaratif import yaklaşımı pull request'lerde incelenebilir, tekrarlanabilir ve state'e doğrudan CLI erişimi gerektirmez.

moved blokları nedir?

Terraform kodunu yeniden düzenlemek (kaynak yeniden adlandırma, modüllere taşıma) tarihsel olarak terraform state mv komutları gerektirirdi. moved bloğu bunu deklaratif olarak yönetir:

# "web" kaynağı "app" olarak yeniden adlandırıldı
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform taşımayı plan sırasında tanır ve state'i otomatik olarak günceller; yok et-ve-yeniden-oluştur döngüsünden kaçınır. Bu, büyük yapılandırmaları modüllere yeniden yapılandırırken paha biçilmezdir.

Terraform'da test nasıl çalışır?

Terraform 1.6+, .tftest.hcl dosyalarını kullanan yerleşik bir test çerçevesi içerir:

# 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 bloğu beklenen değerle eşleşmiyor"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "3 özel alt ağ bekleniyordu"
  }
}

Terraform 1.14, fonksiyon kabul eden mock blokları, başarısız testlerin hata ayıklaması için skip_cleanup ve izole test state'i için run blokları içinde backend blokları ile bu özelliği genişletmiştir. Yerleşik test, temel doğrulama için Terratest gibi harici araçlara olan ihtiyacı ortadan kaldırır.

CI/CD Pipeline'larında Terraform

Üretim düzeyinde bir Terraform pipeline'ı nasıl görünür?

Sağlam bir Terraform CI/CD pipeline'ı her aşamada güvenliği zorunlu kılar:

1. Lint ve doğrulama: terraform fmt -check ve terraform validate sözdizimi sorunlarını yakalar.
2. PR'da plan: Her pull request terraform plan çalıştırır ve çıktıyı PR yorumu olarak yayınlar. İncelenmemiş plan olmadan apply yapılmaz.
3. Politika kontrolleri: OPA (Open Policy Agent), Sentinel (HCP Terraform) veya Checkov gibi araçlar planı organizasyon politikalarına göre doğrular (genel S3 bucket yok, zorunlu şifreleme, gerekli etiketler).
4. Merge'de apply: PR onayı ve politika kontrolleri geçtikten sonra, terraform apply kaydedilmiş plan dosyasından otomatik olarak çalışır.
5. State yedekleme: Apply sonrası pipeline state bütünlüğünü doğrular ve backend'in sürümlemesi yeni state versiyonunu kaydeder.

Altın kural: hiçbir kişi yerel bir makineden üretim ortamına terraform apply çalıştırmamalıdır. Tüm üretim apply işlemleri pipeline üzerinden gerçekleşir.

Sonuç

Terraform mülakat hazırlığı için temel çıkarımlar:

• State yönetimi en önemli konudur. Mülakata girmeden önce uzak backend'ler, kilitleme, şifreleme ve felaket kurtarma stratejilerinin anlaşılması gerekir.
• Modül tasarımı junior'ları senior'lardan ayırır. Yeniden kullanılabilir, sürümlenmiş, net arayüzlere ve minimal kapsama sahip modüller oluşturma becerisi gösterilmelidir.
• Plan/apply iş akışının derinlemesine anlaşılması şarttır. Planların dosyalara kaydedilmesinin neden önemli olduğu, DAG'ın yürütme sırasını nasıl belirlediği ve -target'ın ne yaptığı (ve neden dikkatli kullanılması gerektiği) açıklanabilmelidir.
• Terraform 1.14 modül kaynaklarında değişkenler, genişletilmiş test ve daha sıkı HCP entegrasyonu getirmektedir. Güncel özelliklerin bilinmesi ekosistemle aktif etkileşimi gösterir.
• Terraform vs OpenTofu durumunun dürüstçe ele alınması önemlidir. Lisans bölünmesini, özellik farklılıklarını ve her aracın ne zaman uygun olduğunu anlamak, sözdizimi bilgisinin ötesinde mimari olgunluğu gösterir.
• DevOps mülakat temellerinin Terraform konularıyla birlikte gözden geçirilmesi faydalıdır; mülakatçılar genellikle IaC sorularını daha geniş altyapı konularıyla birleştirir.
• Kubernetes dağıtım kavramlarının incelenmesi tavsiye edilir; Terraform sıklıkla Kubernetes iş yüklerinin çalıştığı kümeleri oluşturur.