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

Я бы централизовал общую связность и инспекцию в hub VNet, подключив каждую VNet нагрузки как нетранзитивный spoke через peering.

• Таблицы маршрутов в spokes направляют разрешенные префиксы или 0.0.0.0/0 в Azure Firewall в hub, а NSG продолжают разделять подсети и нагрузки.
• Gateway transit позволяет spokes использовать VPN или ExpressRoute gateway хаба: на hub peering включается Allow gateway transit, а на каждом spoke включается Use remote gateways.
• Поскольку VNet peering нетранзитивен, для трафика между spokes нужен явный peering или маршрутизируемый путь через appliance в hub.

Azure сначала выбирает самый длинный совпавший префикс, а при равной специфичности учитывает приоритет источника маршрута.

• Маршрут 10.20.4.0/24 выигрывает у 10.20.0.0/16 независимо от того, получен следующий переход из BGP или таблицы маршрутов.
• При одинаковых префиксах пользовательский маршрут обычно выигрывает у BGP, а BGP обычно выигрывает у системного маршрута.
• Я проверяю effective routes на NIC и обратный путь, потому что stateful firewall все равно требует симметричной маршрутизации.

Я бы развернул Azure Firewall в выделенной AzureFirewallSubnet и направил инспектируемый трафик spokes через его приватный IP.

• Firewall Policy разделяет network, application и DNAT rule collections с явными приоритетами и централизованным режимом threat intelligence.
• Standard дает stateful-фильтрацию L3-L7, а Premium добавляет TLS inspection и IDPS, если оправданы затраты на сертификаты и производительность.
• UDR во всех участвующих подсетях сохраняют симметричные пути, а диагностические логи отправляются в Log Analytics для анализа правил и потоков.

Я использую NAT Gateway, когда приватным нагрузкам нужны масштабируемые и предсказуемые исходящие IP без приема незапрошенных входящих подключений.

• Привязка к подсети делает его предпочтительным путем выхода в интернет и дает 64 512 SNAT-портов на каждый подключенный публичный IP.
• До 16 публичных IP или public IP prefix расширяют емкость портов и создают удобный для allow list диапазон исходящих адресов.
• NAT Gateway не инспектирует трафик и не заменяет входящую балансировку, поэтому NSG и Azure Firewall остаются отдельными средствами контроля.

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

• Endpoint получает приватный IP из выбранной подсети, а сервис остается управляемым провайдером и не требует широкого VNet peering.
• Специальная private DNS zone, например privatelink.database.windows.net, связывается с VNets, где обычное имя сервиса должно разрешаться приватно.
• NSG, одобрение endpoint, Azure RBAC на PaaS-ресурсе и авторизация data plane решают разные задачи и проектируются отдельно.

Я бы развернул резервированные inbound и outbound endpoints в выделенных подсетях и связал их с DNS forwarding ruleset.

• Локальный DNS пересылает запросы к приватным зонам Azure на IP inbound endpoints через ExpressRoute или VPN.
• Outbound rules условно пересылают корпоративные суффиксы локальным DNS-серверам, а ruleset привязывается к каждой VNet, где нужны эти правила.
• Private DNS zone links по-прежнему отвечают за записи Azure, поэтому я исключаю циклы пересылки и проверяю пути UDP и TCP на порту 53.

Я выбираю по масштабу и протоколу: глобальный HTTP на edge, DNS-маршрутизация, региональный HTTP или региональный трафик четвертого уровня.

• Front Door является глобальным anycast L7 proxy с edge TLS, WAF, маршрутизацией по пути и проверками origins, а Traffic Manager лишь возвращает DNS-ответы и не проксирует трафик.
• Application Gateway является региональным L7 reverse proxy с WAF и приватными или публичными frontends для веб-нагрузок внутри VNets.
• Azure Load Balancer распределяет TCP или UDP потоки на L4 и подходит публичным или внутренним региональным сервисам с высокой производительностью.

Я бы использовал ExpressRoute как основной приватный канал, а active-active VPN gateway как независимо маршрутизируемый резерв.

• ExpressRoute дает приватную связность через провайдера и BGP, но по умолчанию не шифрует трафик, тогда как IPsec VPN шифрует его через публичный интернет.
• Анонсы маршрутов и BGP weights должны однозначно задавать основной путь без асимметричного возврата через stateful appliances.
• Регулярные failover-тесты подтверждают, что VPN имеет нужную пропускную способность, а DNS, firewall и локальные маршруты работают на резервном пути.

Я предпочитаю managed identity для нагрузки в Azure, а service principal использую, когда identity должна жить независимо от Azure-ресурса.

• System-assigned identity следует жизненному циклу одного ресурса, а user-assigned managed identity может использоваться несколькими одобренными нагрузками и переживает их замену.
• Entra управляет учетными данными managed identity, поэтому приложению не нужно хранить и ротировать client secret.
• Service principal подходит внешней автоматизации или продуктам без managed identity, но вместо долгоживущего секрета лучше использовать сертификат или федерацию.

Workload Identity Federation обменивает доверенный внешний OIDC-токен на access token Entra без хранения Azure client secret.

• Federated credential фиксирует issuer, subject и audience, например одно окружение GitHub или один Kubernetes service account.
• CI запрашивает ID token во время выполнения, либо AKS проецирует токен service account, после чего Azure Identity обменивает его для целевого приложения или managed identity.
• Azure RBAC по-прежнему ограничивает итоговую identity, а узкие subject claims не дают другой ветке, репозиторию или service account использовать это доверие.

Я начинаю с минимального набора операций control plane и data plane и создаю custom role только при отсутствии подходящей built-in роли.

• Actions и DataActions отдельно выдают операции управления и доступа к данным, а NotActions вычитают операции из wildcard, но не создают explicit deny.
• AssignableScopes определяет, где можно назначать определение роли, поэтому я ограничиваю его нужной management group или подписками.
• Я тестирую роль с типовой identity и не добавляю Owner-подобные разрешения вроде roleAssignments/write, если делегирование явно не требуется.

Я делаю высокорисковые Azure-роли eligible и требую ограниченную по времени активацию вместо постоянного активного доступа.

• Для активации Owner или User Access Administrator можно потребовать MFA, обоснование, одобрение и короткий срок действия.
• Access reviews удаляют устаревшую eligibility, а PIM alerts выявляют рискованные постоянные назначения и активации вне ожидаемого процесса.
• Аварийные учетные записи строго мониторятся и исключаются только из средств, способных заблокировать восстановление, а их использование тестируется и аудируется.

Я использую management groups для применения Azure Policy и Azure RBAC выше подписок, но отдельно учитываю их наследование и исключения.

• Иерархия может разделять platform, production, sandbox и регулируемые нагрузки под tenant root, не повторяя часто меняющуюся оргструктуру.
• Назначения Azure RBAC наследуются дочерними management groups, подписками, resource groups и ресурсами, а исключение Azure Policy не может удалить или ослабить этот доступ.
• Назначения Azure Policy тоже наследуются вниз, но Policy exemption лишь отменяет проверку заданных assignments или ссылок initiative на одобренном scope и не влияет на RBAC.

Я выбираю наименее разрушительный effect, который надежно выполняет требование, и перевожу новую policy от наблюдения к принудительному применению.

• Audit и AuditIfNotExists сообщают о несоответствии, а Deny блокирует подходящий create или update запрос до передачи resource provider.
• Modify меняет поддерживаемые свойства, а DeployIfNotExists может развернуть связанные ресурсы, например diagnostic settings, после проверки условий существования.
• Modify и DeployIfNotExists требуют managed identity и remediation tasks для существующих ресурсов, а initiative объединяет связанные definitions с общими параметрами.

Я использую Key Vault RBAC, приватный сетевой доступ и получение через identity, а ротацию автоматизирую с учетом владельца секрета.

• Data-plane роли выдаются managed identities на минимальном scope хранилища или секрета без legacy access policies и широких Contributor grants.
• Private endpoint и private DNS дают доступ приложению, а отключенный public network access или firewall rules блокируют неодобренные пути.
• Rotation policies работают для поддерживаемых ключей, а generic secrets обычно требуют Event Grid события об истечении и Function, которая обновляет исходную систему до публикации новой версии.

Я выбираю Manual, Automatic или Rolling по требуемой степени контроля релиза.

• Manual обновляет модель, но не меняет существующие instances до запуска автоматизации, что дает максимум контроля, но может создать расхождение версий.
• Automatic может распространить изменения модели без прикладного разбиения на партии, поэтому подходит заменяемым fleets, допускающим широкое обновление.
• Rolling заменяет instances партиями с учетом health probes, пауз и минимальной доли здоровых узлов, поэтому обычно подходит контролируемым релизам.

Я использую VM Scale Set с Flexible orchestration, потому что и Spot Priority Mix, и несколько размеров VM через Instance Mix требуют этого режима.

• Я выбираю поддерживаемые availability zones для scale set и храню состояние приложения снаружи, чтобы обычная capacity оставалась доступной при отказе одной зоны дата-центра.
• Spot Priority Mix задает базовое число и долю обычных instances, а Spot instances дают только прерываемый избыток capacity и используют eviction policy Delete.
• Instance Mix ранжирует несколько совместимых размеров VM для повышения доступности capacity, а запас autoscale, Scheduled Events и короткий drain смягчают Spot evictions.

Я задаю App Service plan как общую границу compute и использую staging slot для проверки точной сборки перед контролируемым swap.

• Apps и slots в одном plan конкурируют за CPU и память, поэтому scale-out меняет plan, а не выделяет изолированные workers каждому приложению.
• Slot swap прогревает назначение и меняет маршрутизацию, а slot-sticky settings сохраняют секреты и endpoints окружения в нужном slot.
• Изменения базы должны быть обратно совместимы, потому что swap можно отменить, но он не откатывает несовместимую миграцию схемы.

Я выбираю Container Apps для контейнерных HTTP, event-driven или job workloads, которым нужно управляемое масштабирование без эксплуатации Kubernetes-кластера.

• Revisions поддерживают неизменяемые релизы, распределение трафика и single-revision mode, а правила на KEDA масштабируют по HTTP или очереди до нуля там, где это поддерживается.
• Container Apps environment дает ingress, logging, сеть и необязательные workload profiles для выделенного compute или особых размеров.
• AKS лучше подходит, когда нужны Kubernetes APIs, privileged host access, custom operators или глубокий контроль сети и scheduling.

Azure управляет control plane Kubernetes, а я отвечаю за доступ к кластеру, workloads, add-ons, сеть и capacity узлов.

• Управляемые API server и etcd снимают эксплуатацию control-plane хостов, но version support, расписание обновлений, RBAC и доступность API требуют настройки.
• Небольшой system node pool запускает критичные add-ons, а user pools разделяют workloads по размеру VM, зонам, taints, labels, autoscaling или Spot priority.
• Pod disruption budgets, topology spread и surge settings сохраняют capacity приложения при обновлении образов узлов и Kubernetes.