Microsoft Azure Administrator Associate
Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене AZ-104. Читайте сверху вниз или переходите к нужному разделу.
Автоматическое управление членством в группах безопасности на основе атрибутов пользователя (например, отдела).
Настройте группу безопасности Microsoft Entra ID с типом членства "Динамический пользователь" и определите правило на основе атрибутов.
Почему: Правила на основе атрибутов исключают постоянное ручное администрирование при изменении жизненного цикла пользователя. Требуется Entra ID P1/P2.
Применение согласованного управления (политик, RBAC) к нескольким подпискам из единой точки управления.
Создайте группу управления, поместите подписки под нее и назначьте политики или роли RBAC в области действия группы управления.
Почему: Политики и назначения ролей наследуются всеми дочерними подписками, что обеспечивает централизованное и согласованное управление.
Предотвращение развертывания ресурсов в неавторизованных регионах Azure для всей подписки.
Назначьте встроенную политику Azure "Разрешенные расположения" с эффектом `Deny` в области действия подписки.
Почему: Политика обеспечивает превентивное управление. RBAC контролирует действия, а не места развертывания. Блокировки ресурсов предотвращают изменение/удаление, а не новые развертывания.
Предоставление разрешений на управление виртуальными машинами, но не базовой виртуальной сетью или доступом пользователей.
Назначьте встроенную роль "Участник виртуальной машины" (Virtual Machine Contributor) в области действия группы ресурсов или ВМ.
Почему: Эта роль предоставляет определенные разрешения на управление ВМ (запуск, остановка, пересоздание образа) без предоставления широких прав Участника (Contributor) или Владельца (Owner).
Требовать MFA, когда пользователи получают доступ к определенным облачным приложениям (например, порталу Azure) из-за пределов корпоративной сети.
Создайте политику условного доступа с "Именованным расположением" для корпоративных IP-адресов в качестве условия исключения и требуйте MFA в качестве элемента управления предоставлением доступа.
Почему: Исключение доверенного расположения является ключом к обходу MFA в корпоративной сети при его принудительном применении везде.
Предотвращение удаления критически важных ресурсов, даже администраторами с ролями Владельца.
Примените блокировку ресурсов `CanNotDelete` или `ReadOnly` к ресурсу или его группе ресурсов.
Почему: Блокировки ресурсов применяются ко всем пользователям, независимо от их роли RBAC, обеспечивая сильнейшую защиту от случайного удаления.
Автоматическое исправление существующих несоответствующих ресурсов, выявленных политикой Azure (например, добавление отсутствующего тега).
Для политик с эффектами `Modify` или `DeployIfNotExists` создайте задачу исправления для назначения политики.
Почему: Задачи исправления запускают корректирующие действия политики для всех существующих несоответствующих ресурсов, автоматизируя процесс приведения среды в соответствие.
Формирование отчетов о затратах Azure с разбивкой по отделам, проектам или бизнес-подразделениям.
Примените единообразный тег (например, "CostCenter") ко всем ресурсам. Используйте Azure Cost Management для фильтрации и группировки затрат по этому тегу.
Почему: Теги являются основным механизмом для пользовательского распределения затрат и отчетности по различным группам ресурсов и подпискам.
Предоставление администраторам привилегированных ролей только при необходимости, на ограниченное время и с рабочим процессом утверждения.
Используйте Microsoft Entra Privileged Identity Management (PIM). Сделайте пользователей подходящими для ролей и настройте требования к активации.
Почему: PIM обеспечивает Just-In-Time (JIT) доступ, сокращая подверженность постоянных привилегированных учетных записей и предоставляя полный аудиторский след.
Предоставление внешним партнерам доступа к ресурсам Azure с использованием их собственных корпоративных учетных данных.
Используйте совместную работу Microsoft Entra B2B, чтобы пригласить партнеров в качестве гостевых пользователей в ваш клиент.
Почему: B2B позволяет избежать создания и управления новыми учетными данными в вашем клиенте; партнеры используют своего существующего поставщика удостоверений для аутентификации.
Минимизация затрат на хранение для долгосрочных данных (например, архивов соответствия), к которым редко обращаются, но которые должны быть сохранены.
Используйте политику управления жизненным циклом BLOB-объектов для автоматического перехода BLOB-объектов из уровня Hot/Cool на уровень Archive.
Почему: Уровень Archive имеет самую низкую стоимость хранения. Правила жизненного цикла автоматизируют процесс определения уровня на основе возраста BLOB-объекта или времени последнего доступа.
Обеспечение доступа для чтения к данным хранилища из вторичного региона во время сбоя основного региона.
Настройте учетную запись хранения с геоизбыточным хранилищем с доступом для чтения (RA-GRS) или RA-GZRS.
Почему: Стандартный GRS/GZRS реплицирует данные, но не позволяет читать из вторичного региона до отработки отказа. Префикс "RA" необходим для постоянного доступа для чтения.
Возможность немедленного отзыва набора токенов Shared Access Signature (SAS) для определенного контейнера.
Создавайте токены SAS на основе хранимой политики доступа к контейнеру. Для отзыва измените или удалите политику.
Почему: Изменение хранимой политики доступа немедленно аннулирует все связанные с ней токены SAS, обеспечивая централизованный механизм отзыва.
Синхронизация локального файлового сервера с общим ресурсом файлов Azure при минимизации использования локального дискового пространства.
Разверните Azure File Sync и включите многоуровневое хранение в облаке (cloud tiering) на конечной точке сервера.
Почему: Многоуровневое хранение в облаке сохраняет только часто используемые ("горячие") файлы в локальном кэше, в то время как менее используемые файлы переносятся в Azure, отображаясь как заглушки на локальном сервере.
Ограничение сетевого доступа к учетной записи хранения определенными подсетями VNet и публичными IP-адресами.
Включите брандмауэр учетной записи хранения. Добавьте правила виртуальной сети для подсетей и правила IP-адресов для публичных IP-адресов.
Почему: Брандмауэр хранилища обеспечивает контроль доступа на сетевом уровне непосредственно на публичной конечной точке учетной записи хранения, блокируя весь остальной трафик.
Защита BLOB-объектов от случайного удаления путем разрешения восстановления в течение указанного периода.
Включите обратимое удаление BLOB-объектов (blob soft delete) в учетной записи хранения и настройте период хранения (например, 14 дней).
Почему: Обратимое удаление сохраняет удаленные BLOB-объекты в течение настроенного периода, позволяя простое восстановление. Это первая линия защиты от случайной потери данных.
Выполнение требований соответствия для хранения данных в неизменяемом, нестираемом состоянии (WORM) в течение фиксированного периода.
Настройте политику хранения на основе времени для контейнера BLOB-объектов и заблокируйте политику.
Почему: Заблокированная политика хранения на основе времени делает BLOB-объекты неизменяемыми, предотвращая удаление или изменение кем-либо (включая администраторов) до истечения периода хранения.
Миграция очень большого набора данных (например, 50+ ТБ) в Azure Blob Storage при ограниченной пропускной способности сети.
Используйте физическое устройство Azure Data Box для автономной передачи.
Почему: Для больших наборов данных отправка физического устройства значительно быстрее, чем передача данных по медленному или перегруженному сетевому соединению.
Достижение SLA 99,99% для ВМ и защита приложения от сбоя одного центра обработки данных в регионе.
Разверните несколько экземпляров ВМ в разных зонах доступности (Availability Zones) в одном регионе.
Почему: Зоны доступности (Availability Zones) — это физически раздельные центры обработки данных. Наборы доступности (Availability Sets) защищают только от сбоев на уровне стойки в одном центре обработки данных (SLA 99,95%).
Развертывание и тестирование новой версии приложения с реальным производственным трафиком до полного выпуска, с нулевым временем простоя.
Используйте слот развертывания App Service. Разверните в слот, протестируйте, затем выполните замену. При необходимости используйте маршрутизацию трафика для канареечного тестирования.
Почему: Слоты предоставляют полную промежуточную среду. Операция замены — это почти мгновенное перенаправление трафика, обеспечивающее нулевое время простоя.
Запуск кратковременной, контейнеризированной пакетной задачи по расписанию, с минимальными затратами и без управления инфраструктурой.
Используйте Azure Container Instances (ACI).
Почему: ACI предлагает посекундную тарификацию и отсутствие накладных расходов на управление кластером, что делает его наиболее экономичным вариантом для спорадических или кратковременных контейнерных рабочих нагрузок.
Автоматическое масштабирование рабочей нагрузки с предсказуемыми ежедневными пиками (например, в рабочее время) с одновременной обработкой неожиданных всплесков.
Настройте автомасштабирование VM Scale Set с использованием как правил на основе расписания, так и правил на основе метрик.
Почему: Комбинация проактивного (по расписанию) и реактивного (по метрикам) масштабирования обеспечивает наилучший баланс производительности (готовность до пика) и экономичности (масштабирование вниз в режиме простоя).
Безопасное хранение образов контейнеров для кластера Azure Kubernetes Service (AKS) в частном реестре с проверкой уязвимостей.
Используйте Azure Container Registry (ACR) Premium SKU и интегрируйте его с AKS с помощью управляемого удостоверения.
Почему: ACR предоставляет частный реестр, расположенный в Azure. SKU Premium включает сканирование уязвимостей. Управляемое удостоверение обеспечивает безопасную аутентификацию без учетных данных от AKS к ACR.
Выполнение обновления ОС или приложения для всех экземпляров VMSS без простоя приложения.
Обновите модель VMSS (например, новую версию образа) и используйте политику Rolling upgrade.
Почему: Политика Rolling обновляет экземпляры конфигурируемыми пакетами, гарантируя, что подмножество экземпляров всегда доступно для обслуживания трафика на протяжении всего процесса обновления.
Развертывание многоконтейнерного приложения (например, приложение + sidecar для логирования), которое должно совместно использовать сеть и хранилище, без полного оркестратора.
Разверните контейнеры в одну группу контейнеров Azure Container Instances (ACI).
Почему: Группа контейнеров объединяет несколько контейнеров, совместно использующих сеть localhost и тома, что идеально подходит для паттернов sidecar без сложности Kubernetes.
Увеличение размера диска ОС или диска данных ВМ после ее развертывания.
Деallocate ВМ, измените размер ресурса диска в Azure, запустите ВМ, затем расширьте раздел внутри гостевой ОС.
Почему: Изменение размера диска Azure только выделяет больше места. Гостевая ОС должна быть проинструктирована использовать это новое пространство путем расширения раздела файловой системы.
Разрешить App Service безопасный доступ к секретам из Azure Key Vault без хранения учетных данных в приложении.
Включите системное управляемое удостоверение (system-assigned managed identity) в App Service и предоставьте этому удостоверению разрешения `Get` и `List` на секреты Key Vault.
Почему: Управляемое удостоверение предоставляет механизм аутентификации без учетных данных. Приложение может автоматически получить токен доступа для Key Vault, устраняя управление секретами.
Организация крупного, сложного развертывания инфраструктуры как кода в более мелкие, повторно используемые и поддерживаемые компоненты.
Рефакторинг развертывания в модули Bicep, где каждый модуль представляет логическую единицу (например, сеть, вычисления), и их оркестрация из основного файла Bicep.
Почему: Модули способствуют повторному использованию кода, улучшают читаемость и упрощают управление сложными развертываниями инфраструктуры.
Изоляция уровней приложения (веб, приложение, данные) внутри VNet, предотвращающая прямую связь между несмежными уровнями.
Используйте отдельную подсеть для каждого уровня и примените группы безопасности сети (NSG) к каждой подсети для контроля потока трафика.
Почему: NSG позволяют детальную, stateful фильтрацию на основе диапазонов IP-адресов источника/назначения (подсетей), портов и протоколов, обеспечивая микросегментацию сети.
Приватное соединение двух VNets в разных регионах Azure через магистральную сеть Microsoft.
Настройте глобальный пиринг VNet (Global VNet Peering) между двумя VNets.
Почему: Глобальный пиринг проще, имеет меньшую задержку и более высокую пропускную способность, чем VPN-соединение VNet-to-VNet. Трафик остается в частной сети Microsoft.
VNet-A подключена пирингом к Hub-VNet, и Spoke-VNet также подключена пирингом к Hub-VNet. ВМ в VNet-A не могут достичь ВМ в Spoke-VNet.
Причина в том, что пиринг VNet не транзитивен. Чтобы обеспечить связь, подключите VNet-A и Spoke-VNet напрямую или используйте NVA в Hub.
Почему: Пиринг не создает цепочку. Каждая VNet должна быть напрямую подключена для связи, если только не настроена маршрутизация через Network Virtual Appliance.
Установление постоянного, зашифрованного туннеля IPsec из локальной сети в VNet Azure через публичный интернет.
Разверните Azure VPN Gateway в VNet и настройте подключение Site-to-Site (S2S).
Почему: Это стандартное, безопасное и надежное решение для гибридной связи между одним локальным сайтом и VNet Azure.
Балансировщик нагрузки Azure продолжает отправлять трафик на неисправную серверную ВМ, вызывая тайм-ауты приложения.
Настройте проверку работоспособности (health probe) на балансировщике нагрузки, которая точно проверяет работоспособность приложения на серверных ВМ.
Почему: Балансировщик нагрузки полностью полагается на проверки работоспособности для обнаружения неисправных экземпляров. Без правильно настроенной проверки он не может удалить отказавшие ВМ из ротации трафика.
Маршрутизация HTTP/S трафика к различным пулам серверной части на основе пути URL (например, /images/* против /api/*).
Используйте Azure Application Gateway с правилами маршрутизации на основе пути.
Почему: Application Gateway — это балансировщик нагрузки уровня 7, который проверяет HTTP-запросы и может принимать решения о маршрутизации на основе путей URL. Стандартный Azure Load Balancer является уровнем 4 и не может этого.
ВМ в VNet с пользовательским DNS-сервером не могут разрешать имена хостов в частной зоне Azure Private DNS Zone.
Настройте пользовательский DNS-сервер для условной пересылки запросов для частной зоны на IP-адрес DNS-резолвера, предоставляемый Azure (168.63.129.16).
Почему: При использовании пользовательского DNS-сервера он обходит внутренний DNS Azure. Пользовательский сервер должен быть обучен разрешать Azure-специфические зоны путем пересылки запросов в Azure DNS.
Принудительная проверка всего исходящего в интернет трафика из периферийных VNets центральным Azure Firewall в центральной VNet.
Примените таблицу маршрутизации (Route Table) с определяемым пользователем маршрутом (UDR) к периферийным подсетям. UDR — это маршрут по умолчанию (0.0.0.0/0), указывающий на частный IP-адрес брандмауэра.
Почему: UDR переопределяет системный маршрут Azure по умолчанию к интернету, позволяя контролировать и централизовать поток исходящего трафика для проверки безопасности.
Предоставление безопасного RDP/SSH доступа к ВМ, не имеющим публичных IP-адресов, без настройки VPN.
Разверните Azure Bastion в выделенной подсети (AzureBastionSubnet) в VNet.
Почему: Bastion предоставляет управляемую службу jump box, обеспечивая безопасный административный доступ через портал Azure по TLS, исключая раскрытие публичных IP-адресов на ВМ.
Обеспечение того, чтобы трафик между ВМ и службой PaaS (например, Azure SQL) оставался в частной сети, а служба PaaS не была общедоступной.
Создайте частную конечную точку для службы PaaS в VNet ВМ и отключите доступ к публичной сети на службе PaaS.
Почему: Частная конечная точка предоставляет службе PaaS частный IP-адрес в вашей VNet, а отключение публичного доступа гарантирует, что она доступна только по этому частному IP-адресу.
Маршрутизация глобальных пользователей к ближайшей региональной конечной точке приложения для обеспечения наименьшей возможной задержки.
Используйте Azure Traffic Manager с методом маршрутизации "Performance".
Почему: Метод маршрутизации Performance использует DNS для направления клиентов к конечной точке с наименьшей задержкой сети из их местоположения.
Отправка уведомления (по электронной почте, SMS, webhook), когда метрика ресурса (например, процент загрузки ЦП ВМ) превышает пороговое значение в течение установленной длительности.
Создайте правило оповещения по метрикам (Metric Alert) в Azure Monitor и свяжите его с группой действий (Action Group), которая определяет действие уведомления.
Почему: Это стандартный шаблон. Правило оповещения определяет условие (что/когда), а группа действий определяет результирующее уведомление (кто/как).
Определение того, блокируется ли трафик между двумя ВМ определенным правилом группы безопасности сети (NSG).
Используйте инструмент IP Flow Verify в Azure Network Watcher.
Почему: IP Flow Verify имитирует поток пакетов и явно сообщает, какой NSG и какое правило разрешает или запрещает трафик, что делает его окончательным инструментом для устранения конфликтов NSG.
Настройка планового, основанного на политиках резервного копирования для ВМ Azure с согласованностью приложений и долгосрочным хранением.
Создайте хранилище Recovery Services, определите политику резервного копирования (расписание, хранение) и включите резервное копирование для целевых ВМ.
Почему: Хранилище Recovery Services является центральным объектом управления для Azure Backup. Оно безопасно хранит данные резервного копирования и управляет всеми операциями резервного копирования и восстановления.
Создание централизованной панели мониторинга для отслеживания производительности (ЦП, память, диск, сеть) ВМ в нескольких подписках.
Разверните центральную рабочую область Log Analytics и включите VM Insights для всех целевых ВМ, указывая их на эту рабочую область.
Почему: VM Insights собирает и агрегирует данные о производительности, предоставляя готовые рабочие книги и консолидированное представление производительности "в масштабе" по подпискам.
Проактивное выявление недостаточно используемых ресурсов Azure и возможностей для экономии затрат (например, правильное определение размера ВМ).
Регулярно просматривайте рекомендации по затратам в Azure Advisor.
Почему: Azure Advisor автоматически анализирует использование ресурсов и предоставляет действенные, персонализированные рекомендации по экономии затрат без дополнительной настройки.
Репликация ВМ Azure из основного региона во вторичный для обеспечения возможности аварийного восстановления.
Используйте Azure Site Recovery. Создайте хранилище Recovery Services и включите репликацию для ВМ в целевой регион.
Почему: ASR — это нативная служба Azure для оркестрации репликации ВМ, тестирования отработки отказа и отработки отказа/обратного восстановления между регионами Azure.
Установка различных периодов хранения данных для журналов безопасности и журналов производительности в одной рабочей области Log Analytics для оптимизации затрат.
Установите срок хранения по умолчанию на уровне рабочей области, а затем настройте более длительный срок хранения на уровне отдельных таблиц (например, для таблицы SecurityEvent).
Почему: Хранение по таблицам позволяет соответствовать долгосрочным требованиям к комплаенсу для определенных данных, минимизируя затраты на хранение менее критичных, объемных данных.
