Pytania rekrutacyjne z Terraform: Kompletny przewodnik po Infrastructure as Code 2026

Pytania rekrutacyjne z Terraform weryfikują umiejętność deklaratywnego zarządzania infrastrukturą chmurową, bezpiecznej obsługi stanu oraz projektowania modułów wielokrotnego użytku. Terraform 1.14 wprowadza zmienne w źródłach modułów, a HCP Terraform rozszerza swoją zarządzaną platformę wykonawczą — w 2026 roku rekruterzy oczekują od kandydatów zarówno solidnej znajomości HCL, jak i świadomości ewolucji ekosystemu Infrastructure as Code.

Podstawowe koncepcje Terraform, które musi znać każdy kandydat

Czym jest Terraform i czym różni się od innych narzędzi IaC?

Terraform to deklaratywne narzędzie Infrastructure as Code, które zarządza zasobami chmurowymi za pomocą plików konfiguracyjnych napisanych w HCL (HashiCorp Configuration Language). W przeciwieństwie do narzędzi imperatywnych, takich jak Ansible czy skrypty powłoki, Terraform utrzymuje plik stanu śledzący aktualną infrastrukturę i oblicza różnicę (tzw. "plan") przed wprowadzeniem zmian.

Kluczowe wyróżniki: Terraform jest niezależny od dostawcy chmury (obsługuje AWS, Azure, GCP i setki providerów), stosuje przepływ pracy plan-przed-apply zapobiegający niespodziankom oraz zarządza zależnościami zasobów przez wewnętrzny skierowany graf acykliczny (DAG).

Dobra odpowiedź uwzględnia również zmianę w ekosystemie: odkąd HashiCorp przyjęło licencję BSL w 2023 roku, OpenTofu pojawił się jako open-source'owy fork pod patronatem Linux Foundation. Oba narzędzia współdzielą składnię HCL, ale ich funkcjonalność się rozbiega. Terraform 1.14 skupia się na integracji z platformą HCP, podczas gdy OpenTofu 1.9 priorytetyzuje szyfrowanie stanu i dynamiczne backendy.

Wyjaśnij przepływ pracy Terraform: init, plan, apply, destroy

Cztery podstawowe polecenia tworzą cykl życia każdej operacji Terraform:

# 1. Inicjalizacja - pobiera providery i moduły
terraform init

# 2. Plan - pokazuje co się zmieni bez modyfikowania czegokolwiek
terraform plan -out=tfplan

# 3. Apply - wykonuje zaplanowane zmiany
terraform apply tfplan

# 4. Destroy - usuwa wszystkie zarządzane zasoby
terraform destroy

terraform init pobiera wtyczki providerów i inicjalizuje backend. terraform plan porównuje pożądany stan (pliki konfiguracyjne) z aktualnym stanem (plik stanu) i generuje zestaw zmian. terraform apply wykonuje ten zestaw zmian. Zapisanie planu do pliku za pomocą -out gwarantuje, że zastosowany zostanie dokładnie ten plan, który został zweryfikowany — co jest kluczowe w potokach CI/CD.

Zarządzanie stanem: Najczęstszy temat na rozmowach rekrutacyjnych

Czym jest stan Terraform i dlaczego jest istotny?

Stan Terraform to plik JSON (terraform.tfstate), który mapuje zasoby z konfiguracji na rzeczywiste obiekty infrastruktury. Bez stanu Terraform nie jest w stanie określić, co istnieje, co się zmieniło ani co wymaga usunięcia.

Stan zawiera identyfikatory zasobów, wartości atrybutów oraz metadane zależności. Utrata stanu oznacza, że Terraform traci kontrolę nad wszystkimi zarządzanymi zasobami, co wymaga ręcznego importu każdego obiektu lub — co gorsza — pozostawia osierocone zasoby chmurowe, które nadal generują koszty.

Jak zespoły powinny zarządzać stanem w produkcji?

Lokalne pliki stanu są niedopuszczalne w środowiskach zespołowych. Standardowa konfiguracja produkcyjna wykorzystuje zdalny backend z mechanizmem blokowania:

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

Ta konfiguracja przechowuje stan w S3 z szyfrowaniem po stronie serwera i wykorzystuje DynamoDB do blokowania stanu. Blokada uniemożliwia dwóm inżynierom (lub dwóm potokom CI) jednoczesne uruchomienie apply, co spowodowałoby uszkodzenie stanu.

HCP Terraform (dawniej Terraform Cloud) oferuje zarządzaną alternatywę obsługującą przechowywanie stanu, blokowanie, historię uruchomień i RBAC bez dodatkowej infrastruktury. Dla organizacji już zainwestowanych w ekosystem HashiCorp eliminuje to konieczność utrzymywania bucketów S3 i tabel DynamoDB.

Najlepsze praktyki dotyczące plików stanu

• Nigdy nie commitować terraform.tfstate do repozytorium. Może zawierać sekrety (hasła do baz danych, klucze API) w postaci jawnej.
• Włączenie szyfrowania at rest na backendzie (S3 SSE, szyfrowanie GCS lub Azure Storage).
• Używanie oddzielnych plików stanu dla każdego środowiska. Jeden plik stanu dla dev, staging i produkcji to przepis na przypadkowe zniszczenie infrastruktury.
• Wdrożenie blokowania stanu. Każdy zdalny backend obsługujący tę funkcję powinien mieć aktywne blokowanie.
• Uruchamianie terraform state list i terraform state show do inspekcji stanu bez jego modyfikacji.

Moduły: Komponenty infrastruktury wielokrotnego użytku

Jak działają moduły Terraform?

Moduł to katalog zawierający pliki .tf, które enkapsulują zestaw zasobów. Każda konfiguracja Terraform jest technicznie modułem (modułem głównym). Moduły podrzędne są wywoływane z modułu głównego w celu promowania ponownego użycia i egzekwowania standardów.

# main.tf - wywołanie modułu
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 wprowadził istotne usprawnienie: zmienne i lokale mogą być teraz używane w atrybutach source i version modułów. Wcześniej było to twarde ograniczenie, które wymuszało stosowanie obejść, takich jak Terragrunt, do dynamicznego określania źródeł modułów.

Co definiuje dobrze zaprojektowany moduł?

Moduł klasy produkcyjnej przestrzega następujących zasad:

• Czytelne wejścia i wyjścia: Każda zmienna posiada opis, ograniczenie typu i sensowną wartość domyślną tam, gdzie to ma zastosowanie. Wyjścia udostępniają wartości potrzebne modułom downstream.
• Minimalny zakres: Moduł zarządza jednym logicznym komponentem (VPC, klaster bazy danych, namespace Kubernetes), a nie całym środowiskiem.
• Brak zakodowanych wartości na sztywno: Konfiguracja providerów, region, identyfikatory kont i wartości specyficzne dla środowiska pochodzą ze zmiennych, nigdy z literałów wewnątrz modułu.
• Wersjonowane wydania: Opublikowane moduły korzystają z wersjonowania semantycznego. Przypięcie version = "5.16.0" zapobiega nieoczekiwanym zmianom łamiącym.

Workspaces, środowiska i struktura projektu

Jak zarządzać wieloma środowiskami?

Istnieją trzy popularne wzorce, z których każdy ma swoje kompromisy:

| Wzorzec | Mechanizm | Najlepszy dla | Ryzyko | |---------|-----------|---------------|--------| | Workspaces | terraform workspace select prod | Prostych projektów, ta sama konfiguracja na środowisko | Współdzielony backend stanu, łatwo wykonać apply na złym workspace | | Katalog-na-środowisko | Oddzielne katalogi dev/, staging/, prod/ | Pełna izolacja między środowiskami | Duplikacja kodu między katalogami | | Terragrunt | Wrapper DRY generujący konfiguracje backendu | Duże konfiguracje wielokontowe | Dodatkowa zależność narzędziowa |

Podejście katalog-na-środowisko ze współdzielonymi modułami jest najczęściej stosowane w produkcji. Każdy katalog środowiska zawiera main.tf wywołujący te same moduły z różnymi wartościami zmiennych, a każdy ma własny izolowany plik stanu.

Czym różni się terraform workspace od izolacji katalogowej?

Workspaces tworzą nazwane pliki stanu w ramach tego samego backendu. Przełączenie workspace za pomocą terraform workspace select staging zmienia, który plik stanu Terraform odczytuje i zapisuje, ale konfiguracja pozostaje identyczna.

Ograniczenie: workspaces współdzielą tę samą konfigurację backendu i ustawienia providera. Izolacja katalogowa zapewnia silniejsze granice — każde środowisko może korzystać z innego konta AWS, innego backendu stanu, a nawet innych wersji providerów. W środowiskach regulowanych wymagających ścisłej kontroli promienia rażenia izolacja katalogowa jest bezpieczniejszym wyborem.

Providery, źródła danych i cykl życia zasobów

Czym są providery i jak je konfigurować?

Providery to wtyczki, które tłumaczą konfigurację HCL na wywołania API do konkretnych platform. Provider AWS wywołuje API AWS, provider Kubernetes komunikuje się z serwerem API Kubernetes i tak dalej.

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

Ograniczenie wersji ~> 5.80 pozwala na aktualizacje patch (5.80.x), ale blokuje aktualizacje minor version, balansując między stabilnością a łatkami bezpieczeństwa. Blok default_tags stosuje spójne tagowanie do każdego zasobu tworzonego przez provider — częsty temat rozmów rekrutacyjnych dotyczący governance i alokacji kosztów.

Źródła danych a zasoby

Zasoby (bloki resource) tworzą, aktualizują i usuwają infrastrukturę. Źródła danych (bloki data) odczytują istniejącą infrastrukturę bez zarządzania nią.

# Źródło danych - odczytuje istniejące AMI, nie tworzy niczego
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-*"]
  }
}

# Zasób - tworzy instancję EC2 używając źródła danych
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Źródła danych są ewaluowane podczas plan, co czyni je przydatnymi do odwoływania się do współdzielonej infrastruktury (VPC utworzone przez inny zespół), wyszukiwania dynamicznych wartości (najnowsze identyfikatory AMI) lub odczytywania konfiguracji zewnętrznej (parametry SSM, sekrety Vault).

Zaawansowane tematy: Import, bloki moved i testowanie

Jak działa terraform import i kiedy jest potrzebny?

terraform import wiąże istniejący zasób chmurowy z blokiem zasobu Terraform. Typowy scenariusz: infrastruktura została utworzona ręcznie (ClickOps) lub przez inne narzędzie, a zespół chce teraz zarządzać nią przez Terraform.

Terraform 1.5+ wprowadził bloki import bezpośrednio w konfiguracji, zastępując przepływ oparty wyłącznie na CLI:

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

Uruchomienie terraform plan z tym blokiem generuje plan, który adoptuje istniejący bucket do stanu. To deklaratywne podejście do importu jest przeglądalne w pull requestach, powtarzalne i nie wymaga bezpośredniego dostępu CLI do stanu.

Czym są bloki moved?

Refaktoryzacja kodu Terraform (zmiana nazw zasobów, przenoszenie ich do modułów) historycznie wymagała poleceń terraform state mv. Blok moved obsługuje to deklaratywnie:

# Zmiana nazwy zasobu z "web" na "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform rozpoznaje przeniesienie podczas planowania i automatycznie aktualizuje stan, unikając cyklu zniszczenie-i-ponowne-utworzenie. Jest to nieocenione przy restrukturyzacji dużych konfiguracji na moduły.

Jak działa testowanie w Terraform?

Terraform 1.6+ zawiera natywny framework testowy wykorzystujący pliki .tftest.hcl:

# 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 = "Blok CIDR VPC nie odpowiada oczekiwanej wartości"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Oczekiwano 3 prywatnych podsieci"
  }
}

Terraform 1.14 rozszerzył tę funkcjonalność o bloki mock akceptujące funkcje, skip_cleanup do debugowania nieudanych testów oraz bloki backend w blokach run dla izolowanego stanu testowego. Natywne testowanie eliminuje potrzebę stosowania zewnętrznych narzędzi takich jak Terratest do podstawowej walidacji.

Terraform w potokach CI/CD

Jak wygląda produkcyjny potok Terraform?

Solidny potok CI/CD dla Terraform wymusza bezpieczeństwo na każdym etapie:

1. Lint i walidacja: terraform fmt -check i terraform validate wychwytują problemy składniowe.
2. Plan na PR: Każdy pull request uruchamia terraform plan i publikuje wynik jako komentarz w PR. Żadne apply bez zweryfikowanego planu.
3. Kontrole polityk: Narzędzia takie jak OPA (Open Policy Agent), Sentinel (HCP Terraform) lub Checkov walidują plan względem polityk organizacji (brak publicznych bucketów S3, obowiązkowe szyfrowanie, wymagane tagi).
4. Apply po merge: Po zatwierdzeniu PR i przejściu kontroli polityk, terraform apply uruchamia się automatycznie z zapisanego pliku planu.
5. Kopia zapasowa stanu: Po apply potok weryfikuje integralność stanu, a wersjonowanie backendu rejestruje nową wersję stanu.

Złota zasada: żaden człowiek nie powinien uruchamiać terraform apply na produkcji z lokalnej maszyny. Wszystkie produkcyjne apply przechodzą przez potok.

Podsumowanie

Kluczowe wnioski dotyczące przygotowania do rozmowy rekrutacyjnej z Terraform:

• Zarządzanie stanem to najważniejszy temat. Należy rozumieć zdalne backendy, blokowanie, szyfrowanie i strategie odzyskiwania po awarii przed przystąpieniem do rozmowy.
• Projektowanie modułów odróżnia juniorów od seniorów. Warto wykazać się umiejętnością budowania modułów wielokrotnego użytku, wersjonowanych, z czytelnymi interfejsami i minimalnym zakresem.
• Głębokie zrozumienie przepływu plan/apply jest niezbędne. Kandydat powinien wyjaśnić, dlaczego zapisywanie planów do plików ma znaczenie, jak DAG określa kolejność wykonania i co robi -target (oraz dlaczego należy go używać oszczędnie).
• Terraform 1.14 przynosi zmienne w źródłach modułów, rozszerzone testowanie i ściślejszą integrację z HCP. Znajomość aktualnych funkcji świadczy o aktywnym śledzeniu ekosystemu.
• Uczciwe podejście do krajobrazu Terraform vs OpenTofu jest ważne. Zrozumienie podziału licencyjnego, rozbieżności funkcji i tego, kiedy każde narzędzie pasuje, demonstruje dojrzałość architektoniczną wykraczającą poza składnię.
• Warto powtórzyć podstawy rozmów rekrutacyjnych DevOps obok zagadnień Terraform, ponieważ rekruterzy często mieszają pytania o IaC z szerszymi tematami infrastruktury.
• Przegląd koncepcji wdrożeń Kubernetes jest zalecany, gdyż Terraform często provisionuje klastry, na których działają obciążenia Kubernetes.