Шпаргалка к собеседованию DevOps: 26 вопросов с чёткими отве
Terraform, AWS, Docker, Kubernetes и CI/CD. Короткие практичные ответы — чтобы подготовиться к интервью или просто проверить себя. Собеседования в этой сфере проверяют сразу две вещи: теорию и руки, поэтому ответы здесь не зазубренные определения, а то, что реально стоит понимать. Маленький совет перед стартом: не учите ответы наизусть. Хороший интервьюер после короткого ответа задаёт «а почему?» и «а что, если…», и тут зубрёжка рассыпается. Поэтому держите в голове логику, а не формулировку. Terraform 1. Как безопасно аутентифицировать облако в Terraform? Главное правило — не хардкодить ключи в .tf-файлах. Варианты по возрастанию надёжности: переменные окружения (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY); общий файл учёток (~/.aws/credentials); IAM-роли с временными токенами STS — самый безопасный вариант, потому что нет долгоживущих ключей; в CI — доступ через OIDC, чтобы вообще не хранить ключи; в Terraform Cloud секреты лежат как защищённые переменные. 2. Как хранить секреты в Terraform? помечайте переменные sensitive = true (прячет из вывода CLI); секреты передавайте через .tfvars, но никогда не коммитьте их в Git; используйте TF_VAR_* (например, TF_VAR_db_password); в проде интегрируйтесь с менеджером секретов (Vault, AWS Secrets Manager). Важная тонкость, которую любят спросить: sensitive прячет значение только из вывода, а в файле состояния (state) секрет лежит в открытом виде. Поэтому защищайте сам бэкенд состояния: шифрование и строгий доступ. 3. Зачем нужны удалённое состояние и блокировка (state locking)? State — это карта того, какими ресурсами Terraform уже управляет. Локальный файл не годится для команды: двое могут затереть друг друга. Решение — удалённый бэкенд (например, S3) с блокировкой и шифрованием: terraform { backend "s3" { bucket = "my-tfstate" key = "prod/terraform.tfstate" region = "eu-central-1" dynamodb_table = "tf-locks" # блокировка от одновременных apply encrypt = true } } 4. Чем count отличается от for_each?count создаёт ресурсы по числу и адресует их по индексу. Если удалить элемент из середины списка, остальные переиндексируются, и Terraform пересоздаст лишнее. for_each работает по ключам (set или map), адреса стабильны, изменения точечные. Для именованных, разнородных ресурсов почти всегда лучше for_each. 5. Как обнаружить и устранить дрейф конфигурации (drift)? Дрейф — это когда реальная инфраструктура разошлась с состоянием, обычно потому что кто-то поменял что-то руками в консоли. terraform plan показывает расхождение. Лечится дисциплиной: не менять вручную, возвращать всё через apply, а уже существующие ресурсы заводить под управление через terraform import.
· 25.06
Эти 26 вопросов закрывают костяк типичного собеседования, но сами по себе ответы — только половина дела. На реальном интервью за коротким ответом почти всегда идёт уточнение: почему именно так, а что будет, если сделать иначе. Поэтому по каждой теме полезно не просто прочитать, а потрогать руками: поднять у себя кластер, специально сломать readiness-пробу, собрать многоступенчатый образ, настроить удалённый state. Понимание, добытое практикой, держится на любых уточняющих вопросах, а заодно остаётся с вами и после собеседования.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён