Как бы вы структурировали enterprise-scale landing zone Azure для 80 подписок в 6 бизнес-подразделениях, если production и регулируемые нагрузки требуют раздельных контролей?

Я бы строил иерархию management groups вокруг устойчивых границ governance, а не структуры подчинения компании. - Под корневой группой tenant разместил бы Platform, Landing Zones, Sandbox и Decommissioned, чтобы контроли жизненного цикла наследовались предсказуемо. - Разделил бы Landing Zones на Corp, Online и Regulated, а затем отделил production от nonproduction там, где политики должны различаться. - Назначал бы подписку только в одну ветвь через автоматизацию и не размещал бы рабочие нагрузки в корне tenant или ветке Platform. - Каждое изменение иерархии или наследуемых политик сначала проверял бы на 2 canary-подписках, а затем распространял на все 80.

Какие платформенные подписки вы бы создали для landing zone из 80 подписок, если обязанности сетевых администраторов и специалистов безопасности должны быть разделены, а SLO платформы равен 99,95%?

Я бы изолировал connectivity, management, identity и security в отдельных платформенных подписках. - Connectivity владеет региональными hub-сетями, ExpressRoute, Private DNS Resolver, Azure Firewall и DDoS-планами без доступа к рабочим нагрузкам. - Management владеет workspace Azure Monitor, Automation, governance резервного копирования и общими операционными инструментами для SLO 99,95%. - Identity содержит только зависящие от идентификации сервисы, например контроллеры домена, если они нужны, а Entra остаётся на уровне tenant. - Security владеет администрированием Sentinel и Defender, причём PIM-роли отделены от сетевой команды и владельцев нагрузок.

Как бы вы спроектировали инициативы Azure Policy для 80 подписок, если за 24 часа требуется достичь 95% compliance, а production-исключения могут действовать не более 30 дней?

Я бы публиковал версионированные инициативы на уровне management groups, а каждое исключение делал явным и ограниченным по сроку. - Разделил бы базовые контроли безопасности, диагностики, регионов, тегов и сетей, чтобы у каждой инициативы был один владелец и цикл релизов. - Deny применял бы только для проверенных инвариантов, новые контроли начинал бы с Audit, а DeployIfNotExists запускал бы с managed identity для remediation. - В exemption фиксировал бы владельца, обоснование, scope ресурсов и срок не более 30 дней вместо копирования assignments. - Отслеживал бы compliance через Policy Insights и создавал remediation tasks, пока каждая ветвь не достигнет 95% за 24 часа.

Как бы вы управляли доступом Entra ID и PIM для 2 000 сотрудников, администрирующих 80 подписок, если привилегированная активация ограничена 1 часом?

Я бы выдавал доступ к Azure через группы Entra, а привилегированные роли делал eligible через PIM вместо постоянной активации. - Сопоставил бы рабочие функции с группами Reader, Contributor, Network Operator и узкими custom roles, исключив прямые назначения пользователям. - Для Owner, User Access Administrator и платформенных ролей требовал бы phishing-resistant MFA, approval, номер заявки и активацию на 1 час. - Оставил бы 2 облачные break-glass учётные записи вне Conditional Access, защитил аппаратными ключами и проверял ежеквартально. - Ежеквартально проводил бы access review и оповещал о постоянных привилегиях, изменениях ролей и активациях вне разрешённого времени.

Восемь продуктовых групп запрашивают 20 подписок Azure в месяц, и каждая должна быть готова за 30 минут; как бы вы построили subscription vending?

Я бы предоставил валидируемый контракт запроса поверх идемпотентного workflow создания подписок. - До создания собирал бы группу владельцев, billing scope, management group, окружение, класс данных, регион, адресное пространство и месячный бюджет. - Создавал бы подписку через subscription alias, перемещал в целевую management group и ждал применения унаследованных Policy. - Из одного версионированного релиза разворачивал бы RBAC, бюджеты, диагностику, Defender, сеть и регистрацию resource providers. - Измерял бы p95 от запроса до готовности относительно 30 минут и сверялся по request ID, чтобы retry не создавал дубликаты.

Новой платформе нужны 12 000 региональных vCPU и 6 resource providers в 15 подписках через 6 недель; как бы вы управляли регистрацией провайдеров, квотами и ёмкостью?

Я бы управлял регистрацией providers, квотами, коммерческими reservations и физической ёмкостью как независимыми контролями. - Выдал бы vending identity право RBAC providers/register/action только в нужных scopes; Azure Policy не блокирует регистрацию namespace, но может запретить последующие типы или конфигурации ресурсов. - Инвентаризировал бы региональные квоты vCPU, public IP, gateway, AKS и сервисов во всех 15 подписках, затем запросил повышения минимум за 4 недели. - Создал бы On-demand Capacity Reservations для нужных семейств VM и зон, поскольку они покрывают ёмкость, а Azure Reservations снижают стоимость подходящего usage, но не резервируют ёмкость. - Отрепетировал бы деплой в масштабе 12 000 vCPU и отдельно проверил provider state, квоту и возможность деплоя в основном и резервном регионах.

Выбрали бы вы hub-spoke или Azure Virtual WAN для 200 VNet в 4 регионах и 25 филиалов, если 3 сетевым командам нужна единая политика сегментации?

Я бы выбрал secured Virtual WAN, потому что при таком количестве филиалов и VNet управляемая глобальная маршрутизация ценнее ручного контроля hub-сетей. - Создал бы по одному secured virtual hub в регионе и разделил production, nonproduction, shared services и регулируемый трафик route tables. - Подключил бы 25 филиалов по VPN или ExpressRoute и направлял private и интернет-трафик через Azure Firewall с помощью routing intent. - Управлял бы связностью через Virtual WAN и Azure Virtual Network Manager вместо сотен двусторонних peerings. - Hub-spoke сохранил бы для 2 регионов и менее 40 VNet, когда выбор appliances и контроль маршрутов важнее простоты эксплуатации.

Как бы вы подключили 2 ЦОД к Azure через 2 независимых канала ExpressRoute по 10 Гбит/с, с резервным VPN и переключением быстрее 90 секунд?

Я бы устранил общие физические и маршрутные зависимости двух путей ExpressRoute, а VPN оставил бы менее предпочтительным маршрутом. - Завершил бы каналы в разных peering locations и на разных клиентских маршрутизаторах, используя zone-redundant ExpressRoute gateways. - Анонсировал бы агрегированные префиксы по BGP и явно настроил предпочтения, чтобы stateful inspection не получал асимметричные потоки. - Построил бы active-active VPN gateways через 2 интернет-провайдеров и анонсировал те же префиксы с меньшим приоритетом BGP. - Ежеквартально отключал бы каждый канал, peering site, маршрутизатор и gateway, измеряя сходимость относительно 90 секунд.

Как бы вы спроектировали private DNS для 200 VNet, 40 зон Private Link и 2 on-premises доменов, если изменения записей должны разрешаться за 5 минут?

Я бы централизовал гибридный DNS через Azure DNS Private Resolver, сохранив private zones под единым управлением. - Развернул бы inbound и outbound endpoints в выделенных подсетях каждого нужного региона и связал forwarding rulesets с разрешёнными VNet; Private Resolver имеет встроенную zone redundancy, поэтому endpoints вручную по 2 availability zones не распределяются. - Outbound пересылал бы только 2 on-premises suffix, а в ЦОД настроил conditional forwarders для private namespaces Azure. - Связывал бы каждую из 40 Private DNS zones через автоматизацию, не допуская дублирующих зон с одинаковыми именами. - Настроил бы TTL и проверки деплоя под 5 минут, затем мониторил ошибки запросов, NXDOMAIN и циклы forwarding.

Сорок подписок используют 25 PaaS-сервисов через Private Link, а число публичных endpoints должно быть равно нулю; как бы вы стандартизировали связность и DNS?

Я бы включил private endpoints и их DNS-записи в контракт деплоя сервиса, а публичный доступ запретил. - Создавал бы endpoints в выделенных spoke-подсетях с адресным запасом на 25 сервисов и применял минимальные NSG-правила там, где включены network policies. - Использовал бы private DNS zone groups, чтобы endpoint автоматически регистрировал записи в централизованных зонах без ручных A records. - Разрешал бы зоны через Private DNS Resolver для клиентов Azure и ЦОД, проверяя нужные subresources каждого сервиса. - Через Policy запрещал бы public network access и проверял orphaned endpoints, устаревшие DNS-записи и неразрешённые approvals между подписками.

Как бы вы организовали централизованный интернет-egress для 80 подписок в 3 регионах с пиком 20 Гбит/с и без public IP в workload spokes?

Я бы развернул региональный secured hub с Azure Firewall Premium, чтобы egress оставался региональным и инспектируемым. - Направлял бы default route spokes через локальный firewall посредством routing intent или UDR и управлял иерархическими правилами через Azure Firewall Manager. - Включил бы DNS proxy, TLS inspection только для разрешённых категорий и threat-intelligence blocking с документированными исключениями. - Использовал бы несколько public IP или связку с NAT Gateway там, где она поддерживается, чтобы хватило SNAT-портов сверх нагрузки 20 Гбит/с. - Запретил бы public IP и неразрешённые route tables через Policy, затем следил за throughput, SNAT и маршрутами обхода.

Спроектируйте Azure Front Door для API с 30 000 запросов в секунду в 3 регионах, SLA 99,99%, RTO 5 минут и без публичных origins; что вы развернёте?

Я бы использовал Front Door Premium с active-active origins, доступными через Private Link. - Разместил бы региональные API за internal origins, одобрил Private Link и отклонял трафик, обходящий Front Door. - Настроил бы latency routing, health probes с проверкой зависимостей и ёмкость каждого региона для 30 000 запросов в секунду при потере другого региона. - Применил бы WAF managed rules, rate limits, bot controls и ротацию сертификатов на edge без кеширования чувствительных API-ответов. - Вынес бы сессии и данные из compute, а отключение регионального origin проверял бы ежеквартально относительно RTO 5 минут и SLA 99,99%.

Как бы вы выбирали между VMs, App Service, Container Apps, AKS и Functions для 30 сервисов с нагрузкой от 100 до 10 000 запросов в секунду и SLA 99,95%?

Я бы распределял нагрузки по ограничениям выполнения, а самым простым управляемым сервисом сделал бы вариант по умолчанию. - Functions использовал бы для коротких event handlers, а Container Apps для bursty-контейнеров с KEDA scaling, которым не нужны Kubernetes APIs. - App Service выбрал бы для обычных web API со slots и управляемым runtime, а VMs для требований к kernel, appliances или лицензиям. - AKS применял бы только тогда, когда нескольким командам нужны scheduling Kubernetes, controllers, network policy или общая контейнерная платформа. - Перед стандартизацией сравнил бы p99, cold start, пределы scaling, штат и месячную стоимость при 10 000 запросов в секунду.

Лицензированному vendor-приложению нужны драйверы ядра Windows, 64 vCPU на узел и доступность 99,95% в 2 зонах; как бы вы спроектировали платформу Azure VM?

Я бы использовал Virtual Machine Scale Set в нескольких зонах на основе неизменяемого протестированного образа. - Собирал бы Windows-образ через Azure VM Image Builder, фиксировал версию vendor и сканировал перед репликацией в Shared Image Gallery. - Распределил бы минимум 2 инстанса по зонам за Standard Load Balancer или Application Gateway и зарезервировал бы ёмкость SKU на 64 vCPU. - Применял бы Azure Update Manager поэтапно, а данные приложения вынес бы в managed service или на поддерживаемые vendor реплицируемые disks. - Масштабировал бы только в пределах лицензии и проверял потерю зоны и откат образа относительно требования 99,95%.

Пятнадцати .NET API нужны private ingress, откат деплоя быстрее 10 минут и SLA 99,95%; как бы вы спроектировали платформу Azure App Service?

Я бы использовал zone-redundant Premium plans с private endpoints, VNet integration и deployment slots. - Объединял бы API только при одинаковом профиле scaling и blast radius, а критичные сервисы держал бы на отдельных plans минимум по 3 инстанса. - Направлял бы inbound через Application Gateway или Front Door к private endpoints, а outbound через VNet integration. - Прогревал бы staging slot, проверял зависимости и выполнял swap, сохраняя предыдущий slot для отката быстрее 10 минут. - Использовал бы managed identities, Key Vault references, autoscale rules и отдельную telemetry приложения вместо общих секретов и ручной конфигурации.

Двадцать event-driven нагрузок работают от 200-миллисекундных handlers до 45-минутных jobs и дают всплеск в 30 раз; где вы примените Functions, а где Azure Container Apps?

Я бы использовал Functions для коротких event handlers, а Container Apps jobs или services для долгих контейнерных задач. - 200-миллисекундные handlers разместил бы в Functions с event triggers, идемпотентностью и hosting plan по измеренному cold start. - 45-минутную работу запускал бы как Container Apps jobs с явными CPU, memory, retry, timeout и parallelism. - Масштабировал бы через KEDA по глубине Service Bus, ограничивая replicas, чтобы всплеск в 30 раз не исчерпал базы данных. - Отделил бы poison messages, передавал correlation IDs и сравнил стоимость простоя и всплеска перед выбором Consumption или dedicated capacity.

Как бы вы спроектировали multi-tenancy AKS для 12 команд и 80 сервисов, если регулируемым нагрузкам нужна жёсткая изоляция, а SLA платформы равен 99,95%?

Я бы отделил security isolation от availability: общие кластеры подходят для мягкой multi-tenancy, а регулируемые trust boundaries получают отдельные кластеры или подписки. - Каждой команде дал бы namespaces с ResourceQuota, LimitRange, network policy, Pod Security admission и RBAC через Entra. - Для каждого service account использовал бы Azure Workload Identity, чтобы 80 сервисов не делили cluster или cloud credentials. - Production-кластеры запускал бы на поддерживаемом Standard или Premium tier, распределяя system и user node pools по availability zones с запасом на потерю зоны. - Для каждого сервиса настроил бы несколько replicas, topology spread, PodDisruptionBudgets и проверенный failover зависимостей; 2 кластера снижают blast radius, но сами по себе не доказывают SLA workload 99,95%.

AKS estate запускает 600 pods, имеет 70% переменной нагрузки, разрешает Spot только для retryable-задач и допускает service mesh при p99 overhead ниже 10 мс; как бы вы его спроектировали?

Я бы разделил стабильную, burst и Spot-ёмкость по node pools, а mesh проверил бы репрезентативным нагрузочным тестом. - Использовал бы cluster autoscaler или node auto-provisioning вместе с pod requests, topology spread и disruption budgets, сохраняющими критичные replicas. - Пометил бы Spot pools через taints и запускал там только checkpointed retryable jobs с обычными nodes на случай Azure eviction. - Подключил бы AKS Istio add-on только ради нужных mTLS и traffic policy, измерив CPU, memory и p99 относительно 10 мс. - Ограничения scaling вывел бы из IP подсети, региональной vCPU quota, ёмкости базы и колебания 70%, а не только CPU.

Как бы вы предоставили golden paths и безопасные деплои для 12 команд, выпускающих 80 AKS-сервисов 20 раз в день с откатом быстрее 10 минут?

Я бы опубликовал версионированный шаблон сервиса и сделал progressive delivery стандартным путём, а не выбором каждой команды. - Шаблон создавал бы workload identity, probes, resource requests, telemetry, policy checks, dashboards и pipeline Azure DevOps или GitHub. - Собирал бы образ один раз, подписывал в ACR, продвигал digest по окружениям и синхронизировал deployments через Flux. - Выпускал бы canary по шагам 5%, 25% и 50% или blue-green для несовместимых изменений с gates по error rate и p99. - Хранил бы предыдущий manifest и image digest готовыми к деплою, чтобы automated abort восстанавливал сервис быстрее 10 минут.

Как бы вы спроектировали failover groups Azure SQL для сервиса на 5 000 TPS с SLA 99,99%, RTO меньше 5 минут и RPO меньше 30 секунд?

Я бы оспорил RPO, потому что failover group Azure SQL сама по себе не гарантирует потерю данных меньше 30 секунд. - Включил бы zone redundancy для primary и secondary databases или elastic pools, а не для logical servers, и рассчитал обе стороны на 5 000 TPS. - Считал бы geo-replication асинхронной: пересогласовал жёсткий RPO или добавил и проверил синхронный бизнес-слой с idempotency, ordering и write fencing. - Использовал бы read-write listener для записи, ограничил read-only listener чтениями, допускающими отставание, и отслеживал replication lag и здоровье зависимостей. - Использовал бы monitored manual failover, потому что минимальный automatic grace period равен 1 часу, и ежеквартально проверял promotion против RTO 5 минут и согласованного RPO.

Вопросы на собеседовании: Azure-инженер

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior Azure-инженер.

Смотреть пример резюме: Azure-инженер →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

Я бы строил иерархию management groups вокруг устойчивых границ governance, а не структуры подчинения компании.

Под корневой группой tenant разместил бы Platform, Landing Zones, Sandbox и Decommissioned, чтобы контроли жизненного цикла наследовались предсказуемо.
Разделил бы Landing Zones на Corp, Online и Regulated, а затем отделил production от nonproduction там, где политики должны различаться.
Назначал бы подписку только в одну ветвь через автоматизацию и не размещал бы рабочие нагрузки в корне tenant или ветке Platform.
Каждое изменение иерархии или наследуемых политик сначала проверял бы на 2 canary-подписках, а затем распространял на все 80.

Зачем это спрашивают: Интервьюер оценивает понимание наследования management groups, границ подписок и контролируемых изменений в масштабе предприятия.

slo

Я бы изолировал connectivity, management, identity и security в отдельных платформенных подписках.

Connectivity владеет региональными hub-сетями, ExpressRoute, Private DNS Resolver, Azure Firewall и DDoS-планами без доступа к рабочим нагрузкам.
Management владеет workspace Azure Monitor, Automation, governance резервного копирования и общими операционными инструментами для SLO 99,95%.
Identity содержит только зависящие от идентификации сервисы, например контроллеры домена, если они нужны, а Entra остаётся на уровне tenant.
Security владеет администрированием Sentinel и Defender, причём PIM-роли отделены от сетевой команды и владельцев нагрузок.

Зачем это спрашивают: Интервьюер проверяет разделение общих сервисов и привилегированных обязанностей без лишних подписок.

designerror-handling

Я бы публиковал версионированные инициативы на уровне management groups, а каждое исключение делал явным и ограниченным по сроку.

Разделил бы базовые контроли безопасности, диагностики, регионов, тегов и сетей, чтобы у каждой инициативы был один владелец и цикл релизов.
Deny применял бы только для проверенных инвариантов, новые контроли начинал бы с Audit, а DeployIfNotExists запускал бы с managed identity для remediation.
В exemption фиксировал бы владельца, обоснование, scope ресурсов и срок не более 30 дней вместо копирования assignments.
Отслеживал бы compliance через Policy Insights и создавал remediation tasks, пока каждая ветвь не достигнет 95% за 24 часа.

Зачем это спрашивают: Интервьюер проверяет композицию политик, remediation, управление исключениями и измеримый compliance.

activation

Я бы выдавал доступ к Azure через группы Entra, а привилегированные роли делал eligible через PIM вместо постоянной активации.

Сопоставил бы рабочие функции с группами Reader, Contributor, Network Operator и узкими custom roles, исключив прямые назначения пользователям.
Для Owner, User Access Administrator и платформенных ролей требовал бы phishing-resistant MFA, approval, номер заявки и активацию на 1 час.
Оставил бы 2 облачные break-glass учётные записи вне Conditional Access, защитил аппаратными ключами и проверял ежеквартально.
Ежеквартально проводил бы access review и оповещал о постоянных привилегиях, изменениях ролей и активациях вне разрешённого времени.

Зачем это спрашивают: Интервьюер оценивает масштабируемую авторизацию, just-in-time привилегии и контролируемый аварийный доступ.

Я бы предоставил валидируемый контракт запроса поверх идемпотентного workflow создания подписок.

До создания собирал бы группу владельцев, billing scope, management group, окружение, класс данных, регион, адресное пространство и месячный бюджет.
Создавал бы подписку через subscription alias, перемещал в целевую management group и ждал применения унаследованных Policy.
Из одного версионированного релиза разворачивал бы RBAC, бюджеты, диагностику, Defender, сеть и регистрацию resource providers.
Измерял бы p95 от запроса до готовности относительно 30 минут и сверялся по request ID, чтобы retry не создавал дубликаты.

Зачем это спрашивают: Интервьюер ожидает конкретную self-service фабрику с биллингом, governance, сетью и безопасными повторами.

capacity

Я бы управлял регистрацией providers, квотами, коммерческими reservations и физической ёмкостью как независимыми контролями.

Выдал бы vending identity право RBAC providers/register/action только в нужных scopes; Azure Policy не блокирует регистрацию namespace, но может запретить последующие типы или конфигурации ресурсов.
Инвентаризировал бы региональные квоты vCPU, public IP, gateway, AKS и сервисов во всех 15 подписках, затем запросил повышения минимум за 4 недели.
Создал бы On-demand Capacity Reservations для нужных семейств VM и зон, поскольку они покрывают ёмкость, а Azure Reservations снижают стоимость подходящего usage, но не резервируют ёмкость.
Отрепетировал бы деплой в масштабе 12 000 vCPU и отдельно проверил provider state, квоту и возможность деплоя в основном и резервном регионах.

Зачем это спрашивают: Интервьюер проверяет регистрацию providers через RBAC, реальную границу Azure Policy, квоты, скидки и обеспечение ёмкости.

Я бы выбрал secured Virtual WAN, потому что при таком количестве филиалов и VNet управляемая глобальная маршрутизация ценнее ручного контроля hub-сетей.

Создал бы по одному secured virtual hub в регионе и разделил production, nonproduction, shared services и регулируемый трафик route tables.
Подключил бы 25 филиалов по VPN или ExpressRoute и направлял private и интернет-трафик через Azure Firewall с помощью routing intent.
Управлял бы связностью через Virtual WAN и Azure Virtual Network Manager вместо сотен двусторонних peerings.
Hub-spoke сохранил бы для 2 регионов и менее 40 VNet, когда выбор appliances и контроль маршрутов важнее простоты эксплуатации.

Зачем это спрашивают: Интервьюер оценивает соответствие топологии масштабу сети, филиальной связности и операционной модели.

hybrid-networking

Я бы устранил общие физические и маршрутные зависимости двух путей ExpressRoute, а VPN оставил бы менее предпочтительным маршрутом.

Завершил бы каналы в разных peering locations и на разных клиентских маршрутизаторах, используя zone-redundant ExpressRoute gateways.
Анонсировал бы агрегированные префиксы по BGP и явно настроил предпочтения, чтобы stateful inspection не получал асимметричные потоки.
Построил бы active-active VPN gateways через 2 интернет-провайдеров и анонсировал те же префиксы с меньшим приоритетом BGP.
Ежеквартально отключал бы каждый канал, peering site, маршрутизатор и gateway, измеряя сходимость относительно 90 секунд.

Зачем это спрашивают: Интервьюер проверяет физическое резервирование, поведение BGP, устойчивость gateways и измеримый fallback.

designdnsprivate-connectivity

Я бы централизовал гибридный DNS через Azure DNS Private Resolver, сохранив private zones под единым управлением.

Развернул бы inbound и outbound endpoints в выделенных подсетях каждого нужного региона и связал forwarding rulesets с разрешёнными VNet; Private Resolver имеет встроенную zone redundancy, поэтому endpoints вручную по 2 availability zones не распределяются.
Outbound пересылал бы только 2 on-premises suffix, а в ЦОД настроил conditional forwarders для private namespaces Azure.
Связывал бы каждую из 40 Private DNS zones через автоматизацию, не допуская дублирующих зон с одинаковыми именами.
Настроил бы TTL и проверки деплоя под 5 минут, затем мониторил ошибки запросов, NXDOMAIN и циклы forwarding.

Зачем это спрашивают: Интервьюер проверяет направления гибридного DNS, встроенную отказоустойчивость resolver, владение зонами, VNet links и ограничения распространения.

dnsprivate-connectivitycloud

Я бы включил private endpoints и их DNS-записи в контракт деплоя сервиса, а публичный доступ запретил.

Создавал бы endpoints в выделенных spoke-подсетях с адресным запасом на 25 сервисов и применял минимальные NSG-правила там, где включены network policies.
Использовал бы private DNS zone groups, чтобы endpoint автоматически регистрировал записи в централизованных зонах без ручных A records.
Разрешал бы зоны через Private DNS Resolver для клиентов Azure и ЦОД, проверяя нужные subresources каждого сервиса.
Через Policy запрещал бы public network access и проверял orphaned endpoints, устаревшие DNS-записи и неразрешённые approvals между подписками.

Зачем это спрашивают: Интервьюер оценивает жизненный цикл Private Link, интеграцию DNS и соблюдение запрета на публичные endpoints.

Я бы развернул региональный secured hub с Azure Firewall Premium, чтобы egress оставался региональным и инспектируемым.

Направлял бы default route spokes через локальный firewall посредством routing intent или UDR и управлял иерархическими правилами через Azure Firewall Manager.
Включил бы DNS proxy, TLS inspection только для разрешённых категорий и threat-intelligence blocking с документированными исключениями.
Использовал бы несколько public IP или связку с NAT Gateway там, где она поддерживается, чтобы хватило SNAT-портов сверх нагрузки 20 Гбит/с.
Запретил бы public IP и неразрешённые route tables через Policy, затем следил за throughput, SNAT и маршрутами обхода.

Зачем это спрашивают: Интервьюер проверяет региональную автономность, централизованные правила, ёмкость SNAT и предотвращение обходного egress.

designedge-routingapi

Я бы использовал Front Door Premium с active-active origins, доступными через Private Link.

Разместил бы региональные API за internal origins, одобрил Private Link и отклонял трафик, обходящий Front Door.
Настроил бы latency routing, health probes с проверкой зависимостей и ёмкость каждого региона для 30 000 запросов в секунду при потере другого региона.
Применил бы WAF managed rules, rate limits, bot controls и ротацию сертификатов на edge без кеширования чувствительных API-ответов.
Вынес бы сессии и данные из compute, а отключение регионального origin проверял бы ежеквартально относительно RTO 5 минут и SLA 99,99%.

Зачем это спрашивают: Интервьюер оценивает edge routing, private origins, региональную ёмкость, безопасность и проверенное восстановление.

containerskuberneteszero-to-one

Я бы распределял нагрузки по ограничениям выполнения, а самым простым управляемым сервисом сделал бы вариант по умолчанию.

Functions использовал бы для коротких event handlers, а Container Apps для bursty-контейнеров с KEDA scaling, которым не нужны Kubernetes APIs.
App Service выбрал бы для обычных web API со slots и управляемым runtime, а VMs для требований к kernel, appliances или лицензиям.
AKS применял бы только тогда, когда нескольким командам нужны scheduling Kubernetes, controllers, network policy или общая контейнерная платформа.
Перед стандартизацией сравнил бы p99, cold start, пределы scaling, штат и месячную стоимость при 10 000 запросов в секунду.

Зачем это спрашивают: Интервьюер проверяет выбор compute по ограничениям нагрузки, а не по одной любимой платформе.

procurementdesign

Я бы использовал Virtual Machine Scale Set в нескольких зонах на основе неизменяемого протестированного образа.

Собирал бы Windows-образ через Azure VM Image Builder, фиксировал версию vendor и сканировал перед репликацией в Shared Image Gallery.
Распределил бы минимум 2 инстанса по зонам за Standard Load Balancer или Application Gateway и зарезервировал бы ёмкость SKU на 64 vCPU.
Применял бы Azure Update Manager поэтапно, а данные приложения вынес бы в managed service или на поддерживаемые vendor реплицируемые disks.
Масштабировал бы только в пределах лицензии и проверял потерю зоны и откат образа относительно требования 99,95%.

Зачем это спрашивают: Интервьюер оценивает оправданность VMs и управление образами, зонами, лицензированием и обновлениями.

deploymentrollbackkubernetes

Я бы использовал zone-redundant Premium plans с private endpoints, VNet integration и deployment slots.

Объединял бы API только при одинаковом профиле scaling и blast radius, а критичные сервисы держал бы на отдельных plans минимум по 3 инстанса.
Направлял бы inbound через Application Gateway или Front Door к private endpoints, а outbound через VNet integration.
Прогревал бы staging slot, проверял зависимости и выполнял swap, сохраняя предыдущий slot для отката быстрее 10 минут.
Использовал бы managed identities, Key Vault references, autoscale rules и отдельную telemetry приложения вместо общих секретов и ручной конфигурации.

Зачем это спрашивают: Интервьюер проверяет изоляцию App Service, private networking, delivery через slots и проектирование отката.

eventscontainers

Я бы использовал Functions для коротких event handlers, а Container Apps jobs или services для долгих контейнерных задач.

200-миллисекундные handlers разместил бы в Functions с event triggers, идемпотентностью и hosting plan по измеренному cold start.
45-минутную работу запускал бы как Container Apps jobs с явными CPU, memory, retry, timeout и parallelism.
Масштабировал бы через KEDA по глубине Service Bus, ограничивая replicas, чтобы всплеск в 30 раз не исчерпал базы данных.
Отделил бы poison messages, передавал correlation IDs и сравнил стоимость простоя и всплеска перед выбором Consumption или dedicated capacity.

Зачем это спрашивают: Интервьюер оценивает ограничения длительности, scaling, защиту downstream-систем и стоимость serverless-вариантов.

designkubernetes

Я бы отделил security isolation от availability: общие кластеры подходят для мягкой multi-tenancy, а регулируемые trust boundaries получают отдельные кластеры или подписки.

Каждой команде дал бы namespaces с ResourceQuota, LimitRange, network policy, Pod Security admission и RBAC через Entra.
Для каждого service account использовал бы Azure Workload Identity, чтобы 80 сервисов не делили cluster или cloud credentials.
Production-кластеры запускал бы на поддерживаемом Standard или Premium tier, распределяя system и user node pools по availability zones с запасом на потерю зоны.
Для каждого сервиса настроил бы несколько replicas, topology spread, PodDisruptionBudgets и проверенный failover зависимостей; 2 кластера снижают blast radius, но сами по себе не доказывают SLA workload 99,95%.

Зачем это спрашивают: Интервьюер проверяет security isolation, выбор поддерживаемого AKS tier, зональный дизайн nodes и availability на уровне workloads.

designresilienceservice-mesh

Я бы разделил стабильную, burst и Spot-ёмкость по node pools, а mesh проверил бы репрезентативным нагрузочным тестом.

Использовал бы cluster autoscaler или node auto-provisioning вместе с pod requests, topology spread и disruption budgets, сохраняющими критичные replicas.
Пометил бы Spot pools через taints и запускал там только checkpointed retryable jobs с обычными nodes на случай Azure eviction.
Подключил бы AKS Istio add-on только ради нужных mTLS и traffic policy, измерив CPU, memory и p99 относительно 10 мс.
Ограничения scaling вывел бы из IP подсети, региональной vCPU quota, ёмкости базы и колебания 70%, а не только CPU.

Зачем это спрашивают: Интервьюер оценивает границы autoscaling, безопасность Spot eviction и обоснованное внедрение service mesh.

deploymentrollbackkubernetes

Я бы опубликовал версионированный шаблон сервиса и сделал progressive delivery стандартным путём, а не выбором каждой команды.

Шаблон создавал бы workload identity, probes, resource requests, telemetry, policy checks, dashboards и pipeline Azure DevOps или GitHub.
Собирал бы образ один раз, подписывал в ACR, продвигал digest по окружениям и синхронизировал deployments через Flux.
Выпускал бы canary по шагам 5%, 25% и 50% или blue-green для несовместимых изменений с gates по error rate и p99.
Хранил бы предыдущий manifest и image digest готовыми к деплою, чтобы automated abort восстанавливал сервис быстрее 10 минут.

Зачем это спрашивают: Интервьюер проверяет, улучшают ли платформенные стандарты delivery без потери измеримой безопасности отката.

sqldesign

Я бы оспорил RPO, потому что failover group Azure SQL сама по себе не гарантирует потерю данных меньше 30 секунд.

Включил бы zone redundancy для primary и secondary databases или elastic pools, а не для logical servers, и рассчитал обе стороны на 5 000 TPS.
Считал бы geo-replication асинхронной: пересогласовал жёсткий RPO или добавил и проверил синхронный бизнес-слой с idempotency, ordering и write fencing.
Использовал бы read-write listener для записи, ограничил read-only listener чтениями, допускающими отставание, и отслеживал replication lag и здоровье зависимостей.
Использовал бы monitored manual failover, потому что минимальный automatic grace period равен 1 часу, и ежеквартально проверял promotion против RTO 5 минут и согласованного RPO.

Зачем это спрашивают: Интервьюер оценивает ограничения RPO при асинхронной репликации, zone redundancy на уровне databases, работу listeners и реалистичный контракт ручного failover.

Закрытые вопросы

21
SaaS-платформа содержит 40 tenant databases Azure SQL, требует скоординированного регионального восстановления за 20 минут и допускает потерю 2 минут данных; как бы вы организовали failover?
sqldatabasecloud
22
Какую модель consistency Azure Cosmos DB вы выберете для 20 000 запросов в секунду в 3 регионах, если чтение профиля может отставать на 5 секунд, а чтение баланса не может быть stale?
cosmos-dbconsistency
23
Cosmos DB account в 3 регионах принимает multi-region writes для 10 000 заказов в секунду, а конфликты должны разрешаться за 60 секунд без потери updates; какую стратегию вы выберете?
cosmos-db
24
Как бы вы обрабатывали change feed Cosmos DB с 50 миллионами изменений в день, если дубликаты допустимы, но ни одно бизнес-событие не должно теряться более чем на 15 минут?
cosmos-dbconcurrency
25
Регулируемый архив хранит 100 ТБ blobs 7 лет, требует WORM retention и второй регион Azure с RPO меньше 15 минут; как бы вы его спроектировали?
designregionsretention
26
Как бы вы спроектировали Redis-кеширование на 100 000 операций в секунду с p99 меньше 5 мс и устареванием каталога не более 60 секунд?
redisdesigncaching
27
Workflow заказов создаёт 20 миллионов событий в день и должен сходиться между 6 сервисами за 2 минуты без распределённых транзакций; как бы вы спроектировали consistency?
distributeddesignconsistency
28
Как бы вы спроектировали Conditional Access и privileged access workstations для 2 000 пользователей и администраторов в 80 подписках Azure, включая risk-based authentication и 2 аварийные учётные записи?
authdesign
29
Триста Azure workloads должны обращаться к storage, SQL и Key Vault без client secrets, а лишние credentials нужно отзывать за 24 часа; как бы вы использовали managed identities?
secretssql
30
Платёжная платформа управляет 500 ключами, требует HSM с защитой FIPS, ротацию каждые 90 дней и восстановление удалённых ключей в течение 90 дней; выберете Key Vault Premium или Managed HSM?
secrets
31
Как бы вы объединили Defender for Cloud и Microsoft Sentinel для 80 подписок, создающих 2 ТБ security data в день, при месячном лимите ingestion $150 000?
32
Аудит требует 98% compliance Azure Policy по 80 подпискам за 30 дней, но 12 legacy-приложений несовместимы с 3 контролями; как бы вы закрыли gap?
33
Как бы вы хранили immutable Azure Activity и diagnostic logs 7 лет по 80 подпискам, сохраняя только 90 дней для поиска в Log Analytics?
immutability
34
Платформа поставляет 200 container images в 4 страны, требует подписанные artifacts и запрещает customer data или encryption keys покидать страну; как бы вы защитили supply chain и residency boundary?
encryptionsupply-chaincontainers
35
Стандартизировали бы вы Bicep, Terraform или ручные ARM templates для 80 подписок Azure и 12 команд, если 90% ресурсов Azure-native?
terraformiac
36
Как бы вы разделили workload Terraform state для 80 подписок и 30 concurrent pipelines, чтобы повреждение затронуло не больше 1 подписки, а shared management-group и Policy foundation state осталось отдельным исключением с большим blast radius?
terraformci-cdconcurrency
37
Как бы вы управляли Bicep registry с 40 modules для 12 команд, если критичные исправления должны попасть в production за 7 дней без поломки существующих deployments?
deploymentregistriesiac
38
Как бы вы реализовали policy as code для 60 Azure Policy definitions в 80 подписках, если каждое изменение требует 2 approvals и canary-период 14 дней?
deployment-strategies
39
В 80 подписках нужно обнаруживать infrastructure drift за 24 часа, но автоматическая коррекция не может перезапускать production resources; как бы вы находили и обрабатывали drift?
iac
40
Как бы вы выпустили изменение landing zone в 80 подписок за 10 волн, если rollback должен завершаться за 30 минут, а волна не может превышать 10 подписок?
rollback
41
Как бы вы определили и мониторили месячный availability SLO 99,95% для 25 Azure API, если error budget составляет около 21,6 минуты?
reliabilityslomonitoring
42
Как бы вы инструментировали 150 сервисов, создающих 100 000 spans в секунду, через OpenTelemetry и Azure Monitor при бюджете telemetry до $80 000 в месяц?
monitoringobservability
43
Сорока приложениям нужны 3 уровня disaster recovery с парами RTO/RPO 15 минут/1 минута, 4 часа/1 час и 24 часа/24 часа; как бы вы сопоставили Azure services и стоимость?
44
Как бы вы защитили backups 300 VMs и 80 ТБ данных от ransomware при retention 1 год и обязательном доказательстве восстановления каждые 90 дней?
retentionbackups
45
Двумстам on-premises VMs нужен Azure Site Recovery с RTO меньше 30 минут и RPO меньше 15 минут; как бы вы спроектировали и проверили recovery plan?
recoverydesign
46
Как бы вы провели Azure Well-Architected review платформы с расходами $2 миллиона в год, SLA 99,99% и 6 неделями на финансирование 10 главных улучшений?
47
Azure estate тратит $4 миллиона в год, а 65% compute usage стабильно; как бы вы выбирали reservations и Azure Savings Plan без лишних обязательств на 3 года?
48
Как бы вы распределили минимум 95% Azure cost между 80 подписками и 15 бизнес-подразделениями, если общие сетевые и security services дают 12% месячных расходов?
49
Нужно сократить месячный счёт Azure в $500 000 на 25% за 6 месяцев без снижения SLA 99,95%; какой конкретный FinOps-план вы выполните?
finops
50
Двенадцать команд спорят о стандарте Azure platform, затрагивающем 80 сервисов, а 8 инженеров должны подготовить RFC за 4 недели при лимите миграции $200 000; как бы вы повели решение?
conflictdecision-makingmigrations
51
Azure Front Door направляет 65% из 24 000 запросов в секунду в West Europe; 4 внешних пробника показывают 31% ошибок checkout в течение 8 минут после изменения WAF-политики, хотя health origin остаётся зелёным. Как вы локализуете инцидент и какие данные станут гейтом возврата трафика?
incidentsedge-routing
52
Ассоциация таблицы маршрутов Azure Virtual WAN пропустила 10.42.0.0/16 из development в 180 production VNet; flow logs Network Watcher показывают 16 000 отклонённых потоков, а 7 платёжных сервисов недоступны 11 минут. Что вы локализуете первым и что докажет безопасность маршрутов?
53
Канал ExpressRoute на 10 Гбит/с отказал 14 минут назад, и трафик перешёл на два site-to-site VPN по 2 Гбит/с, но packet capture показывает, что обратный трафик всё ещё предпочитает ExpressRoute, а 29% API-вызовов истекают по таймауту при 3,6 Гбит/с. Что вы измените и какой гейт не допустит асимметрию при восстановлении?
hybrid-networkingapi
54
Azure NAT Gateway обслуживает 52 000 одновременных исходящих соединений; ошибки SNAT достигают 8 600 в минуту, а TLS-ошибки партнёра 26%, при этом flow logs указывают на crawler, открывающий 45 соединений в секунду на реплику. Как вы локализуете проблему и зададите гейт восстановления?
gatewaynetworkingreplication
55
Application Gateway v2 возвращает 502 для 18% из 42 000 запросов в секунду после релиза backend; access logs показывают ERRORINFO_UPSTREAM_CONNECTION_RESET, UnhealthyHostCount вырос с 2 до 94, а CPU backend равен 61%. Вы масштабируете, откатываете или меняете gateway, и что станет гейтом восстановления?
gatewayload-balancingrollback
56
После обновления ruleset Azure Private DNS Resolver 68 VNet не могут разрешить corp.internal в течение 12 минут; DNS query logs показывают 84% SERVFAIL, оба outbound endpoint созданы, а on-premises DNS отвечает на прямые запросы за 14 мс. Что вы откатите и что докажет восстановление?
queriesdnsendpoints
57
Private Endpoint хранилища заменили 20 минут назад; 140 потребителей всё ещё разрешают старый приватный IP, 38 новых подключений ожидают одобрения, а логи приложения показывают 33% TCP timeout. Что вы восстановите и как зададите гейт миграции Private Link?
resiliencenetworkingprivate-connectivity
58
Изменение origin в Front Door направляло 88 ТБ в день регулируемого трафика ЕС через East US в течение 29 минут; flow logs показывают 34 Гбит/с через границу резидентности. Как вы локализуете нарушение, сохраните production-доказательства и зададите гейт соответствующего требованиям восстановления?
edge-routing
59
Rolling upgrade VM Scale Set установил плохой образ на 170 из 240 инстансов одновременно с вытеснением 65% Spot-мощности; boot diagnostics показывают cloud-init exit 1, число здоровых инстансов упало до 52, а ошибки API достигли 24% за 7 минут. Как вы восстановитесь и зададите гейт замены?
capacityautoscalingapi
60
Swap deployment slot в App Service завершился для 60 инстансов, но ошибки checkout выросли с 0,3% до 13% при зелёных health check; Application Insights показывает, что production slot использует staging endpoint платежей для 41% вызовов. Что вы меняете обратно и что станет гейтом новой попытки?
deploymenthealth-checksendpoints
61
Новая ревизия Azure Container Apps получает 50% из 36 000 запросов в секунду; 5xx достигает 16%, реплики готовы, а Log Analytics связывает ошибки с ревизией 2026-07-16-2. Что вы локализуете и какого гейта восстановления не хватало?
replicationcontainers
62
AKS-кластер на 780 узлов показывает p99 Kubernetes API в 13 секунд, 34 узла NotReady и 21% неуспешных запросов через 6 минут после обновления Azure CNI; Azure Service Health не сообщает об инциденте control plane. Вы заменяете узлы, откатываете CNI или переключаете регион, и что докажет восстановление?
kubernetesrollbackapi
63
Cluster autoscaler AKS удалил 120 узлов за 9 минут после изменения лимита node pool; 2 100 pod находятся в Pending, p99 платежей равен 4,1 секунды, а логи autoscaler указывают на невыполнимые topology constraints. Что вы остановите и как зададите гейт восстановления планирования?
jobsscalingkubernetes
64
После обновления sidecar Istio на 82 сервисах AKS p99 вырос с 190 мс до 2,1 секунды, а retries усилили трафик с 28 000 до 75 000 запросов в секунду; traces показывают 690 мс в Envoy при CPU приложения 44%. Вы настраиваете или откатываете, и что станет гейтом восстановления?
rollbackkubernetes
65
Ошибка retries увеличивает Azure Functions с 7 000 до 49 000 выполнений в секунду; host concurrency достигает 92 000, 12 несвязанных приложений throttled, а возраст самого старого сообщения Service Bus равен 38 минутам. Какое решение по concurrency вы примете и как безопасно разгрузите очередь?
resilienceserverlessmessaging
66
Microsoft Defender for Cloud находит критическую RCE в базовом образе ACR, который используют 1 600 работающих контейнеров в 24 сервисах; эксплуатация не подтверждена, но исправленный digest проваливает 8% canary health check. Вы останавливаете production, принимаете риск или откатываете, и что станет гейтом замены?
containershealth-checksrollback
67
Azure SQL Database переключилась за 42 секунды, но 1 100 инстансов приложения одновременно переподключились; сессии достигли 14 700 из 15 000, CPU равен 95%, а ошибки checkout остаются на 18% через 6 минут. Как остановить storm и задать гейт восстановления writer?
sqldatabasesessions
68
В Azure SQL Managed Instance осталось 110 ГБ из 11 ТБ, хранилище уменьшается на 19 ГБ в час, lag реплики равен 24 минутам, а Query Store связывает рост с операцией над индексом, начатой 4 часа назад. Вы добавляете хранилище, отменяете операцию или переключаетесь, и что станет гейтом восстановления?
sqlindexesqueries
69
Readable secondary Azure SQL, обслуживающая 64% чтений каталога, отстаёт на 43 минуты при 20 000 записей в секунду на primary; устаревшие цены вызывают 7% несовпадений корзины, а Data IO достигает 98%. Вы продвигаете реплику, останавливаете чтения или перестраиваете её, и что станет гейтом возврата?
sql
70
Контейнер Cosmos DB получает 180 000 запросов в секунду, но один tenant создаёт 46% трафика; normalized RU consumption его partition достигает 100%, ответы 429 составляют 22%, а другие tenants получают timeout. Как локализовать hot key и задать гейт восстановления?
normalizationpartitioningcosmos-db
71
Аккаунт Cosmos DB с multi-write принимал обновления в 2 регионах во время 9-минутного разделения; conflict feed содержит 74 000 конфликтов профилей клиентов, а 6% балансов loyalty расходятся. Что вы изолируете и какие данные станут гейтом multi-region writes?
partitioningcosmos-dbconflict
72
Lifecycle rule удалила 8,4 миллиона исходных blobs за 17 минут; object replication завершилась для 6,3 миллиона, а 2,1 миллиона имеют failed или missing replication status, при этом soft delete включён на 14 дней. Как локализовать проблему и восстановиться без потери оставшейся копии?
replicationsoft-delete
73
Azure Managed Redis переключился за 76 секунд; затем 900 инстансов приложения одновременно получили cache miss, CPU базы достиг 97%, а p99 checkout вырос до 5,2 секунды. Как локализовать stampede и задать гейт восстановления cache?
databaserediscaching
74
Backlog Service Bus достиг 11 миллионов сообщений, а lag consumer Event Hubs 38 минут после релиза downstream; dead-letter rate равен 9%, CPU SQL 88%, и появились дубликаты invoices. Что вы приостановите и как зададите гейт восстановления backlog?
messagingstreamingsql
75
Sign-in logs Microsoft Entra показывают аутентификацию service principal из 3 стран и создание 9 credentials за 14 минут; он выполнил 4 200 чтений Key Vault, а alerts Defender указывают на token replay. Как локализовать компрометацию и задать гейт восстановления identity?
tokenssecretsalerting
76
Автоматизация PIM удалила eligible Owner role schedules из 46 подписок; 18 responders не могут активировать аварийные роли во время production outage, а PIM audit history и Activity Logs показывают, что её managed identity удалила 46 schedules 9 минут назад. Как восстановить доступ без постоянного backdoor?
identity
77
Ключ Key Vault отключили во время ротации; 23 приложения теперь проваливают 61% decrypt operations, audit logs Key Vault показывают отключение версии 7 шесть минут назад, а 18 миллионов записей всё ещё ссылаются на неё. Что вы восстановите и что станет гейтом rekeying?
secrets
78
Ротация секрета базы изменила Key Vault за 12 минут до того, как все 320 реплик приложения загрузили его; ошибки аутентификации достигли 37%, а 140 реплик всё ещё используют старый пароль. Как локализовать проблему и задать гейт безопасной ротации?
authsecretspasswords
79
Defender for Cloud обнаруживает 2,7 ТБ необычной исходящей передачи с VM обработки данных за 46 минут; flow logs указывают на 4 внешних IP, snapshots дисков показывают новый инструмент, а VM выполняет 18% ночной обработки. Как локализовать exfiltration и задать гейт восстановления?
snapshotconcurrency
80
Во время расследования отсутствуют экспорты Azure Activity Log для 3 подписок с 02:10 до 03:05, метрики ingestion упали до 0, а в этом окне произошло 14 привилегированных изменений. Как сохранить доказательства, восстановить logging и задать гейт закрытия?
loggingmonitoringclosures
81
Аккаунт хранилища с 31 миллионом документов клиентов разрешал anonymous Blob access в течение 22 минут; логи показывают 640 000 успешных чтений с 1 900 IP, а Defender сообщает о массовом скачивании. Что вы локализуете и что станет гейтом открытия?
82
Audit logs AKS показывают, что скомпрометированный pod создаёт cluster-admin bindings и читает 1 400 secrets за 6 минут; Defender for Containers сообщает о попытке privileged escape на 3 узлах. Как локализовать escalation и задать гейт восстановления кластера?
containerskubernetessecrets
83
Блокировка Terraform state не сработала во время 2 одновременных production apply; в remote state теперь отсутствуют 86 существующих ресурсов, а оба plan предлагают 240 replacements. Как локализовать инцидент state и задать гейт следующего apply?
terraformincidentsconcurrency
84
Обновление AzureRM provider изменило defaults для 74 ресурсов; production plan показывает 31 forced replacement, а логи pipeline говорят, что lock file пересоздан 18 минут назад. Вы применяете, фиксируете версию или редактируете state, и что станет гейтом восстановления?
packagingci-cd
85
Релиз общего Terraform-модуля изменил выражение subnet, и 26 подписок теперь планируют удаление 190 подсетей с 4 800 private endpoints. Что вы замораживаете и как зададите гейт восстановления модуля?
networkingprivate-connectivityterraform
86
Deployment Bicep обновил 420 ресурсов в 12 resource groups до сбоя на ресурсе 311; Activity Logs показывают 68 изменений конфигурации, а 9 приложений теперь возвращают 503. Как безопасно откатиться и доказать восстановление?
deploymentconfigrollback
87
Remediation DeployIfNotExists в 540 подписках запускает 20 000 ARM deployments; запросы throttled, а ресурсы появляются в workload, которые должны были попасть под exemptions. Как остановить и локализовать rollout, сверить его последствия и задать гейт перезапуска?
throttledeployment
88
Workload identity Azure DevOps использовали с неизвестного agent для deployment 17 ресурсов и добавления Owner в 6 подписках за 11 минут; pipeline audit logs показывают токен вне одобренного pool. Как локализовать CI identity и задать гейт восстановления pipeline?
tokensidentitydeployment
89
Azure Monitor пропустил 19-минутный outage checkout, потому что sampling Application Insights отбросил 62% dependency spans, одновременно новое пороговое значение вызвало 14 000 малоценных alerts. Как восстановить signal, локализовать noise и задать гейт мониторинга?
monitoringdependenciesalerting
90
Canary deployment направил 5% из 50 000 запросов в секунду в новую сборку, но её error rate 8% не вызвал rollback в течение 12 минут, потому что alert оценивал среднее по всему fleet. Что вы откатываете и какой гейт должен заменить неудачную canary-проверку?
deploymentrollbackalerting
91
West Europe недоступен 13 минут; целевые RTO платформы 10 минут и RPO 60 секунд, North Europe имеет 45% прогретой мощности, а пробники Front Door и Service Health подтверждают региональный сбой. Как активировать DR и задать гейт трафика?
capacityedge-routing
92
Azure Backup восстановил только 3,2 ТБ из SQL workload на 14 ТБ за 4 часа; RTO равен 6 часам, прогноз завершения 11 часов, а защищённая native restore point за 13 минут до инцидента доступна. Что вы сделаете и что станет гейтом восстановления сервиса?
incidentssqlbackups
93
Azure Cost Management прогнозирует рост месячных расходов на 40%, с $500 000 до $700 000, после релиза; exports показывают, что NAT Gateway и Log Analytics создают $165 000 разницы, а finance требует локализации за 6 часов. Что вы сократите и какие гейты защитят production?
gatewaynetworkingdispersion
94
Портфель Azure reservations на $240 000 в месяц используется только на 54% после переноса 300 VM на другой размер и регион; CFO review завтра, а возврат workloads добавит 80 мс latency. Вы переносите workloads, обмениваете reservations или принимаете потери, и что станет гейтом решения?
latency
95
Региональная квота vCPU блокирует 420 инстансов VMSS во время трёхкратного скачка трафика; allocation failures достигают 100%, здоровая мощность равна 58%, а ошибки API 17%. Как локализовать outage квоты и задать гейт добавленной мощности?
capacityapi
96
Обновление landing zone изменило 18 policy assignments management group; за 2 часа 96 подписок сообщают о сломанных deployments, а 310 соответствующих требованиям private endpoints получают deny. Policy Insights и Activity Logs указывают на новую версию initiative. Что вы откатите и что станет гейтом восстановления?
deploymentrollbackendpoints
97
Аудит начинается через 72 часа, но у 1 800 из 12 000 Azure-ресурсов нет обязательных diagnostic settings, а 340 storage accounts разрешают public network access; production-команды сообщают, что массовая remediation может сломать 26 сервисов. Как уложиться в срок без outage?
estimation
98
Инцидент severity 1 затрагивает 42% транзакций в 3 регионах; на одном звонке 28 responders, за 20 минут предпринято 11 изменений, никто не владеет rollback, а error rate растёт до 19%. Что вы сделаете как incident commander в следующие 10 минут?
incidentstransactionsrollback
99
Junior-инженер предлагает выдать Contributor на все 85 production-подписок, чтобы исправить 25-минутный deployment outage; 14 сервисов заблокированы, но audit logs показывают, что реальный deny вызван отсутствием 2 actions в одной custom role. Как вы обучите инженера и восстановите сервис?
mentoringdeployment
100
Outage на 47 минут вызвал $1,8 миллиона неуспешных заказов; postmortem перечисляет 36 действий, но в квартале доступны только 4 инженера, а evidence показывает, что 82% влияния дали отсутствующий rollback alert и общая региональная DNS-зависимость. Что вы приоритизируете?
dependenciesrollbackalerting

Вопросы

1Как бы вы структурировали enterprise-scale landing zone Azure для 80 подписок в 6 бизнес-подразделениях, если production и регулируемые нагрузки требуют раздельных контролей?

3Как бы вы спроектировали инициативы Azure Policy для 80 подписок, если за 24 часа требуется достичь 95% compliance, а production-исключения могут действовать не более 30 дней?

4Как бы вы управляли доступом Entra ID и PIM для 2 000 сотрудников, администрирующих 80 подписок, если привилегированная активация ограничена 1 часом?

5Восемь продуктовых групп запрашивают 20 подписок Azure в месяц, и каждая должна быть готова за 30 минут; как бы вы построили subscription vending?

6Новой платформе нужны 12 000 региональных vCPU и 6 resource providers в 15 подписках через 6 недель; как бы вы управляли регистрацией провайдеров, квотами и ёмкостью?

7Выбрали бы вы hub-spoke или Azure Virtual WAN для 200 VNet в 4 регионах и 25 филиалов, если 3 сетевым командам нужна единая политика сегментации?

8Как бы вы подключили 2 ЦОД к Azure через 2 независимых канала ExpressRoute по 10 Гбит/с, с резервным VPN и переключением быстрее 90 секунд?

9Как бы вы спроектировали private DNS для 200 VNet, 40 зон Private Link и 2 on-premises доменов, если изменения записей должны разрешаться за 5 минут?

10Сорок подписок используют 25 PaaS-сервисов через Private Link, а число публичных endpoints должно быть равно нулю; как бы вы стандартизировали связность и DNS?

11Как бы вы организовали централизованный интернет-egress для 80 подписок в 3 регионах с пиком 20 Гбит/с и без public IP в workload spokes?

12Спроектируйте Azure Front Door для API с 30 000 запросов в секунду в 3 регионах, SLA 99,99%, RTO 5 минут и без публичных origins; что вы развернёте?

13Как бы вы выбирали между VMs, App Service, Container Apps, AKS и Functions для 30 сервисов с нагрузкой от 100 до 10 000 запросов в секунду и SLA 99,95%?

14Лицензированному vendor-приложению нужны драйверы ядра Windows, 64 vCPU на узел и доступность 99,95% в 2 зонах; как бы вы спроектировали платформу Azure VM?

15Пятнадцати .NET API нужны private ingress, откат деплоя быстрее 10 минут и SLA 99,95%; как бы вы спроектировали платформу Azure App Service?

16Двадцать event-driven нагрузок работают от 200-миллисекундных handlers до 45-минутных jobs и дают всплеск в 30 раз; где вы примените Functions, а где Azure Container Apps?

17Как бы вы спроектировали multi-tenancy AKS для 12 команд и 80 сервисов, если регулируемым нагрузкам нужна жёсткая изоляция, а SLA платформы равен 99,95%?

18AKS estate запускает 600 pods, имеет 70% переменной нагрузки, разрешает Spot только для retryable-задач и допускает service mesh при p99 overhead ниже 10 мс; как бы вы его спроектировали?

19Как бы вы предоставили golden paths и безопасные деплои для 12 команд, выпускающих 80 AKS-сервисов 20 раз в день с откатом быстрее 10 минут?

20Как бы вы спроектировали failover groups Azure SQL для сервиса на 5 000 TPS с SLA 99,99%, RTO меньше 5 минут и RPO меньше 30 секунд?

Закрытые вопросы