Terraform Nedir? Sıfırdan Öğrenme Rehberi ve İlk Projen

Terraform nedir? Kısa cevap: Terraform, bulut altyapını (sunucular, ağlar, veritabanları, DNS kayıtları, hatta SaaS ayarları) yazdığın kodla tanımlamanı ve tek komutla oluşturmanı sağlayan açık kaynaklı bir altyapı otomasyon aracıdır. HashiCorp tarafından geliştirilen Terraform, "tıkla, ayarla, unut" tarzı manuel konsol işlemlerinin yerini alır; altyapının bir Git deposunda, versiyonlanabilir ve tekrarlanabilir bir biçimde durur. Bu rehberde Terraform'un ne olduğunu, nasıl çalıştığını ve sıfırdan ilk projeni nasıl ayağa kaldıracağını adım adım göreceksin. Sonunda terraform init, plan, apply ve destroy komutlarını gerçek bir örnek üzerinde çalıştırabilecek, değişken ve çıktı tanımlayabilecek ve neden binlerce şirketin altyapısını bu şekilde yönettiğini anlayacaksın.

Terraform'u tek başına anlamak zor; çünkü o, daha büyük bir fikrin en popüler uygulamasıdır. Bu fikir Infrastructure as Code (Kod olarak Altyapı) yani IaC'dir. Terraform'a girmeden önce bu kavramı oturtmak, gerisini çok daha kolay hale getirir.

Terraform'dan önce: Infrastructure as Code (IaC) nedir?

Geleneksel yöntemde bir sunucu, ağ ya da veritabanı oluşturmak için bulut sağlayıcının web konsoluna girer, formları elle doldurur ve "Oluştur" düğmesine basarsın. Bu yaklaşım küçük ölçekte işe yarar ama ekip büyüdükçe kırılır: kimin neyi neden değiştirdiği belli olmaz, aynı ortamı ikinci kez birebir kuramazsın ve prod ile test ortamları sessizce birbirinden ayrışır. Infrastructure as Code, tüm bu kaynakları metin dosyalarında tanımlamak demektir. Konu kavram olarak yeniyse önce Infrastructure as Code (IaC) nedir? yazısını okumanı öneririz; orada IaC'nin "neden"ini derinlemesine ele alıyoruz.

IaC'nin sağladığı üç somut kazanç şudur: altyapın versiyonlanır (her değişiklik Git geçmişinde durur), tekrarlanabilir olur (aynı kodu farklı hesaplarda birebir çalıştırırsın) ve gözden geçirilebilir hale gelir (bir Pull Request'te altyapı değişikliği tıpkı uygulama kodu gibi incelenebilir). Terraform, bu felsefeyi bulut sağlayıcıdan bağımsız, tek bir dille hayata geçiren araçtır.

Manuel yönetimin en sinsi problemi konfigürasyon kayması (configuration drift) denen olgudur: zamanla birileri konsoldan küçük ayarlar değiştirir, kimse not almaz ve ortamlar sessizce birbirinden uzaklaşır. Bir gün prod'da çalışan bir şey test'te çalışmaz ve kimse nedenini bilmez. IaC ile altyapının "tek doğru kaynağı" (single source of truth) koddur; koda bakarak sistemin nasıl olması gerektiğini kesin olarak bilir, kaymayı plan ile tespit edebilirsin. Terraform öğrenmenin asıl kazancı, işte bu öngörülebilirliği ekibine kazandırmaktır.

Terraform nedir ve neden bu kadar popüler?

Terraform, altyapını bildirimsel (declarative) bir dilde tanımlamanı sağlar. Bildirimsel olması şu demek: adım adım "şunu yap, sonra bunu yap" diye komut yazmazsın; bunun yerine sistemin son halini tarif edersin: "3 sunucum, 1 yük dengeleyicim ve 1 veritabanım olsun." Terraform mevcut durumla senin istediğin durumu karşılaştırır ve aradaki farkı kapatmak için gerekli API çağrılarını kendisi hesaplar. Bu, imperative (emir kipi) betiklerin en büyük derdi olan "ikinci kez çalıştırınca ne olacak?" sorusunu ortadan kaldırır.

Terraform'u öne çıkaran özellikler

• Sağlayıcı bağımsızlığı: Tek bir HCL diliyle AWS, Azure, GCP, Kubernetes, Cloudflare ve 4000'den fazla provider'ı yönetirsin.
• Plan/apply döngüsü: Değişikliği uygulamadan önce Terraform sana tam olarak ne ekleyeceğini, değiştireceğini ve sileceğini gösterir. Sürprizsiz altyapı.
• State (durum) takibi: Terraform gerçek dünyadaki kaynakların bir haritasını tutar; böylece neyi yönettiğini bilir. Bu konu o kadar kritik ki ayrı bir başlıkta ele alacağız.
• Bağımlılık grafiği: Kaynaklar arası bağımlılıkları otomatik çözer; VPC olmadan subnet oluşturmaya kalkmaz, doğru sırayı kendi bulur.
• Modülerlik: Tekrar eden altyapı desenlerini modüllere sarıp yeniden kullanırsın; kopyala-yapıştır azalır.

Terraform nasıl çalışır? HCL, provider, plan ve apply

Terraform'un iş akışı üç temel kavram üzerine kuruludur: altyapıyı tanımladığın HCL dili, bulut API'leriyle konuşan provider'lar ve değişiklikleri güvenle uygulayan plan/apply döngüsü. Bunları sırayla açalım.

HCL — HashiCorp Configuration Language

Terraform dosyaları .tf uzantısıyla yazılır ve HCL adı verilen, okuması kolay bir dil kullanır. HCL'de üç ana yapı taşı vardır: provider (hangi buluta bağlanacağını söyler), resource (oluşturulacak somut altyapı parçası) ve variable/output (giriş ve çıkışlar). Aşağıda bir provider ve basit bir resource tanımı görüyorsun:

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

provider "aws" {
  region = "eu-central-1"
}

resource "aws_s3_bucket" "veri" {
  bucket = "cloudpuz-terraform-demo-2026"

  tags = {
    Ortam  = "ogrenme"
    Proje  = "terraform-baslangic"
  }
}

Bu bloklarda resource "aws_s3_bucket" "veri" ifadesindeki aws_s3_bucket kaynağın tipini, veri ise Terraform içinde ona verdiğin yerel adı belirtir. Bu yerel adla kaynağa başka yerlerden aws_s3_bucket.veri.id şeklinde referans verebilirsin. bucket gibi alanlar ise o kaynağın gerçek özellikleridir.

Provider — bulutla konuşan eklenti

Provider, Terraform'un ilgili servisin API'siyle konuşmasını sağlayan eklentidir. terraform init çalıştırdığında Terraform, required_providers bloğunda belirttiğin provider'ları Terraform Registry'den indirir. Her provider kendi kaynak tiplerini (aws_instance, google_compute_instance, cloudflare_record...) sunar. Aynı konfigürasyonda birden fazla provider kullanabilir, örneğin AWS'de sunucu açıp Cloudflare'de DNS kaydı oluşturabilirsin.

Plan ve apply — güvenli değişiklik döngüsü

Terraform'un can damarı plan → apply döngüsüdür. terraform plan mevcut altyapıyı, state dosyasını ve senin kodunu karşılaştırır; sonra bir execution plan üretir. Bu plan sana net bir dille "1 kaynak eklenecek (+), 0 değişecek (~), 0 silinecek (-)" gibi bir özet gösterir. Planı onayladığında terraform apply bu değişiklikleri gerçek dünyada uygular. Bu iki adım, prod ortamda "acaba ne olacak?" korkusunu ortadan kaldırır.

Bağımlılık grafiği — doğru sırayı Terraform bulur

Altyapı kaynakları çoğu zaman birbirine bağımlıdır: bir subnet, ait olduğu VPC'den önce oluşturulamaz; bir sunucu, bağlanacağı güvenlik grubuna ihtiyaç duyar. Terraform, kodundaki referansları (aws_vpc.ana.id gibi) tarayarak kaynaklar arasında bir bağımlılık grafiği çıkarır ve oluşturma/silme sırasını kendisi belirler. Sen sadece "neyin neye bağlı" olduğunu referanslarla ima edersin; sıralamayı düşünmek zorunda kalmazsın. Bağımlılığı otomatik çözülemeyen istisnai durumlarda depends_on ile açıkça belirtebilirsin, ama çoğu zaman buna gerek kalmaz.

Bu grafiğin bir başka faydası da paralelliktir: birbirine bağımlı olmayan kaynakları Terraform eşzamanlı oluşturur, böylece büyük altyapılar bile makul sürede kurulur. Silme işleminde ise grafiği tersten yürür; önce bağımlı kaynakları, sonra üzerine kuruldukları temel kaynakları kaldırır.

State: Terraform'un en kritik kavramı

Terraform, yönettiği her kaynağın kaydını bir state (durum) dosyasında tutar (varsayılan olarak terraform.tfstate). Bu dosya, kodundaki kaynaklarla gerçek dünyadaki kaynaklar arasındaki köprüdür. plan çalıştırdığında Terraform "kodda ne yazıyor?" ile "state'te ne kayıtlı?" ve "buluta gerçekte ne var?" sorularını karşılaştırarak farkı bulur. State'i silersen ya da bozarsan Terraform yönettiği kaynakları "unutur" ve tekrar oluşturmaya kalkar; bu yüzden state, en dikkat edilmesi gereken parçadır.

State, Terraform öğrenirken en çok kafa karıştıran ve en çok hataya yol açan konudur. Nasıl çalıştığını, remote backend'lerin neden şart olduğunu ve state kilitleme (locking) gibi ekip senaryolarını derinlemesine anlatan Terraform state nedir? yazısını bu rehberden sonra mutlaka oku; ciddi projelerde ustalaşmanın anahtarı orada.

Terraform kurulumu

Terraform tek bir binary'den ibarettir; kurulumu son derece basittir. İşletim sistemine göre en yaygın yöntemleri aşağıda bulacaksın. Kurulum sonrası her zaman sürümü doğrula.

macOS (Homebrew)

$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform
$ terraform -version
Terraform v1.9.5
on darwin_arm64
✓ Terraform kuruldu

Linux (paket deposu) ve Windows

Linux'ta HashiCorp'un apt/yum deposunu ekleyip terraform paketini kurabilir, Windows'ta ise choco install terraform (Chocolatey) veya winget install HashiCorp.Terraform komutunu kullanabilirsin. Alternatif olarak her platformda HashiCorp'un sitesinden ZIP indirip binary'yi PATH'e koyman yeterli.

Bulut sağlayıcıyla gerçekten kaynak oluşturacaksan bir de kimlik doğrulama gerekir. AWS için aws configure ile erişim anahtarlarını ayarlaman ya da bir IAM rolü kullanman gerekir. Öğrenme aşamasında ücretsiz katmandaki (free tier) kaynaklarla ilerlemeni ve maliyet oluşturabilecek servislerden kaçınmanı öneririz.

İlk Terraform projen: adım adım

Şimdi teoriyi bir kenara bırakıp gerçek bir proje kuralım. Amacımız: küçük bir dizinde provider tanımlamak, tek bir kaynak oluşturmak ve tüm yaşam döngüsünü (init → plan → apply → destroy) baştan sona görmek. Bu örnekte maliyet oluşturmayan bir yerel kaynak yerine, kavramları netleştirmek için AWS S3 bucket'ı kullanıyoruz; mantık her sağlayıcıda aynıdır.

1. 1Yeni bir dizin oluştur: `mkdir terraform-ilk-proje && cd terraform-ilk-proje`.
2. 2`main.tf` dosyasını oluştur ve içine provider + resource bloklarını yaz (aşağıdaki kod).
3. 3`terraform init` ile provider'ı indir ve çalışma dizinini başlat.
4. 4`terraform plan` ile ne olacağını önizle.
5. 5`terraform apply` ile onaylayıp kaynağı gerçekten oluştur.
6. 6İşin bitince `terraform destroy` ile her şeyi temizle (maliyet birikmesin).

1. Konfigürasyon dosyası: main.tf

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

provider "aws" {
  region = "eu-central-1"
}

resource "aws_s3_bucket" "ilk" {
  bucket = "cloudpuz-ilk-proje-2026"

  tags = {
    Ortam = "ogrenme"
  }
}

2. init, plan, apply ve destroy

$ terraform init
Initializing provider plugins...
- Installing hashicorp/aws v5.62.0...
Terraform has been successfully initialized!
✓ init tamamlandi
 
$ terraform plan
Terraform will perform the following actions:
  # aws_s3_bucket.ilk will be created
  + resource "aws_s3_bucket" "ilk" {
      + bucket = "cloudpuz-ilk-proje-2026"
    }
Plan: 1 to add, 0 to change, 0 to destroy.
 
$ terraform apply -auto-approve
aws_s3_bucket.ilk: Creating...
aws_s3_bucket.ilk: Creation complete after 3s
✓ Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

terraform init çalışınca dizinde bir .terraform/ klasörü ve .terraform.lock.hcl dosyası oluşur; bu kilit dosyası provider sürümlerini sabitler ve ekipçe commit'lenmelidir. apply sonrası ise terraform.tfstate dosyası ortaya çıkar; işte Terraform'un gerçek dünya haritasını tuttuğu dosya budur. İşin bitince aşağıdaki komutla temizlik yap:

Perde arkasında ne olduğunu kısaca özetleyelim: init provider'ları indirip backend'i hazırlar; plan kodu, state'i ve gerçek altyapıyı karşılaştırıp bir eylem listesi çıkarır; apply bu listeyi provider aracılığıyla API çağrılarına çevirir ve sonucu state'e yazar; destroy ise state'te kayıtlı her şeyi ters bağımlılık sırasıyla siler. Bu dört komut, öğrendiğin her Terraform projesinin bel kemiğidir; ne kadar karmaşık altyapı kurarsan kur, döngü hep aynı kalır.

Temel Terraform komutları

$ terraform destroy -auto-approve
aws_s3_bucket.ilk: Destroying...
aws_s3_bucket.ilk: Destruction complete after 2s
✓ Destroy complete! Resources: 1 destroyed.

Değişkenler (variables) ve çıktılar (outputs)

Değerleri koda gömmek (hardcode) esnekliği öldürür. Aynı kodu farklı bölgelerde ya da ortamlarda kullanmak için değişkenler kullanırız. Değişkenler dış girdileri temsil eder; çıktılar ise oluşan kaynakların önemli değerlerini (IP adresi, URL, ID) dışarı verir.

variable "bolge" {
  description = "AWS bolgesi"
  type        = string
  default     = "eu-central-1"
}

variable "bucket_adi" {
  description = "Olusturulacak S3 bucket adi"
  type        = string
}

provider "aws" {
  region = var.bolge
}

resource "aws_s3_bucket" "ilk" {
  bucket = var.bucket_adi
}

output "bucket_arn" {
  description = "Olusan bucket'in ARN'i"
  value       = aws_s3_bucket.ilk.arn
}

Değişkenlere değer atamanın birkaç yolu vardır: komut satırında -var="bucket_adi=deneme", bir terraform.tfvars dosyasında bucket_adi = "deneme" satırıyla ya da TF_VAR_bucket_adi ortam değişkeniyle. default verilmemiş bir değişken için Terraform apply sırasında değeri sana sorar. Çıktılar ise apply sonunda ekrana yazılır ve terraform output komutuyla istendiğinde tekrar okunabilir; bu, çıktıları başka betiklere veya CI adımlarına aktarmak için idealdir.

Modüller: tekrar kullanılabilir altyapı

Projede aynı altyapı desenini tekrar tekrar yazmak yerine onu bir modül içine paketleyip yeniden kullanırsın. Bir modül, aslında .tf dosyalarını içeren bir dizinden ibarettir; girdi olarak değişken alır, çıktı olarak output verir. Böylece "standart bir VPC", "loglama etkinleştirilmiş bir S3 bucket'ı" gibi desenleri bir kez tanımlar, her yerde çağırırsın.

module "depolama" {
  source      = "./modules/s3-bucket"
  bucket_adi  = "cloudpuz-loglar-2026"
  versiyonla  = true
}

# Kayitli (registry) modul de kullanabilirsin:
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.8.1"
  name    = "ana-vpc"
  cidr    = "10.0.0.0/16"
}

Modüller, altyapı kodunu tıpkı yazılımdaki fonksiyonlar gibi organize etmeni sağlar: kopyala-yapıştır yerine tek kaynaktan yeniden kullanım. Terraform Registry'de topluluğun ve sağlayıcıların hazırladığı binlerce hazır modül bulabilir, örneğin AWS VPC'yi sıfırdan yazmak yerine iyi test edilmiş bir modülle dakikalar içinde kurabilirsin. Kendi modüllerini yazarken de aynı disiplin geçerlidir: net girdiler, anlamlı çıktılar ve tek bir sorumluluk.

Modül kullanmanın altyapı kalitesine somut etkisi vardır: iyi test edilmiş bir modül, güvenlik ayarlarını (şifreleme, en dar erişim, loglama) varsayılan olarak doğru yapar; böylece her yeni ortamda aynı hatayı tekrar etme riskini azaltırsın. Yeni başlarken tavsiyemiz, önce tek dosyalık bir konfigürasyonla kavramları oturtman, sonra tekrar eden desenleri fark ettikçe kademeli olarak modüllere çıkarmandır. Erken aşamada aşırı modülerleştirme, gereksiz karmaşıklık yaratabilir; modülerlik bir ihtiyaç doğduğunda uygulanan bir çözümdür, baştan zorlanan bir kural değil.

State yönetimi ve remote backend özeti

Tek başına çalışırken state dosyası makinende durabilir; ama bir ekipte herkesin kendi bilgisayarındaki terraform.tfstate ile çalışması felaket reçetesidir. İki kişi aynı anda apply çalıştırırsa state çakışır ve altyapı bozulur. Çözüm, state'i paylaşılan bir remote backend'de tutmaktır: AWS'de S3 + DynamoDB kilitleme, Azure'da Storage Account, GCP'de Cloud Storage ya da HashiCorp'un yönetilen çözümü Terraform Cloud.

terraform {
  backend "s3" {
    bucket         = "cloudpuz-tfstate"
    key            = "prod/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Remote backend üç kritik sorunu çözer: state'i merkezi ve güvenli (şifreli) tutar, aynı anda çalışan iki kişiyi engelleyen kilitleme (locking) sağlar ve state geçmişini saklar. State yönetiminin tüm detayları, ortam ayrıştırma (workspaces) stratejileri ve state taşıma/kurtarma komutları için yeniden hatırlatalım: Terraform state nedir? yazısı bu konunun tam referansıdır.

Terraform vs alternatifleri

Terraform tek IaC aracı değildir. Doğru aracı seçmek için farklarını bilmek gerekir. Aşağıdaki tablo en yaygın seçenekleri karşılaştırır:

Terraform en iyi pratikleri

Terraform'u öğrenmek kolay, ama sürdürülebilir kullanmak disiplin ister. İlk günden benimseyeceğin birkaç alışkanlık, ileride büyük acılardan kurtarır:

• State'i asla Git'e koyma. .gitignore'a *.tfstate* ve .terraform/ ekle; state'i remote backend'de tut.
• Kilit dosyasını commit'le. .terraform.lock.hcl provider sürümlerini sabitler; ekipçe aynı sürümü garantiler.
• `terraform fmt` ve `terraform validate` çalıştır. Kodu tutarlı biçimlendir ve sözdizimini doğrula; ideali CI'da otomatik yapmak.
• Kaynakları etiketle (tag). Ortam, proje, sahip gibi etiketler maliyet takibini ve temizliği kolaylaştırır.
• Modüllerle DRY kal. Tekrar eden deseni kopyalamak yerine modüle çıkar.
• Ortamları ayır. Prod ve test için ayrı state (ayrı dizin ya da workspace) kullan; yanlış ortama apply riskini düşür.
• Plan'ı gözden geçir. Özellikle prod'da apply öncesi planı bir ekip arkadaşına inceletmek en ucuz sigortadır.

Terraform ve CI/CD: altyapıyı otomatikleştirmek

Terraform'un asıl gücü, bir boru hattına (pipeline) bağlandığında ortaya çıkar. Manuel apply yerine, altyapı değişikliğini bir Pull Request olarak açar, otomatik plan çıktısını PR'da görür ve merge ile apply'ı tetiklersin. Bu yaklaşım, sürekli entegrasyon ve teslimat felsefesinin altyapıya uygulanmış halidir; temel kavramlar için CI/CD nedir? yazısına göz atabilirsin.

GitHub Actions ile basit bir Terraform boru hattı şöyle görünür: fmt ve validate kontrolleri, PR'da plan, main'e merge'de apply. Kendi ilk pipeline'ını sıfırdan kurmak istiyorsan GitHub Actions ile ilk pipeline rehberi adım adım yol gösterir.

name: terraform
on: [pull_request]
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan -no-color

Terraform Associate sertifikası ve kariyer

Terraform bilgini belgelemek istiyorsan HashiCorp'un Terraform Associate (003) sınavı doğal başlangıç noktasıdır. Sınav; IaC kavramları, Terraform iş akışı (init/plan/apply), state yönetimi, modüller, değişkenler ve provider'lar gibi bu rehberde gördüğün konuları ölçer. Çoktan seçmeli, orta zorlukta ve pratik odaklıdır; birkaç haftalık düzenli çalışma ve gerçek apply'larla rahatça geçilir.

Kariyer açısından Terraform, bir DevOps veya Cloud/Platform mühendisi için neredeyse zorunlu bir beceridir; ilan taramalarında en sık istenen araçlardan biridir. Ancak Terraform tek başına yeterli değil; onu bulut bilgisi ve otomasyon becerileriyle birleştirmen gerekir. Bulutun temellerini oturtmak için Bulut bilişim nedir?, rol odaklı yol haritası için DevOps engineer nasıl olunur? ve bulut sertifikalarını planlamak için AWS sertifika yol haritası 2026 yazılarımıza göz atmanı öneririz.

İş görüşmelerinde Terraform bilgin çoğunlukla teoriyle değil, senaryolarla ölçülür: "State bozulursa ne yaparsın?", "İki mühendis aynı anda apply çalıştırırsa ne olur?", "Var olan bir kaynağı Terraform yönetimine nasıl alırsın (import)?" gibi sorular sık gelir. Bu yüzden sertifika kadar önemli olan şey, gerçek projelerde yaşanan sorunları çözmüş olmandır. Küçük ama uçtan uca bir portföy projesi, örneğin bir statik siteyi S3 + CloudFront üzerinde Terraform'la kurup GitHub Actions'a bağladığın bir depo, CV'nde tek başına birçok sertifikadan daha ikna edici olabilir.

Sıkça Sorulan Sorular

Terraform ücretsiz mi?

Terraform'un çekirdek CLI aracı ücretsizdir ve HashiCorp Business Source License (BSL) altında dağıtılır; tamamen açık kaynak bir alternatif istiyorsan OpenTofu (MPL lisanslı) de birebir uyumludur. Ücretli olan kısım, HashiCorp'un yönetilen ekip platformu Terraform Cloud/Enterprise'ın gelişmiş özellikleridir. Öğrenmek ve çoğu proje için CLI fazlasıyla yeterlidir.

Terraform ile Ansible arasındaki fark nedir?

Terraform provisioning aracıdır: altyapıyı (sunucu, ağ, veritabanı) oluşturur ve bildirimsel çalışır. Ansible ise ağırlıklı olarak configuration management aracıdır: var olan sunucuların içini yapılandırır (paket kurar, dosya kopyalar, servis başlatır) ve daha imperative çalışır. İkisi rakip değil, tamamlayıcıdır; Terraform sunucuyu açar, Ansible içini kurar.

Terraform öğrenmek için önce programlama bilmem gerekir mi?

Hayır. HCL bir programlama dili değil, bildirimsel bir yapılandırma dilidir ve okuması oldukça kolaydır. Temel terminal kullanımı, JSON/YAML'a aşinalık ve bulut kavramlarına dair genel bir fikir başlamak için yeterlidir. Programlama bilmek modüller ve karmaşık ifadelerde işini kolaylaştırır ama ön koşul değildir.

terraform.tfstate dosyasını Git'e commit'leyebilir miyim?

Hayır, kesinlikle önerilmez. State dosyası hassas verileri düz metin içerebilir ve ekip çalışmasında çakışmalara yol açar. Bunun yerine .gitignore'a ekle ve state'i S3, GCS ya da Terraform Cloud gibi bir remote backend'de kilitlemeyle birlikte tut.

terraform plan gösterdiği değişiklikleri hemen uygular mı?

Hayır. terraform plan yalnızca ne olacağını gösteren, salt okunur bir önizlemedir; hiçbir gerçek değişiklik yapmaz. Değişiklikler yalnızca terraform apply çalıştırıp onay verdiğinde uygulanır. Bu ayrım, Terraform'un güvenli iş akışının temelidir.

Terraform Associate sınavına hazırlanmak ne kadar sürer?

Bulut ve IaC'ye tamamen yabancıysan günde 1-2 saat düzenli çalışmayla 4-6 hafta gerçekçi bir hedeftir. Halihazırda bir bulutta çalışıyorsan 2-3 hafta yeterli olabilir. En önemlisi, sadece okumak değil; gerçek init/plan/apply/destroy döngülerini kendi elinle çalıştırmaktır.

Buraya kadar geldiysen Terraform nedir sorusunun teorik cevabını da, ilk projeni ayağa kaldıracak pratik adımları da öğrendin: IaC felsefesinden HCL'e, provider'lardan plan/apply döngüsüne, state yönetiminden modüllere ve CI/CD entegrasyonuna kadar. Şimdi sıra pratikte: kendi makinende küçük bir kaynak oluştur, değişken ve çıktı ekle, sonra destroy ile temizle. Sonraki adım olarak state'i derinlemesine kavramak için Terraform state nedir? yazısını oku ve öğrendiklerini Cloudpuz'un uygulamalı laboratuvarlarında gerçek senaryolarla pekiştir. Altyapıyı kodla yönetmek, modern bulut kariyerinin en değerli becerilerinden biridir; bugün attığın bu ilk adım, ilerideki her projende karşılığını verecek.