22 вопроса для DevOps и Cloud интервью: Terraform, AWS, Dock
Подготовка к DevOps и Cloud собеседованию сложна тем, что хороший интервьюер проверяет сразу два уровня: понимание того, как вещи работают, и умение применять это понимание в реальных ситуациях. Заученные определения здесь не помогут. Ниже двадцать с лишним вопросов, которые часто встречаются на практике, с ответами, ориентированными не на теорию, а на инженерное мышление. Terraform 1. Как безопасно аутентифицироваться в облаке через Terraform? Первое правило: никогда не хардкодить credentials прямо в .tf файлах. Это создаёт риск случайного попадания секретов в репозиторий, откуда они могут утечь навсегда — даже после удаления из истории. Правильные подходы, от менее к более предпочтительному. Переменные окружения: AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY Terraform подхватывает автоматически. Файл ~/.aws/credentials: стандартный механизм AWS CLI, который Terraform тоже понимает. IAM роли с временными STS-токенами: самый безопасный вариант, поскольку токены имеют ограниченный срок жизни и не требуют хранения долгосрочных ключей. В production на EC2 или в Kubernetes это должен быть выбор по умолчанию. Terraform Cloud или Workspaces: позволяет хранить credentials как защищённые переменные окружения, не касаясь локальной файловой системы. 2. Как правильно хранить секреты в Terraform? Используйте переменные с флагом sensitive = true — Terraform не будет выводить их значения в plan и apply. Передавайте секреты через .tfvars файлы, но никогда не коммитьте их в git. Добавьте *.tfvars в .gitignore и используйте .tfvars.example с заглушками как документацию. Для production интеграция с внешними системами хранения секретов значительно надёжнее: HashiCorp Vault, AWS Secrets Manager или Azure Key Vault. Terraform умеет получать секреты из них напрямую через data source во время apply, не сохраняя значения в state-файле. Важно: Terraform state file может содержать секретные значения в открытом виде. Удалённый backend с шифрованием (например, S3 с server-side encryption и доступом по IAM) обязателен для любого production окружения. 3. Что такое terraform taint и когда его использовать? terraform taint помечает ресурс как «испорченный» — при следующем terraform apply Terraform уничтожит этот ресурс и создаст его заново, даже если конфигурация не изменилась. Типичные случаи применения: ресурс попал в некорректное состояние из-за ручных изменений вне Terraform, или вы хотите принудительно пересоздать EC2-инстанс для применения нового user data скрипта. В современных версиях Terraform (начиная с 0.15.2) рекомендуется использовать terraform apply -replace="aws_instance.my_instance" вместо taint — это более явный и безопасный подход. 4. Как Terraform обрабатывает зависимости между ресурсами? Terraform строит граф зависимостей для каждого плана. Зависимости бывают двух видов. Неявные зависимости: когда один ресурс ссылается на атрибут другого через интерполяцию (${aws_vpc.main.id}), Terraform автоматически понимает, что второй ресурс должен быть создан раньше первого. Явные зависимости: через мета-аргумент depends_on, который указывает зависимость там, где Terraform не может её вывести автоматически — например, когда ресурс зависит от побочного эффекта другого ресурса, а не от его атрибута. Понимание графа зависимостей важно для отладки планов, где ресурсы создаются в неожиданном порядке или где параллельное создание приводит к race condition. 5. В чём разница между terraform plan и terraform apply с флагом -refresh=false? По умолчанию оба команды сначала обновляют state, запрашивая реальное состояние ресурсов из облачного провайдера (refresh). Это гарантирует актуальность плана, но добавляет время и создаёт лишние API-запросы. Флаг -refresh=false пропускает этот шаг. Terraform работает только с тем, что записано в state-файле, не обращаясь к провайдеру. Это ускоряет работу в больших инфраструктурах, но создаёт риск: если кто-то изменил ресурсы вне Terraform (drift), план не отразит этих изменений.
· 25.06
Знать правильный ответ — это половина дела. Вторая половина — уметь объяснить, почему именно так, и привести пример из реального опыта. Каждый из вопросов выше можно углубить: интервьюер часто идёт от общего к частному, проверяя, где заканчивается ваше понимание и начинается зазубренная теория. Если вы понимаете задачу, которую решает каждый инструмент — вы сможете обсуждать его на любом уровне детализации. Готовьтесь не к вопросам, а к разговору об инженерии.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён