Microsoft AZ-400: Инфраструктура как код и управление конфигурацией — Руководство по подготовке

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Инфраструктура как код (IaC) и управление конфигурацией в Azure позволяют многократно и безопасно определять, предоставлять и применять настройки инфраструктуры и приложений. Azure нативно поддерживает ARM JSON и Bicep, а также хорошо интегрируется с Terraform и Ansible. Состояние конфигурации можно объявлять с помощью PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef и Puppet. Развертывание функционала приложений и управление ключами централизованы с помощью Azure App Configuration и Key Vault. Неизменяемые образы, созданные с помощью Packer, уменьшают расхождения в конфигурации (drift). Управление (governance) реализуется как политика как код (policy-as-code) с помощью Azure Policy и OPA/Gatekeeper для Kubernetes.

Нативные средства IaC в Azure: шаблоны ARM и Bicep

Шаблоны ARM — это декларативные JSON-документы, которые Azure Resource Manager использует для создания и обновления ресурсов. Структура верхнего уровня включает $schema, contentVersion, parameters, variables, resources и outputs. parameters позволяют задавать входные данные для конкретной среды; variables помогают вычислять производные значения; resources объявляют желаемое состояние; outputs публикуют результаты, такие как идентификаторы ресурсов. Шаблоны поддерживают выражения и функции времени выполнения (например, resourceId, reference, concat, uniqueString), что позволяет конструировать имена и извлекать свойства.

Чтобы разбить большие развертывания на поддерживаемые блоки, можно использовать вложенные или связанные шаблоны. Вложенный шаблон встраивает JSON в свойство template ресурса Microsoft.Resources/deployments. Связанный шаблон ссылается на удаленный шаблон через templateLink.uri, который обычно хранится в Azure Storage и защищен для целостности с помощью SAS с ограниченным сроком действия. Используйте вложенные шаблоны, когда все может находиться в одном артефакте и вам требуется транзакционное развертывание всех частей. Используйте связанные шаблоны для очень больших топологий или при повторном использовании шаблонов между репозиториями или командами. Задавайте область развертывания (resource group, subscription, management group или tenant) по мере необходимости, устанавливая deployment scope на ресурсе deployments.

ARM поддерживает два режима развертывания. Incremental (по умолчанию) создает или обновляет ресурсы, присутствующие в шаблоне, не удаляя ничего, что не объявлено. Complete удаляет ресурсы в целевой области, которые не указаны в шаблоне, что полезно для гарантии минимального расхождения, но и более рискованно, если шаблон не является авторитетным для этой области. Операции Validate и What-If помогают предварительно просмотреть изменения, чтобы снизить риски перед выполнением.

Bicep — это предметно-ориентированный язык (DSL), который компилируется в ARM JSON и предлагает первоклассную эргономику для разработки. Объявления ресурсов используют символические имена, обеспечивают строгую типизацию и поддерживают ключевое слово existing для ссылки на уже существующие ресурсы без их повторного развертывания. parameters, variables, outputs и объявления ресурсов лаконичны, а отношения родитель-потомок и области видимости задаются явно. Модули обеспечивают композицию и повторное использование; каждый модуль — это Bicep-файл, на который ссылаются с помощью ключевого слова module, и который можно публиковать и использовать из template spec или реестров артефактов OCI. Условия выражаются встроенно с помощью if для ресурсов или модулей, а циклы используют выражения for для объявления нескольких экземпляров с четкой обработкой зависимостей. Миграция с ARM JSON проста: команда az bicep decompile (или bicep decompile) преобразует JSON в Bicep; затем вы проводите рефакторинг в модули и используете символические имена. Bicep обеспечивает преобразование в ARM без потерь и поддерживает всю поверхность платформы; команда bicep build генерирует стандартный ARM JSON для развертывания.

Кроссплатформенный IaC в Azure с помощью Terraform

Terraform дополняет нативные средства IaC в Azure, когда требуются мультиоблачные или не зависящие от провайдера рабочие процессы. Провайдер azurerm управляет ресурсами Azure Resource Manager, и его версию следует закреплять; включайте блок features {}, даже если он пуст, чтобы активировать функции провайдера. Другие распространенные провайдеры включают azuread для объектов AAD и random для служебных значений. Аутентифицируйтесь через service principal, Managed Identity на хост-агентах или с помощью Azure CLI. Применяйте четкую стратегию конфигурации провайдера для каждой среды и централизуйте повторно используемые модули с входными переменными и выходными значениями.

Управление состоянием (state) имеет решающее значение. Используйте бэкенд azurerm для хранения удаленного состояния в Azure Storage: настройте resource_group_name, storage_account_name, container_name и key; аутентифицируйтесь с помощью managed identity или SAS; и включите обратимое удаление (soft delete) и версионирование для blob-контейнера. Бэкенд использует аренду blob-объектов (blob leases) для блокировки состояния и предотвращения одновременных изменений. Доступ к учетной записи хранения должен контролироваться через RBAC и, опционально, ограничиваться с помощью Private Endpoints. Изолируйте файлы состояния для каждой среды и никогда не храните в них секреты — это заложено в дизайне. Используйте Key Vault и источники данных (data sources) для получения секретов при необходимости.

Рабочие области (workspaces) обеспечивают логическую изоляцию состояния в рамках одной конфигурации для ветвления по средам, таким как dev, test и prod. Используйте terraform workspace select и убедитесь, что ключ бэкенда кодирует рабочую область, чтобы избежать коллизий (например, myapp-${terraform.workspace}.tfstate). Рабочие области отлично подходят для поддержания паритета сред с небольшими различиями; когда топологии значительно расходятся, используйте отдельные конфигурации или модули, чтобы избежать расхождений и усложнения логики с условиями. Интегрируйте с Azure Pipelines, используя service connections и задачи Terraform CLI, чтобы стандартизировать init/plan/apply на разных этапах и контролировать применение изменений через утверждения и проверки политик.

Управление конфигурацией в масштабе: DSC, Azure Automation DSC, Ansible, Chef и Puppet

PowerShell Desired State Configuration (DSC) декларирует состояние для Windows и кроссплатформенных сред с помощью ресурсов. Существует два режима доставки: push-режим отправляет MOF-файлы напрямую на узлы; pull-режим заставляет узлы запрашивать свои MOF-файлы из pull-сервиса по расписанию. Local Configuration Manager (LCM) обеспечивает применение политики. Ключевые параметры LCM включают:

ConfigurationMode: ApplyOnly (настроить один раз, без исправления смещения), ApplyAndMonitor (обнаружить смещение, без исправления), ApplyAndAutoCorrect (обнаружить и исправить смещение).
ConfigurationModeFrequencyMins и RefreshFrequencyMins для настройки частоты применения и периодичности запросов (pull).
RebootNodeIfNeeded и ActionAfterReboot для управления перезагрузками.
Частичные конфигурации для составления состояния узла из нескольких MOF-файлов, которые независимо нацелены на определенные функции (например, базовое усиление безопасности ОС и роль приложения).

Azure Automation State Configuration (Azure Automation DSC) — это управляемый pull-сервис. Вы создаете конфигурации в PowerShell, импортируете их в Automation Account и запускаете задания компиляции, которые создают конфигурации узлов (MOF). Узлы регистрируются с помощью

undefined

, используя ключ регистрации/конечную точку, и могут быть сгруппированы и назначены конфигурациям с параметрами для каждого узла. Отчеты о соответствии показывают последнюю примененную конфигурацию и статус смещения; узлы в режиме ApplyAndAutoCorrect будут автоматически исправлять смещение при следующей проверке. Задания компиляции являются проверяемыми артефактами сборки, а управление доступом на основе ролей (RBAC) ограничивает права на создание конфигураций и назначение узлов.

Ansible — это безагентный инструмент, хорошо подходящий для настройки парка Linux-систем и ситуативной оркестрации. В Azure используйте azure.azcollection, который предоставляет модули для вычислений, сетей, Key Vault и многого другого. Динамический инвентарь с плагином azure_rm обнаруживает хосты из ваших подписок или конкретных групп ресурсов и тегов; получение учетных данных может использовать субъект-службу, Azure CLI или управляемое удостоверение. Интегрируйте с Azure Pipelines, установив Ansible на Linux-агенте, выполнив вход через AzureCLI@2 или подключение службы Azure Resource Manager, и запуская плейбуки, которые ссылаются на динамический инвентарь, группы переменных и защищенные файлы. Ansible отлично справляется с идемпотентными, читаемыми задачами и может дополнять DSC в средах с преобладанием Windows, управляя кроссплатформенными рабочими процессами и оркестрацией.

Chef и Puppet предоставляют зрелые модели «политика как код» и отчеты о соответствии. На виртуальных машинах Azure расширения Chef и Puppet VM выполняют начальную загрузку агентов во время подготовки, гарантируя раннюю конвергенцию. Chef Infra использует «кулинарные книги» (cookbooks) и Policyfiles для закрепления зависимостей и обеспечения воспроизводимых запусков; Chef InSpec выражает соответствие как код и передает отчеты в Chef Automate для анализа смещения и состояния контроля. Манифесты и модули Puppet кодируют желаемое состояние, а Code Manager и окружения обеспечивают процессы продвижения кода; Puppet Enterprise предоставляет централизованную отчетность, классификацию на основе ролей и исправление. Оба инструмента интегрируются с Azure через модули и поставщики ресурсов и могут сосуществовать с нативным DSC в Azure, когда это требуется для миграции или в смешанных средах.

Конфигурация приложений, неизменяемые образы и политика как код

Azure App Configuration централизует настройки приложений и флаги функций. Флаги функций позволяют выполнять постепенное развертывание: вы определяете флаги и, при необходимости, прикрепляете фильтры, такие как развертывание на процент пользователей или таргетинг на пользователей, с помощью библиотек Feature Manager. Метки позволяют разделять значения по средам или кольцам развертывания. Снимки конфигурации (Configuration snapshots) фиксируют неизменяемое представление набора ключей и меток на определенный момент времени, обеспечивая согласованное и воспроизводимое развертывание для множества сервисов без состояний гонки из-за одновременного изменения ключей. Ссылки на Key Vault позволяют хранить секреты в Key Vault, оставляя в App Configuration только ссылки на них; управляемое удостоверение приложения должно иметь разрешение get на секрет, а клиентские библиотеки разрешают и кэшируют секреты с возможностью динамического обновления. Используйте RBAC и сетевую изоляцию для обоих сервисов, чтобы защитить доступ.

Неизменяемая инфраструктура устраняет дрейф конфигурации путем пересоздания из известного образа вместо изменения существующих хостов. Сборщик azure-arm (теперь azure) в Packer создает образы из базовой ОС, запускает средства подготовки (provisioners), такие как shell, PowerShell, Ansible, и публикует их в Shared Image Gallery с репликацией по регионам и семантическим версионированием. Конвейер для создания «золотых образов» обычно выполняет линтинг шаблонов Packer, собирает образ, проводит сканирование на уязвимости и соответствие требованиям (например, с помощью InSpec), выполняет интеграционное тестирование, продвигает образ в галерею, а затем обновляет VM Scale Sets или пулы хостов. С помощью VM Scale Sets, скользящих обновлений или обновлений на основе состояния работоспособности, а также автоматических обновлений образов ОС вы получаете безопасные, согласованные развертывания и легкий откат путем выбора предыдущей версии образа.

Политика как код (Policy as code) обеспечивает соблюдение защитных ограничений. Определения Azure Policy — это JSON-объекты с policyRule, которое оценивает свойства ресурсов и применяет эффекты, такие как deny, audit, append, modify или deployIfNotExists для автоматического исправления. Параметризуйте определения для повторного использования; группируйте их в инициативы (наборы определений политик) для согласованного назначения и централизованного отслеживания соответствия. Назначайте политики на уровне группы управления, подписки или группы ресурсов; включайте задачи по исправлению для политик с эффектами modify и deployIfNotExists, чтобы привести существующие ресурсы в соответствие. Храните артефакты политик в системе контроля версий, рецензируйте их через pull-запросы и развертывайте с помощью Bicep, ARM или Terraform для последовательного продвижения по средам.

Для Kubernetes OPA/Gatekeeper применяет ограничения на этапе приема (admission). ConstraintTemplates определяют политики на языке Rego и их схемы; Constraints создают экземпляры этих политик для кластера. Типичные меры контроля включают ограничение образов только доверенными реестрами, требование наличия меток/аннотаций или запрет привилегированных подов. Gatekeeper интегрируется с инструментами GitOps (Flux/Argo CD) и тестированием в CI через conftest. Azure Policy for Kubernetes построен на базе Gatekeeper и предоставляет нативные для Azure возможности назначения и просмотра соответствия для кластеров AKS, объединяя управление облаком и кластерами на единой панели мониторинга состояния соответствия.

Практический сценарий

Компании Spotify необходимо стандартизировать инфраструктуру Azure, уменьшить дрейф конфигурации и ускорить безопасное развертывание функций для микросервисов, работающих на Windows и Linux, в AKS и на виртуальных машинах.

Моделируйте облачные ресурсы с помощью модулей Bicep для каждой области (сеть, данные, вычисления) и развертывайте их через подписки, привязанные к группам управления. Это дает типизированные, поддерживаемые объявления, четкое разграничение области действия и возможность повторного использования без многословности ARM JSON.
Используйте небольшое количество связанных спецификаций шаблонов ARM (template specs) для общих платформенных сервисов, потребляемых несколькими командами. Связанные шаблоны, размещенные как template specs, предоставляют версионированные, неизменяемые артефакты и отделяют ритм обновления платформы от команд приложений.
Выберите Terraform для управления мультиоблачными пограничными зависимостями и CDN, используя бэкенд azurerm для хранения удаленного состояния в Azure Storage для каждой рабочей области (dev/test/prod) и аренду blob-объектов для блокировки. Это сохраняет единый шаблон конвейера, безопасно изолируя состояние и обеспечивая согласованное продвижение.
Централизуйте конфигурацию приложений и флаги функций в Azure App Configuration. Флаги функций с процентными фильтрами и метками позволяют выполнять развертывание по кольцам; снимки конфигурации гарантируют, что каждый этап развертывания использует неизменяемый, аудируемый набор ключей.
Храните секреты в Azure Key Vault и ссылайтесь на них из App Configuration. Разрешение ссылок во время выполнения с помощью управляемого удостоверения позволяет ротировать ключи без повторного развертывания и удаляет секреты из конфигурации приложений и конвейеров.
Внедрите неизменяемые образы для рабочих нагрузок на ВМ, используя Packer для создания «золотых образов», публикуемых в Shared Image Gallery. Конвейер запускает скрипты для повышения безопасности (hardening) и сканирования InSpec, присваивает теги образам и продвигает только те версии, которые прошли проверку. VM Scale Sets используют образы из галереи для сине-зеленых и скользящих обновлений, устраняя дрейф.
Обеспечьте соблюдение защитных ограничений с помощью инициатив Azure Policy, которые запрещают использование публичных IP-адресов в частных подсетях, требуют наличия настроек диагностики для Log Analytics и автоматически развертывают политики резервного копирования. Назначайте их на уровне группы управления для широкого охвата и создавайте задачи по исправлению для существующих ресурсов, чтобы быстро привести их в соответствие.
Защитите AKS с помощью OPA/Gatekeeper, применяя ограничения, которые блокируют несоответствующие образы и привилегированные поды. Политики хранятся и версионируются в Git, проверяются с помощью conftest в CI и применяются через GitOps, чтобы состояние кластера всегда соответствовало политике.
Управляйте конфигурацией серверов Windows с помощью Azure Automation DSC. Узлы регистрируются с помощью Register-AzAutomationDscNode и используют ConfigurationMode=ApplyAndAutoCorrect для обнаружения и исправления дрейфа; задания компиляции создают MOF-файлы для каждой роли, а панели мониторинга соответствия отображают дрейф для расследования.
Управляйте конфигурацией и оркестрацией Linux с помощью Ansible, используя динамический инвентарь azure_rm и модули azure.azcollection. Azure Pipelines аутентифицируется с помощью управляемого удостоверения, идемпотентно запускает плейбуки и координирует обновления между сервисами, дополняя DSC на Windows.
Используйте профили Chef InSpec для кроссплатформенного соответствия как кода (compliance-as-code) как на образах, так и на запущенных хостах, передавая данные в Chef Automate для отчетности. Это встраивает аудируемые, тестируемые средства контроля в конвейер и производственную среду, обеспечивая непрерывную проверку соответствия нормативным требованиям.

Такая комбинация обеспечивает типизированную, модульную IaC (Bicep/Terraform), неизменяемые хосты (Packer), централизованную конфигурацию приложений (App Configuration/Key Vault), непрерывное применение конфигурации (Azure Automation DSC, Ansible) и строгое управление (Azure Policy, Gatekeeper). Это уменьшает дрейф, сокращает время восстановления и развертывания, а также делает соответствие требованиям доказуемым.

← Конвейеры CI · Все домены · Контейнеризация и Kubernetes →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →