Вопросы на собеседовании: Infrastructure as Code

Чем декларативная инфраструктура в Terraform отличается от shell-скрипта, который по очереди создаёт те же ресурсы?

как ответить В Terraform я описываю желаемую конфигурацию и связи ресурсов, а Terraform через provider, state и текущие данные строит план перехода. Императивный скрипт задаёт последовательность команд и сам должен распознавать уже созданное состояние, ошибки и частичный повтор. Декларативность облегчает review и convergence, но не отменяет понимание побочных эффектов provider API.

Что делают terraform init, plan и apply? Почему в автоматизации лучше применять сохранённый plan, а не снова запускать обычный apply после review?

terraform fmt -check
terraform init -input=false
terraform validate
terraform plan -out=tfplan
terraform show tfplan
terraform apply tfplan

как ответить init настраивает backend и устанавливает модули с providers, plan сравнивает конфигурацию, state и remote objects, а apply выполняет выбранные действия. plan -out сохраняет конкретный execution plan, и apply tfplan не строит вместо него новый набор изменений. Поэтому reviewer и apply-job работают с одним plan, хотя устаревшее внешнее состояние всё равно может привести к ошибке выполнения.

Зачем Terraform нужен state и почему terraform.tfstate нельзя хранить в Git как обычный файл конфигурации?

как ответить State связывает адреса ресурсов в конфигурации с конкретными удалёнными объектами и хранит metadata, нужные для планирования. Это не исходный код и не резервная копия инфраструктуры, а чувствительный изменяемый снимок управления. В команде его держат в защищённом remote backend с контролем доступа, versioning и, если backend умеет, locking.

Как Terraform понимает порядок создания этих ресурсов и когда здесь действительно понадобился бы depends_on?

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

как ответить Ссылка aws_vpc.main.id создаёт неявное ребро графа, поэтому subnet будет обработан после необходимых действий над VPC. depends_on здесь лишний. Его добавляют для скрытой поведенческой зависимости, которую нельзя выразить ссылкой на данные, и используют точечно.

Зачем одновременно нужны version constraints и .terraform.lock.hcl? Что именно lock-файл фиксирует, а что пока не фиксирует?

как ответить Constraints задают допустимый диапазон Terraform и provider versions, а lock-файл запоминает конкретно выбранные providers и их checksums для повторных init. Его коммитят и изменения ревьюят. Remote modules lock-файл не фиксирует, поэтому их version или неизменяемую source revision задают отдельно.

Два инженера одновременно запускают terraform apply. Как remote backend и state locking защищают команду, а от чего они не защищают?

как ответить Remote backend даёт участникам один актуальный state, а backend с locking не позволяет двум операциям одновременно записывать его. Terraform берёт lock автоматически для операций, способных менять state, и при неудаче не продолжает. Lock не защищает от ручных изменений в облаке, ошибок одной apply-job или двух разных state, управляющих одним объектом.

Кто-то вручную изменил firewall в облачной консоли, и следующий plan хочет вернуть старое значение. Как безопасно разобрать drift и выбрать источник нужного поведения?

terraform plan -refresh-only
terraform plan

как ответить Обычный plan обновляет представление remote objects в памяти и предлагает привести их к configuration, поэтому ручное правило будет удалено или изменено. plan -refresh-only отдельно показывает, как фактическое состояние отличается от записанного state, не планируя изменение инфраструктуры. После review я либо возвращаю объект к коду, либо сначала меняю configuration и осознанно принимаю drift в state.

Ресурс уже создан вручную, а теперь его нужно передать под Terraform. Что делает import и какой порядок действий не даст случайно пересоздать объект?

как ответить Import связывает существующий remote object с конкретным resource address в state; он не доказывает, что написанная конфигурация полностью совпадает с объектом. Сначала описываю destination resource или import block, делаю резервную копию state, выполняю import и внимательно проверяю последующий plan. Цель — получить no-op либо только заранее понятные изменения.

Как понять, что набор Terraform-ресурсов пора вынести в module, и каким должен быть его интерфейс?

как ответить Module оправдан, когда повторяется устойчивое инфраструктурное понятие с ясными inputs, outputs и политикой, а не просто несколько строк HCL. Интерфейс должен принимать зависимости от caller и возвращать только нужные результаты, чтобы модули можно было плоско компоновать. Огромный module с десятками boolean flags скрывает решения и связывает независимые lifecycle.

Когда применять create_before_destroy, prevent_destroy и ignore_changes? Какие опасные иллюзии безопасности создаёт каждая настройка?

lifecycle {
  create_before_destroy = true
  prevent_destroy       = true
  ignore_changes        = [tags["managed-externally"]]
}

как ответить create_before_destroy меняет порядок replacement, если старый и новый объект могут существовать вместе. prevent_destroy отклоняет plan с удалением, пока правило присутствует в configuration, а ignore_changes отдаёт перечисленные attributes другому владельцу при update. Ни одна настройка не заменяет review: они могут упереться в уникальные имена, быть обойдены удалением блока или скрыть опасный drift.

Переменная Terraform помечена sensitive = true. Гарантирует ли это отсутствие секрета в state и plan, и как спроектировать передачу секрета безопаснее?

как ответить sensitive в первую очередь скрывает значение в CLI и UI, но обычное sensitive-значение всё ещё может храниться в state и saved plan. Поэтому state и plan защищают как секреты, а постоянные credentials не вшивают в HCL или tfvars. Если Terraform и provider поддерживают ephemeral или write-only путь, его используют, иначе передают короткоживущее значение из secret manager и минимизируют его сохранение.

terraform apply упал после того, как часть ресурсов уже создалась. Почему Terraform не делает автоматический rollback и как безопасно привести configuration, state и облако к согласованному состоянию?

как ответить Terraform применяет граф по шагам; при ошибке он записывает в state известные успешно завершённые изменения, снимает lock и завершает apply. Общей транзакции с API провайдера и автоматического rollback нет. Сначала устраняю причину, сверяю state с фактическими объектами и строю новый plan; предыдущий state не восстанавливаю вслепую, иначе можно осиротить уже созданные ресурсы или получить дубликаты.