Вопросы по Terraform и Ansible на собеседовании

Инфраструктуру кодом проверяют вопросами про состояние и последствия: что покажет план после ручной правки в консоли, почему удаление элемента из середины списка пересоздаёт половину ресурсов, где в итоге оказывается пароль, помеченный как чувствительный.

Что спрашивают

• +Terraform и OpenTofu: план перед применением, провайдеры и пины версий, зеркала реестра для закрытого контура
• +Состояние: общий бэкенд и блокировка, дрейф после ручных правок, секреты внутри state
• +Структура: модули и переменные, count против for_each, размер стейта и радиус поражения
• +Ansible: идемпотентность и модули против shell, роли и inventory, граница ответственности с Terraform

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Terraform: основы8
• Ansible7
• Состояние и дрейф7
• IaC на практике6
• Модули и переменные6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Terraform: план, провайдеры, версии8 вопросов
• Состояние Terraform и дрейф7 вопросов
• Модули Terraform: count против for_each6 вопросов
• Ansible: идемпотентность и роли7 вопросов
• IaC на практике: ревью, политики, секреты6 вопросов

Примеры вопросов с разбором

1. #dvo_ansible1 / 9
   Что означает идемпотентность плейбука Ansible?

   A)Повтор ничего не меняет, если состояние уже нужное

   B)Плейбук одинаково работает во всех дистрибутивах

   C)Задачи выполняются в том же порядке при каждом запуске

   D)Ошибка на одном хосте останавливает выполнение на остальных

   показать ответ и разбор

   +A)Повтор ничего не меняет, если состояние уже нужное

   // разбор: Модули Ansible описывают желаемое состояние: пакет установлен, строка в файле есть, сервис запущен. Модуль сам проверяет текущее положение дел и отчитывается changed только когда реально что-то сделал. Отсюда полезное следствие для эксплуатации: второй прогон подряд должен давать ноль изменений, и это лучший тест плейбука.

2. #dvo_iac_practice2 / 9
   В чём смысл неизменяемой инфраструктуры вместо донастройки живых машин?

   A)Новая версия — новый образ и новая машина, старую гасим

   B)Обновления ставятся автоматически по расписанию на всех хостах

   C)Конфигурация хранится в одном месте и раздаётся агентом

   D)Машины перестают требовать мониторинга после сборки образа

   показать ответ и разбор

   +A)Новая версия — новый образ и новая машина, старую гасим

   // разбор: Долгоживущий сервер накапливает историю: ручные правки, разные версии пакетов, забытые эксперименты — два «одинаковых» хоста расходятся, и воспроизвести падение невозможно. Неизменяемый подход заменяет донастройку заменой: собрали образ, раскатали новые машины, старые погасили. Плата — нужна сборка образов и быстрая замена, зато состояние предсказуемо, а откат сводится к запуску прошлого образа.

3. #dvo_tf_basics3 / 9
   Зачем в Terraform смотреть plan, если apply всё равно спросит подтверждение?

   A)План прогревает кэш провайдеров и ускоряет применение

   B)План показывает расхождение кода и реальности до изменений

   C)План проверяет синтаксис конфигурации, apply это уже не делает

   D)План резервирует ресурсы у облака на время применения

   показать ответ и разбор

   +B)План показывает расхождение кода и реальности до изменений

   // разбор: Plan читает текущее состояние ресурсов, сравнивает с описанием в коде и печатает разницу: что создать, что изменить, что удалить и что пересоздать. Именно там ловят страшное — уничтожение базы из-за смены параметра, пересоздание сети, случайное удаление ресурса, выпавшего из кода. В CI план сохраняют как артефакт и применяют ровно его, чтобы между просмотром и применением ничего не поменялось.

4. #dvo_tf_state4 / 9
   Почему state не держат локально на ноутбуке и не коммитят в репозиторий?

   A)Файл слишком велик для системы контроля версий

   B)Terraform шифрует его ключом машины и на другой не прочитает

   C)Он общий, с секретами внутри и нужен под блокировкой

   D)Состояние живёт только в памяти и на диск пишется временно

   показать ответ и разбор

   +C)Он общий, с секретами внутри и нужен под блокировкой

   // разбор: State связывает описанные ресурсы с реальными идентификаторами в облаке — без него Terraform считает, что ничего не создано. Работать с ним должны все и CI, значит нужен общий бэкенд (объектное хранилище с версионированием) плюс блокировка от одновременных применений. Плюс в состоянии оседают значения ресурсов, включая пароли и ключи, поэтому в git ему не место.

5. #dvo_tf_structure5 / 9
   Три окружения различаются размерами машин и числом реплик. Зачем тут модуль?

   A)Модуль даёт отдельное состояние каждому окружению

   B)Модуль ускоряет применение за счёт параллельной обработки

   C)Один описанный набор ресурсов вызывается с разными значениями

   D)Модуль позволяет применять окружения по очереди в одном прогоне

   показать ответ и разбор

   +C)Один описанный набор ресурсов вызывается с разными значениями

   // разбор: Модуль — параметризованный кусок инфраструктуры: описали один раз, вызвали трижды с разными переменными. Так дев, стейдж и прод перестают расходиться: отличается только набор значений, а не копипаста конфигураций. Разделение состояний решается отдельно — своим бэкендом на окружение, и это дополняет модульность, а не заменяет её.

6. #dvo_ansible6 / 9
   Половина задач плейбука написана через модуль shell. Чем это оборачивается?

   A)Ansible откажется выполнять такой плейбук в режиме проверки

   B)Скорость упадёт: каждая команда открывает новое соединение

   C)Идемпотентность и отчёт об изменениях теряются

   D)Плейбук перестанет работать через управляющий узел без sudo

   показать ответ и разбор

   +C)Идемпотентность и отчёт об изменениях теряются

   // разбор: shell и command выполняют команду и почти всегда рапортуют changed, потому что не знают, изменилось ли что-то. Итог: отчёт бесполезен, повторный прогон делает работу заново, режим проверки врёт. Лечится штатными модулями, а где без команды никак — параметрами creates и removes или условием changed_when, которое объясняет Ansible, что считать изменением.

7. #dvo_iac_practice7 / 9
   Как ревьюить пул-реквест, который меняет инфраструктуру?

   A)Смотреть только диф кода: план проверит дежурный при применении

   B)Применить в тестовом окружении и сравнить консоли облака вручную

   C)Публиковать план в пул-реквест и гонять проверки политик

   D)Требовать, чтобы автор приложил скриншот успешного локального применения

   показать ответ и разбор

   +C)Публиковать план в пул-реквест и гонять проверки политик

   // разбор: Диф в коде не показывает последствия: строчка про параметр может означать пересоздание базы. Потому CI на каждый пул-реквест публикует план как комментарий или артефакт, а рядом гоняет проверки политик — запрет публичных бакетов, обязательные теги, ограничения по типам машин. Применяет тоже CI: локальный apply лишает всех истории изменений и обходит ревью.

8. #dvo_tf_basics8 / 9
   Вчерашний код сегодня даёт другой план, хотя ничего не меняли. Что скорее всего произошло?

   A)Подтянулась новая версия провайдера или модуля

   B)Провайдер сбросил кэш и перечитал ресурсы заново

   C)В облаке сменился регион по умолчанию

   D)Состояние устарело и требует ручной перезаписи

   показать ответ и разбор

   +A)Подтянулась новая версия провайдера или модуля

   // разбор: Без ограничения версий provider и module подтягиваются свежие — а там новые поля по умолчанию, изменённое поведение, иногда пересоздание ресурса. Потому версии пинят в required_providers и в источниках модулей, а файл блокировки (lock.hcl) коммитят: он фиксирует конкретные версии и хэши для всей команды и для CI. Обновление становится осознанным шагом с отдельным ревью плана.

9. #dvo_tf_state9 / 9
   Двое одновременно запустили apply на одном стейте. Что защищает от беды?

   A)Очередь в CI: применять можно лишь из пайплайна

   B)Блокировка состояния на время операции в бэкенде

   C)Версионирование хранилища: лишние версии потом откатят

   D)Проверка контрольной суммы плана перед применением

   показать ответ и разбор

   +B)Блокировка состояния на время операции в бэкенде

   // разбор: Бэкенд берёт блокировку на время plan-apply и второй процесс получает отказ с именем держателя. Без неё два применения перетирают состояние друг друга: часть ресурсов исчезает из учёта, дальше план предлагает создать существующее или удалить нужное. Очередь в CI и версионирование полезны, но это дисциплина и запасной парашют, а не механизм взаимного исключения.

Частые вопросы

• Зачем нужен state и почему его не коммитят?

  Состояние связывает описанные ресурсы с реальными идентификаторами в облаке. Оно общее для команды и CI, требует блокировки от параллельных применений и содержит значения ресурсов вплоть до паролей, поэтому живёт в защищённом бэкенде, а не в репозитории.

• Где проходит граница между Terraform и Ansible?

  Terraform ведёт учёт ресурсов и умеет удалять лишнее, приводя набор к описанному. Ansible приезжает на существующие хосты и приводит их конфигурацию к нужной, но не знает, что убрать, если задачу удалили из плейбука.