Microsoft Azure Developer Associate
Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене AZ-204. Читайте сверху вниз или переходите к нужному разделу.
Требуется план службы приложений для производственного веб-приложения с пользовательскими доменами/SSL, автомасштабированием и слотами развертывания.
Используйте уровень плана службы приложений Standard (S1) или выше.
Почему: Standard — это минимальный уровень, поддерживающий все ключевые производственные функции: пользовательские домены с SSL, автомасштабирование и слоты развертывания. Уровень Basic не поддерживает автомасштабирование и слоты.
Выполнить развертывание службы приложений без простоя и сохранить производственные настройки (например, строки подключения) в рабочем слоте.
Используйте слоты развертывания. Отметьте производственные настройки как "настройки слота развертывания" (sticky). Выполните операцию подкачки для развертывания.
Почему: Операция подкачки прогревает промежуточный слот перед перенаправлением трафика. Закрепленные настройки не перемещаются вместе с кодом во время подкачки, предотвращая запуск промежуточных настроек в производство.
Служба приложений должна подключиться к локальному ресурсу (например, SQL Server) без VPN или ExpressRoute.
Используйте гибридные подключения службы приложений. Установите Hybrid Connection Manager (HCM) локально.
Почему: Гибридные подключения обеспечивают безопасный TCP-туннель к локальным ресурсам без необходимости открытия входящих портов брандмауэра, VPN или интеграции с VNet. HCM инициирует исходящее соединение.
Функция Azure в плане Consumption испытывает длительные холодные запуски, что приводит к задержкам.
Перейдите на план Functions Premium и настройте как минимум один предварительно разогретый экземпляр.
Почему: План Premium устраняет холодные запуски, поддерживая заданное количество экземпляров всегда готовыми. Он более экономичен, чем полный план Dedicated для этой цели.
Функция Azure в плане Consumption истекает по времени, так как ее выполнение занимает более 10 минут.
Перенесите функцию на план Premium или Dedicated (службы приложений).
Почему: План Consumption имеет максимальное время ожидания 10 минут. Планы Premium и Dedicated поддерживают значительно более длительное время выполнения (до 60 минут или неограниченно).
Обработать большое количество независимых элементов параллельно и дождаться завершения всех, прежде чем продолжить.
Реализуйте шаблон Durable Functions Fan-out/Fan-in. Оркестратор вызывает несколько функций действий одновременно и использует `Task.WhenAll` (или эквивалент) для ожидания завершения.
Почему: Этот шаблон разработан для параллельного выполнения, что гораздо эффективнее последовательной обработки (цепочки функций) для независимых задач.
Длительный рабочий процесс должен ждать внешнего события, например, подтверждения человека, с тайм-аутом.
Используйте шаблон Durable Functions Human Interaction. Объедините `waitForExternalEvent` с `createTimer`. Используйте `Task.WhenAny` для продолжения, когда либо событие наступит, либо таймер истечет.
Почему: Этот шаблон позволяет оркестрациям приостанавливаться на неопределенное время без потребления вычислительных ресурсов, ожидая внешнего триггера, а также изящно обрабатывая тайм-ауты.
Контейнеризованное приложение должно масштабироваться до нуля экземпляров при отсутствии трафика для минимизации затрат.
Используйте Azure Container Apps с правилом масштабирования на основе KEDA (например, HTTP-запросы или длина очереди).
Почему: Container Apps с масштабировщиками KEDA могут масштабироваться до нуля реплик при простое и масштабироваться по требованию, что идеально подходит для событийных или прерывистых рабочих нагрузок. Масштабирование по CPU/памяти не может масштабироваться до нуля.
Бэкенд-микросервис в Azure Container Apps должен быть доступен только другим контейнерным приложениям в той же среде, а не из общедоступного Интернета.
Включите входящий трафик для бэкенд-контейнерного приложения и установите видимость трафика на `internal`.
Почему: Внутренний входящий трафик ограничивает доступ к среде Container Apps. Другие приложения в среде могут обнаруживать и вызывать службу, используя ее внутреннее FQDN.
Требуется запустить один контейнер для простой задачи, теста или пакетного задания без оркестрации.
Используйте Azure Container Instances (ACI).
Почему: ACI — это самый быстрый и простой способ запуска одного контейнера без управления какой-либо базовой инфраструктурой. Используйте Container Apps или AKS для оркестрации многоконтейнерных приложений.
Требуется собрать и отправить образ Docker в Azure Container Registry (ACR) из локального Dockerfile, но Docker не установлен локально.
Используйте команду `az acr build`.
Почему: `az acr build` переносит процесс сборки в ACR Tasks в облаке. Он отправляет контекст сборки в Azure, собирает образ и сохраняет его непосредственно в реестре.
Разработка контейнера Cosmos DB с частыми запросами, фильтрующими по определенному свойству (например, `region`).
Выберите наиболее часто запрашиваемое свойство с высокой мощностью как ключ раздела (например, `/region`).
Почему: Запросы, которые включают ключ раздела в предложение `WHERE`, направлены на один логический раздел, что позволяет избежать дорогостоящих запросов с распространением по разделам и минимизировать потребление RU.
Глобально распределенное приложение требует, чтобы операции чтения всегда возвращали самую последнюю зафиксированную запись.
Настройте уровень согласованности учетной записи Cosmos DB на Strong (строгий).
Почему: Строгая согласованность обеспечивает гарантию линеаризуемости, гарантируя, что операции чтения всегда актуальны. Другие уровни (Session, Bounded Staleness, Eventual) обменивают согласованность на меньшую задержку и более высокую доступность.
Требуется обрабатывать все новые или обновленные документы в контейнере Cosmos DB в реальном времени для обновления материализованного представления.
Используйте функцию Azure с триггером Cosmos DB, который использует процессор канала изменений.
Почему: Канал изменений предоставляет постоянный журнал изменений. Триггер Cosmos DB с процессором канала изменений автоматизирует управление состоянием и балансировку нагрузки между несколькими экземплярами функций.
Требуется выполнить атомарную операцию над несколькими документами в рамках одного логического раздела (например, создать два и обновить один).
Используйте API `TransactionalBatch` в SDK Cosmos DB. Все операции должны быть нацелены на один и тот же ключ раздела.
Почему: TransactionalBatch гарантирует, что все операции в пакете завершаются успешно или терпят неудачу как единая атомарная единица, предотвращая частичные обновления. Это более эффективно, чем хранимая процедура для пакетных операций на стороне клиента.
Рабочая нагрузка Cosmos DB непредсказуема, со значительными пиками и спадами трафика.
Настройте автомасштабируемую подготовленную пропускную способность для базы данных или контейнера.
Почему: Автомасштабирование автоматически масштабирует RU/с в зависимости от использования, обеспечивая производительность во время пиков и экономию средств во время спадов. Оно масштабируется между 10% и 100% от максимально настроенных RU/с.
Данные сначала часто доступны, затем нечасто, и, наконец, архивируются для долгосрочного хранения.
Используйте комбинацию уровней доступа Hot, Cool и Archive. Автоматизируйте переходы с помощью политики управления жизненным циклом.
Почему: Согласование уровня доступа с шаблоном доступа оптимизирует затраты. Hot — для частого доступа, Cool — для нечастого, а Archive — для долгосрочного, недорогого хранения. Политики жизненного цикла автоматизируют это.
Предотвратить одновременное изменение одного и того же BLOB-объекта несколькими процессами.
Реализуйте аренду BLOB-объектов. Процесс получает эксклюзивную блокировку на запись (аренду) BLOB-объекта перед его изменением.
Почему: Аренда обеспечивает пессимистический контроль параллелизма. После получения аренды ни один другой клиент не может записывать в BLOB-объект, пока аренда не будет освобождена или не истечет.
Хранить журналы аудита в хранилище BLOB-объектов и гарантировать, что они не могут быть изменены или удалены в течение фиксированного периода хранения (например, 7 лет).
Настройте политику хранения на основе времени для контейнера BLOB-объектов. Для бессрочного хранения используйте юридическое удержание.
Почему: Политики неизменяемого хранилища обеспечивают состояние WORM (однократная запись, многократное чтение), что важно для соответствия требованиям. После блокировки политика, основанная на времени, не может быть сокращена.
Требуется категоризировать BLOB-объекты с атрибутами ключ-значение и запрашивать их по всей учетной записи хранения без перечисления всех BLOB-объектов.
Используйте теги индекса BLOB-объектов.
Почему: Теги индекса индексируются службой хранения и могут использоваться в запросах фильтрации на стороне сервера (`Find Blobs by Tags`). Метаданные не индексируются и могут быть отфильтрованы только на стороне клиента после перечисления.
Безопасно аутентифицировать пользователей в одностраничном приложении (SPA) и получать токены для бэкенд-API.
Используйте поток кода авторизации с PKCE (Proof Key for Code Exchange).
Почему: Это текущая лучшая практика безопасности для общедоступных клиентов. Она позволяет избежать раскрытия токенов в URL (в отличие от устаревшего неявного потока) и не требует секрета клиента.
Фоновая служба или демон должен вызывать защищенный API (например, Microsoft Graph) без вошедшего пользователя.
Используйте поток Client Credentials с разрешениями приложения.
Почему: Этот поток аутентифицирует само приложение с использованием секрета клиента или сертификата. Разрешения приложения предоставляют доступ по всей организации, при условии согласия администратора.
Веб-API среднего уровня должен вызывать нижестоящий API, сохраняя при этом личность исходного вошедшего пользователя.
Реализуйте поток On-Behalf-Of (OBO).
Почему: API среднего уровня обменивает токен доступа пользователя на новый токен, ограниченный нижестоящим API. Это безопасно делегирует личность пользователя.
Приложение, использующее MSAL, должно эффективно получать токены, минимизируя запросы к пользователю.
Всегда сначала вызывайте `AcquireTokenSilent()`. Если он завершается сбоем с `MsalUiRequiredException`, переключитесь на интерактивный метод, такой как `AcquireTokenInteractive()`.
Почему: `AcquireTokenSilent()` проверяет кеш на наличие действительного токена или использует токен обновления для получения нового без взаимодействия с пользователем. Это критически важно для удобства пользователя.
Ресурс Azure (например, App Service, Function) должен получить доступ к другому ресурсу Azure (например, Key Vault, SQL Database) без хранения учетных данных в коде или конфигурации.
Включите управляемое удостоверение (системное или пользовательское) на исходном ресурсе и предоставьте ему разрешения RBAC на целевом ресурсе.
Почему: Управляемое удостоверение предоставляет идентификатор в Microsoft Entra ID для ресурса. Azure управляет жизненным циклом учетных данных, избавляя разработчиков от необходимости обрабатывать секреты.
Несколько ресурсов Azure должны совместно использовать одно и то же удостоверение и разрешения для доступа к другим службам.
Создайте одно управляемое удостоверение, назначенное пользователем, и назначьте его всем необходимым ресурсам.
Почему: Пользовательское удостоверение имеет жизненный цикл, независимый от любого ресурса, что делает его многоразовым. Системное удостоверение привязано к одному ресурсу и удаляется при удалении ресурса.
Требуется предоставить доступ к секретам Key Vault с использованием групп Azure AD с детализированными разрешениями на уровне отдельных секретов.
Используйте модель разрешений Azure RBAC для Key Vault. Назначьте роли, такие как `Key Vault Secrets User`, субъектам.
Почему: RBAC позволяет назначать роли на уровне хранилища или отдельных ключей/секретов/сертификатов, обеспечивая большую детализацию, чем политики доступа, которые применяются ко всем объектам определенного типа в хранилище.
Приложение должно получать изменения конфигурации из Azure App Configuration без перезапуска.
Используйте провайдер/SDK App Configuration и настройте его на обновление путем мониторинга ключа-метки.
Почему: SDK может периодически проверять ключ-метку на наличие изменений. При обновлении настроек приложения вы также обновляете ключ-метку, что запускает обновление конфигурации у всех клиентов.
Требуется включить новую функцию для определенной группы пользователей (например, бета-тестеров) и для процента общей аудитории.
Используйте флаг функции Azure App Configuration с фильтром Targeting.
Почему: Фильтр Targeting поддерживает сложные развертывания, позволяя определять аудитории на основе пользователей и групп с определенными процентами, а также процент развертывания по умолчанию для всех остальных.
Требуется сгенерировать безопасный, кратковременный токен для предоставления клиенту доступа к определенному BLOB-объекту.
Создайте SAS делегирования пользователя.
Почему: SAS делегирования пользователя подписывается учетными данными Microsoft Entra ID, а не ключом учетной записи хранения. Это более безопасно, так как позволяет избежать распространения ключа учетной записи, а доступ может быть отозван через политики Entra ID.
Устранить проблему производительности в микросервисном приложении, визуализируя зависимости и определяя, какая нижестоящая служба вызывает высокую задержку.
Используйте функцию карты приложений в Application Insights.
Почему: Карта приложений автоматически обнаруживает и отображает топологическое представление вашего распределенного приложения, показывая метрики работоспособности и производительности для каждого компонента и вызовы между ними.
Отследить один пользовательский запрос по мере его прохождения через несколько микросервисов.
Используйте представление сведений о сквозной транзакции в Application Insights. Вся телеметрия коррелируется по общему `operation_Id`.
Почему: SDK Application Insights автоматически распространяют заголовки W3C Trace Context, позволяя коррелировать всю телеметрию для одной операции с одним и тем же `operation_Id`, что обеспечивает единое представление.
Диагностировать производственную проблему: прерывистое медленное выполнение по сравнению с прерывистым исключением.
Для медленной производительности используйте Application Insights Profiler. Для исключений используйте Snapshot Debugger.
Почему: Profiler фиксирует трассировки времени на уровне методов для медленных запросов ("горячие пути"). Snapshot Debugger фиксирует стек вызовов и локальные переменные в момент возникновения исключения.
Сократить объем данных и стоимость Application Insights для высоконагруженного приложения, сохраняя при этом статистически достоверные данные.
Включите адаптивную выборку в конфигурации SDK приложения.
Почему: Адаптивная выборка автоматически регулирует частоту выборки, чтобы оставаться в пределах целевого объема данных, выполняя более агрессивную выборку при высоком трафике и менее агрессивную при низком трафике, сохраняя важную телеметрию.
Непрерывно отслеживать доступность конечной точки веб-приложения из нескольких географических местоположений.
Настройте стандартный тест доступности (тест URL-пинга) в Application Insights.
Почему: Тесты доступности отправляют запросы к вашей конечной точке из центров обработки данных Azure по всему миру, обеспечивая проактивный мониторинг времени безотказной работы и отзывчивости, а также срабатывание оповещений при сбое.
Создать оповещение, которое срабатывает, когда метрика производительности (например, среднее время ответа) превышает определенный порог в течение заданного периода.
Создайте правило оповещения по метрике Azure Monitor. Укажите целевой ресурс и метрику, настройте статический порог, тип агрегации и период оценки. Свяжите с группой действий.
Почему: Оповещения по метрикам обеспечивают низколатентный, сохраняющий состояние мониторинг метрических данных почти в реальном времени, что идеально подходит для оповещений, основанных на производительности.
Контролировать использование API, ограничивая частоту вызовов (например, 100 вызовов/мин) по сравнению с общим количеством вызовов за более длительный период (например, 10 000 вызовов/месяц).
Используйте политику `rate-limit` для частоты вызовов. Используйте политику `quota` для общего объема вызовов.
Почему: `rate-limit` ограничивает кратковременные всплески и возвращает HTTP 429. `quota` устанавливает ограничение использования на более длительный срок (например, расчетный период) и возвращает HTTP 403 при превышении.
Кешировать ответы API в API Management для снижения нагрузки на бэкенд, при этом ключ кеша изменяется в зависимости от заголовка запроса.
Используйте политику `<cache-lookup vary-by-header="..." />` во входящем разделе и политику `<cache-store duration="..." />` в исходящем разделе.
Почему: Эта двухкомпонентная комбинация политик включает кэширование ответов. `cache-lookup` проверяет наличие кэшированного элемента, а `cache-store` сохраняет ответ. Атрибуты `vary-by` обеспечивают уникальные записи кеша для различных вариантов запросов.
Управление изменениями в API. Требуется внесение критического изменения по сравнению с некритическим изменением, которое необходимо протестировать.
Используйте Versions для критических изменений (например, /v1, /v2). Используйте Revisions для некритических изменений и безопасных, поэтапных развертываний.
Почему: Версионирование позволяет одновременно иметь несколько активных версий API. Редакции позволяют изменять API в автономном режиме, тестировать его, а затем делать его "текущей" редакцией без простоя.
Уведомить несколько независимых нижестоящих служб, когда событие происходит в службе Azure (например, создан BLOB-объект, создана группа ресурсов).
Используйте Azure Event Grid. Создайте системную тему для ресурса Azure и подписки на события для каждого нижестоящего обработчика.
Почему: Event Grid — это полностью управляемая служба pub/sub на основе push-уведомлений, которая отделяет издателей событий от подписчиков, позволяя создавать реактивные, событийно-ориентированные архитектуры.
Принимать большой объем телеметрии или данных о событиях (миллионы событий в секунду) со многих устройств.
Используйте Azure Event Hubs.
Почему: Event Hubs — это массово масштабируемая платформа потоковой передачи данных, разработанная для высокопроизводительного приема. Она использует модель разделенного потребителя для параллельной обработки.
Обеспечить, чтобы события из одного и того же источника (например, определенного устройства IoT) обрабатывались в порядке одним и тем же потребителем.
Отправляйте события в Event Hubs с ключом раздела, установленным на идентификатор источника (например, ID устройства).
Почему: Event Hubs маршрутизирует все сообщения с одним и тем же ключом раздела в один и тот же раздел. Внутри раздела порядок сообщений сохраняется.
Обработать последовательность связанных сообщений в строгом порядке First-In, First-Out (FIFO).
Используйте сеансы Azure Service Bus. Отправляйте все связанные сообщения с одним и тем же `SessionId`.
Почему: Сеансы предоставляют параллельный, упорядоченный поток сообщений. Приемник, поддерживающий сеансы, блокирует сеанс, гарантируя, что сообщения обрабатываются последовательно одним потребителем.
Один издатель отправляет сообщения в тему, но несколько подписчиков хотят получать только подмножество этих сообщений на основе их свойств.
Используйте тему Service Bus с несколькими подписками. Примените SQL-фильтры или фильтры корреляции к каждой подписке.
Почему: Это канонический шаблон publish-subscribe с маршрутизацией на основе контента. Каждая подписка получает копию сообщения, если оно соответствует ее правилу фильтрации.
Сообщение не может быть успешно обработано после нескольких попыток и должно быть отложено для последующей проверки.
Позвольте сообщению завершиться неудачей обработки, пока не будет превышено максимальное количество доставок. Оно будет автоматически перемещено в очередь недоставленных сообщений (DLQ).
Почему: DLQ — это встроенная подочередь для "ядовитых" сообщений. Это предотвращает блокировку основной очереди ошибочным сообщением и позволяет выполнять автономный анализ и повторную обработку.
Выбрать службу обмена сообщениями для: корпоративных команд, реактивных событий или телеметрии большого объема.
Service Bus для команд (заказы, транзакции). Event Grid для реактивных событий (создан BLOB-объект, изменен ресурс). Event Hubs для телеметрии (данные IoT, потоки кликов).
Почему: Service Bus предлагает богатые функции, такие как упорядочивание, транзакции и отложенные сообщения. Event Grid предназначен для легковесной маршрутизации событий на основе push-уведомлений. Event Hubs предназначен для высокопроизводительной потоковой передачи данных.
