Питання на співбесіді з Terraform: Повний посібник з Infrastructure as Code 2026

Питання на співбесіді з Terraform оцінюють здатність кандидата декларативно управляти хмарною інфраструктурою, безпечно працювати зі станом та проєктувати модулі багаторазового використання. З появою підтримки змінних у джерелах модулів у Terraform 1.14 та розширенням керованої платформи виконання HCP Terraform, у 2026 році інтерв'юери очікують від кандидатів як базових знань HCL, так і розуміння еволюції екосистеми Infrastructure as Code.

Базові концепції Terraform, які повинен знати кожен кандидат

Що таке Terraform і чим він відрізняється від інших IaC-інструментів?

Terraform — це декларативний інструмент Infrastructure as Code, який управляє хмарними ресурсами через конфігураційні файли, написані мовою HCL (HashiCorp Configuration Language). На відміну від імперативних інструментів, таких як Ansible чи shell-скрипти, Terraform підтримує файл стану, що відстежує поточну інфраструктуру, і обчислює різницю ("план") перед застосуванням змін.

Ключові відмінності: Terraform є хмарно-незалежним (підтримує AWS, Azure, GCP та сотні провайдерів), використовує робочий процес plan-перед-apply, що запобігає несподіванкам, та управляє залежностями ресурсів через внутрішній спрямований ациклічний граф (DAG).

Сильна відповідь також враховує зміни в екосистемі: після прийняття HashiCorp ліцензії BSL у 2023 році OpenTofu з'явився як open-source форк під егідою Linux Foundation. Обидва інструменти поділяють синтаксис HCL, але розходяться у функціональності. Terraform 1.14 зосереджується на інтеграції з платформою HCP, тоді як OpenTofu 1.9 пріоритизує шифрування стану та динамічні бекенди.

Поясніть робочий процес Terraform: init, plan, apply, destroy

Чотири основні команди формують життєвий цикл кожної операції Terraform:

# 1. Ініціалізація - завантажує провайдери та модулі
terraform init

# 2. План - показує що зміниться без модифікації чого-небудь
terraform plan -out=tfplan

# 3. Apply - виконує заплановані зміни
terraform apply tfplan

# 4. Destroy - видаляє всі керовані ресурси
terraform destroy

terraform init завантажує плагіни провайдерів та ініціалізує бекенд. terraform plan порівнює бажаний стан (конфігураційні файли) з актуальним станом (файл стану) та генерує набір змін. terraform apply виконує цей набір змін. Збереження плану у файл за допомогою -out гарантує, що буде застосовано саме той план, який було переглянуто — це критично важливо в CI/CD-пайплайнах.

Управління станом: Найпоширеніша тема на співбесідах

Що таке стан Terraform і чому він важливий?

Стан Terraform — це JSON-файл (terraform.tfstate), який зіставляє ресурси конфігурації з реальними об'єктами інфраструктури. Без стану Terraform не може визначити, що існує, що змінилося чи що потребує видалення.

Стан містить ідентифікатори ресурсів, значення атрибутів та метадані залежностей. Втрата стану означає, що Terraform втрачає контроль над усіма керованими ресурсами, що вимагає ручного імпорту кожного об'єкта або — ще гірше — залишає осиротілі хмарні ресурси, які продовжують генерувати витрати.

Як команди повинні управляти станом у продакшні?

Локальні файли стану неприйнятні для командних середовищ. Стандартна продакшн-конфігурація використовує віддалений бекенд з механізмом блокування:

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

Ця конфігурація зберігає стан в S3 із серверним шифруванням та використовує DynamoDB для блокування стану. Блокування запобігає одночасному запуску apply двома інженерами (або двома CI-пайплайнами), що призвело б до пошкодження стану.

HCP Terraform (раніше Terraform Cloud) пропонує керовану альтернативу, що забезпечує зберігання стану, блокування, історію запусків та RBAC без додаткової інфраструктури. Для організацій, які вже інвестували в екосистему HashiCorp, це усуває необхідність обслуговування S3-бакетів та таблиць DynamoDB.

Найкращі практики роботи з файлами стану

• Ніколи не комітити terraform.tfstate до системи контролю версій. Він може містити секрети (паролі до баз даних, API-ключі) у відкритому вигляді.
• Увімкнення шифрування at rest на бекенді (S3 SSE, шифрування GCS або Azure Storage).
• Використання окремих файлів стану для кожного середовища. Один файл стану для dev, staging та продакшн — це рецепт випадкового знищення.
• Впровадження блокування стану. Кожен віддалений бекенд, що підтримує цю функцію, повинен мати активне блокування.
• Використання terraform state list та terraform state show для інспекції стану без його модифікації.

Модулі: Компоненти інфраструктури багаторазового використання

Як працюють модулі Terraform?

Модуль — це директорія, що містить файли .tf, які інкапсулюють набір ресурсів. Кожна конфігурація Terraform технічно є модулем (кореневим модулем). Дочірні модулі викликаються з кореневого модуля для просування повторного використання та дотримання стандартів.

# main.tf - виклик модуля
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 впровадив суттєве покращення: змінні та локальні значення тепер можна використовувати в атрибутах source та version модулів. Раніше це було жорстке обмеження, яке вимагало обхідних рішень на кшталт Terragrunt для динамічного визначення джерел модулів.

Що визначає добре спроєктований модуль?

Модуль продакшн-класу дотримується таких принципів:

• Чіткі входи та виходи: Кожна змінна має опис, обмеження типу та розумне значення за замовчуванням, де це доречно. Виходи надають значення, необхідні downstream-модулям.
• Мінімальний обсяг: Модуль управляє одним логічним компонентом (VPC, кластер бази даних, namespace Kubernetes), а не цілим середовищем.
• Відсутність захардкоджених значень: Конфігурація провайдерів, регіон, ідентифікатори акаунтів та значення, специфічні для середовища, надходять зі змінних, ніколи з літералів всередині модуля.
• Версіоновані релізи: Опубліковані модулі використовують семантичне версіонування. Закріплення version = "5.16.0" запобігає несподіваним ламаючим змінам.

Workspaces, середовища та структура проєкту

Як управляти кількома середовищами?

Існують три поширені патерни, кожен зі своїми компромісами:

| Патерн | Механізм | Найкраще для | Ризик | |--------|----------|--------------|-------| | Workspaces | terraform workspace select prod | Простих проєктів, однакова конфігурація на середовище | Спільний бекенд стану, легко виконати apply на неправильному workspace | | Директорія-на-середовище | Окремі директорії dev/, staging/, prod/ | Повна ізоляція між середовищами | Дублювання коду між директоріями | | Terragrunt | DRY-обгортка, що генерує конфігурації бекенду | Великі мульти-акаунтні налаштування | Додаткова залежність від інструменту |

Підхід директорія-на-середовище зі спільними модулями є найпоширенішим у продакшні. Кожна директорія середовища містить main.tf, що викликає ті самі модулі з різними значеннями змінних, і кожна має власний ізольований файл стану.

У чому різниця між terraform workspace та ізоляцією директорій?

Workspaces створюють іменовані файли стану в межах одного бекенду. Перемикання workspace за допомогою terraform workspace select staging змінює, який файл стану Terraform читає та записує, але конфігурація залишається ідентичною.

Обмеження: workspaces поділяють ту саму конфігурацію бекенду та налаштування провайдера. Ізоляція директорій забезпечує сильніші межі — кожне середовище може використовувати інший AWS-акаунт, інший бекенд стану або навіть інші версії провайдерів. Для регульованих середовищ, що вимагають суворого контролю радіуса ураження, ізоляція директорій є безпечнішим вибором.

Провайдери, джерела даних та життєвий цикл ресурсів

Що таке провайдери та як їх налаштовувати?

Провайдери — це плагіни, які перетворюють конфігурацію HCL на API-виклики до конкретних платформ. AWS-провайдер викликає AWS API, Kubernetes-провайдер спілкується з API-сервером Kubernetes тощо.

# 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 дозволяє патч-оновлення (5.80.x), але блокує мінорні оновлення версій, балансуючи між стабільністю та патчами безпеки. Блок default_tags застосовує консистентне тегування до кожного ресурсу, створеного провайдером — часта тема обговорення на співбесідах щодо governance та розподілу витрат.

Поясніть різницю між джерелами даних та ресурсами

Ресурси (блоки resource) створюють, оновлюють та видаляють інфраструктуру. Джерела даних (блоки data) читають існуючу інфраструктуру без управління нею.

# Джерело даних - читає існуючий AMI, нічого не створює
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-*"]
  }
}

# Ресурс - створює EC2-інстанс, використовуючи джерело даних
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Джерела даних оцінюються під час plan, що робить їх корисними для посилання на спільну інфраструктуру (VPC, створені іншою командою), пошуку динамічних значень (останні ідентифікатори AMI) або читання зовнішньої конфігурації (параметри SSM, секрети Vault).

Просунуті теми: Import, блоки moved та тестування

Як працює terraform import і коли він потрібен?

terraform import пов'язує існуючий хмарний ресурс з блоком ресурсу Terraform. Типовий сценарій: інфраструктура була створена вручну (ClickOps) або іншим інструментом, і команда тепер хоче управляти нею через Terraform.

Terraform 1.5+ впровадив блоки import безпосередньо в конфігурації, замінивши робочий процес, заснований виключно на 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"
}

Запуск terraform plan з цим блоком генерує план, що включає існуючий бакет до стану. Цей декларативний підхід до імпорту доступний для перегляду в pull request'ах, повторюваний і не вимагає прямого CLI-доступу до стану.

Що таке блоки moved?

Рефакторинг коду Terraform (перейменування ресурсів, переміщення їх до модулів) історично вимагав команд terraform state mv. Блок moved обробляє це декларативно:

# Ресурс перейменовано з "web" на "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform розпізнає переміщення під час планування та автоматично оновлює стан, уникаючи циклу знищення-і-повторного-створення. Це безцінно при реструктуризації великих конфігурацій на модулі.

Як працює тестування в Terraform?

Terraform 1.6+ включає нативний фреймворк тестування з використанням файлів .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 = "CIDR-блок VPC не відповідає очікуваному значенню"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Очікувалося 3 приватні підмережі"
  }
}

Terraform 1.14 розширив цю функціональність блоками mock, що приймають функції, skip_cleanup для налагодження невдалих тестів та блоками backend всередині блоків run для ізольованого стану тестів. Нативне тестування усуває потребу в зовнішніх інструментах на кшталт Terratest для базової валідації.

Terraform у CI/CD-пайплайнах

Як виглядає продакшн-пайплайн Terraform?

Надійний CI/CD-пайплайн для Terraform забезпечує безпеку на кожному етапі:

1. Лінтинг і валідація: terraform fmt -check та terraform validate виявляють синтаксичні проблеми.
2. План на PR: Кожен pull request запускає terraform plan та публікує результат як коментар до PR. Жодного apply без перевіреного плану.
3. Перевірки політик: Інструменти на кшталт OPA (Open Policy Agent), Sentinel (HCP Terraform) або Checkov валідують план відповідно до організаційних політик (жодних публічних S3-бакетів, обов'язкове шифрування, необхідні теги).
4. Apply після merge: Після затвердження PR та проходження перевірок політик terraform apply запускається автоматично зі збереженого файлу плану.
5. Резервна копія стану: Після apply пайплайн перевіряє цілісність стану, а версіонування бекенду фіксує нову версію стану.

Золоте правило: жодна людина не повинна запускати terraform apply на продакшн з локальної машини. Усі продакшн-apply проходять через пайплайн.

Висновок

Ключові висновки для підготовки до співбесіди з Terraform:

• Управління станом — найважливіша тема. Необхідно розуміти віддалені бекенди, блокування, шифрування та стратегії відновлення після аварій перед тим, як йти на співбесіду.
• Проєктування модулів відрізняє junior-спеціалістів від senior. Варто продемонструвати здатність створювати модулі багаторазового використання, версіоновані, з чіткими інтерфейсами та мінімальним обсягом.
• Глибоке розуміння робочого процесу plan/apply є необхідним. Кандидат повинен пояснити, чому збереження планів у файли має значення, як DAG визначає порядок виконання та що робить -target (і чому його слід використовувати обережно).
• Terraform 1.14 приносить змінні в джерелах модулів, розширене тестування та тіснішу інтеграцію з HCP. Знання актуальних функцій свідчить про активне слідкування за екосистемою.
• Чесне ставлення до ландшафту Terraform vs OpenTofu важливе. Розуміння ліцензійного поділу, розбіжностей у функціях та того, коли кожен інструмент доречний, демонструє архітектурну зрілість, що виходить за межі знання синтаксису.
• Варто повторити основи співбесід з DevOps разом з темами Terraform, оскільки інтерв'юери часто поєднують питання про IaC з ширшими темами інфраструктури.
• Огляд концепцій розгортання Kubernetes рекомендується, оскільки Terraform часто створює кластери, на яких працюють робочі навантаження Kubernetes.