Вы проектируете landing zone AWS для 300 аккаунтов в 12 бизнес-подразделениях, а приобретённые компании должны оставаться изолированными до одобрения интеграции. Как вы построите AWS Organizations и SCP?

Я построю неглубокую иерархию OU по этапам жизненного цикла и требованиям контроля, а не буду копировать организационную структуру компании. - На верхнем уровне размещу OU Security, Infrastructure, Workloads, Sandbox и Suspended, а внутри Workloads создам Production и NonProduction. - Для каждой приобретённой компании создам отдельную Quarantine OU с SCP, запрещающими выход из организации, отключение CloudTrail и использование неодобренных регионов до завершения интеграции. - На корневом уровне оставлю минимальный SCP, потому что унаследованный запрет затронет все 300 аккаунтов, а узкие ограничения назначу на самый нижний подходящий OU. - Перед переносом аккаунтов партиями по 10 проверю каждый SCP на canary-аккаунте с помощью IAM Access Analyzer и данных service last accessed.

В Azure есть 180 подписок в 9 странах, рабочие нагрузки ЕС обязаны оставаться в регионах ЕС, а командам разработки нужно меньше ограничений, чем production. Как вы построите иерархию management groups и Azure Policy?

Я разделю географию и среду нагрузки, чтобы независимо наследовать правила резидентности и production-контроли без копирования каждого назначения. - Под корневой management group тенанта создам Platform, Landing Zones, Sandbox и Decommissioned, а под Landing Zones размещу EU и NonEU. - Внутри каждой географии создам Corp-Prod, Corp-NonProd, Online-Prod и Online-NonProd, затем распределю подписки по границе данных и среде. - На EU назначу инициативу Azure Policy allowed locations только с одобренными регионами ЕС, а на группы Prod назначу более строгие политики диагностики и допустимых SKU. - Вместо копирования инициатив буду использовать исключения Policy с владельцем и сроком действия, а изменения сначала проверю в отдельной canary-подписке.

Организация GCP обслуживает 120 продуктовых команд и ожидает 2000 проектов в течение года, причём каждой команде нужны отдельные production-квоты и прозрачный биллинг. Как вы организуете папки и проекты?

Я буду использовать папки для наследуемых правил, а проекты как границу изоляции рабочих нагрузок, квот и биллинга. - Создам верхнеуровневые папки Platform, Products, Sandbox и Retired, затем для каждой продуктовой команды заведу дочерние папки Production и NonProduction, а не отдельную папку для каждого приложения. - Для независимо развёртываемых сервисов или сред с отдельными квотами, сервисными аккаунтами либо метками распределения затрат создам отдельные проекты, а общие ресурсы вынесу из продуктовых проектов. - Ограничения Organization Policy назначу на самой высокой безопасной папке, а project factory будет проставлять метки cost-center, product, environment и owner. - Проекты будут автоматически подключаться к централизованным billing accounts, а данные Cloud Billing будут экспортироваться в BigQuery для распределения затрат по командам во всех 2000 проектах.

Платформа AWS должна выдавать 40 новых аккаунтов для рабочих нагрузок в месяц менее чем за 30 минут, без ручных действий в консоли и со стандартным подключением к сети. Как будет выглядеть процесс account vending?

Я реализую создание аккаунта как асинхронный продукт на базе AWS Control Tower Account Factory for Terraform и версионируемой схемы запроса. - Pull request будет содержать владельца, cost center, среду, классификацию данных и целевой OU, а проверки JSON Schema отклонят неполный запрос до слияния. - Account Factory создаст аккаунт, зарегистрирует его в Control Tower и применит базовый Terraform для IAM Identity Center, бюджетов, агрегации Config и обязательных тегов. - Второй этап подключит VPC аккаунта к нужной таблице маршрутизации AWS Transit Gateway через AWS RAM и зарегистрирует приватные DNS-зоны в Route 53 Profiles. - Процесс вернёт ID аккаунта и статус pipeline, будет идемпотентно повторять попытки по ID запроса и уведомит очередь платформенной команды при превышении SLO в 30 минут.

Платформенная команда Azure получает 25 запросов на подписки в неделю, но имена подписок, billing scopes и диапазоны виртуальных сетей часто указывают неверно. Как вы построите процесс subscription vending?

Я предоставлю валидируемый контракт запроса на подписку, а один pipeline будет отвечать за создание, размещение и подключение подписки. - Запрос будет содержать имя нагрузки, среду, management group, billing scope, группу владельцев, регион и требуемый размер адресного диапазона, причём допустимые значения будут браться из центрального каталога. - Pipeline создаст подписку через Azure subscription alias, переместит её в целевую management group и дождётся наследования назначений Policy перед продолжением развёртывания. - Этап IPAM зарезервирует непересекающийся CIDR в Azure Virtual Network Manager IP address management и развернёт spoke VNet с пирингом к региональному hub. - Terraform сохранит ID подписки и выделенный диапазон, а неудачный запуск продолжится с существующего alias вместо создания дубликата подписки.

Платформа GCP создаст 500 проектов для аналитических команд, и каждый проект должен использовать Shared VPC, но владельцы проектов не должны управлять сетью host project. Как вы реализуете project factory?

Я размещу сеть в региональных host projects Shared VPC, а аналитическим командам буду выдавать только service projects. - Pipeline Cloud Build создаст каждый проект, назначит ему папку и billing account, включит одобренные API и дождётся распространения данных о создании проекта перед следующими шагами. - Фабрика подключит проект к одному из четырёх региональных host projects и выдаст роль Network User только на назначенные подсети, а не на весь host project. - Владельцы продукта получат роли внутри своего service project, а подсетями, маршрутами, Cloud NAT и firewall policies в host projects будет управлять только сетевая команда. - Метаданные проекта будут включать owner, cost center, region и expiry, а повтор с тем же ключом запроса приведёт существующий проект к нужному состоянию вместо создания нового.

В landing zone AWS с 250 аккаунтами рабочих нагрузок и 3 регионами командам нужны централизованные DNS и транзитная связность, но сбой shared services не должен блокировать локальные развёртывания в аккаунтах. Где вы проведёте границу?

Я централизую сервисы, которым нужен единый обзор сети, но оставлю критичные для развёртывания инструменты внутри каждого аккаунта рабочей нагрузки. - Transit Gateway, подключения Direct Connect и проверку исходящего трафика размещу в отдельных Network accounts для каждого региона, разделив таблицы маршрутизации production и nonproduction. - Route 53 Resolver endpoints и связи с общими приватными пространствами имён размещу в DNS accounts, распространяя правила и Route 53 Profiles через AWS RAM. - Pipelines приложений, pull-through caches артефактов и runtime-секреты оставлю локально в аккаунтах, чтобы потеря shared account не мешала откату или обычному развёртыванию. - Разделю Log Archive и Network accounts, потому что их объединение свяжет доступ к большим объёмам логов с привилегированными изменениями маршрутов для 250 аккаунтов.

Один state Terraform сейчас управляет базовыми ресурсами в 600 облачных аккаунтах, а refresh занимает 45 минут. Как вы разделите state, не потеряв согласованность?

Я разделю state по control plane и аккаунту или подписке, чтобы один plan никогда не имел права изменять все 600 сред. - Иерархию и назначения политик уровня организации оставлю в небольшом foundation state, который меняет только платформенная команда. - Базовой конфигурации каждого аккаунта или подписки дам отдельный state key, а региональные network hubs вынесу в отдельные states из-за другого жизненного цикла и состава операторов. - State буду хранить в версионируемом backend с блокировкой, например S3 с DynamoDB locking или Azure Storage blob leases, а каждой pipeline identity дам доступ только к её пути state. - ID аккаунтов, ID сетей и версии политик передам через опубликованный артефакт или реестр параметров вместо широкого доступа через terraform_remote_state.

Тридцать платформенных инженеров вносят изменения в Terraform landing zone, и production-применения должны выполняться последовательно, пока нижние среды работают параллельно. Как вы построите pipeline?

Я отделю проверку переиспользуемых модулей от plans для сред и буду последовательно выполнять apply только в пределах каждого production state. - Pull requests запустят terraform fmt, validate, TFLint, Checkov и тесты модулей, затем создадут сохранённый plan с тем же файлом блокировки провайдеров. - States nonproduction-аккаунтов получат независимые runners и блокировки, поэтому до 10 plans смогут выполняться параллельно без общих учётных данных или state. - Production потребует одобрения сохранённого plan, использует identity уровня среды с краткоживущими OIDC-данными и обеспечит один apply на state через блокировку backend и CI concurrency group. - Релизы модулей будут закреплены неизменяемым Git tag, а при продвижении изменится только ссылка на версию, без пересборки другого кода для production.

Вам нужно переместить 90 аккаунтов AWS из плоской структуры Organizations в новые OU без остановки рабочих нагрузок, а текущее поведение SCP плохо задокументировано. Как вы проведёте реорганизацию?

Я буду считать каждый перенос аккаунта изменением политик и проверю эффективные разрешения до перемещения production-аккаунтов. - Экспортирую текущее членство в OU и прикреплённые SCP, затем вычислю унаследованные политики для каждого аккаунта, а не буду считать прямое назначение полной картиной. - Сначала создам целевые OU без новых запретов, перенесу два sandbox-аккаунта и через CloudTrail и проверки политик IAM Access Analyzer сравню ожидаемые вызовы сервисов. - По возможности добавлю целевые SCP этапами с аудитом, затем буду переносить nonproduction-аккаунты партиями по 10, а production-аккаунты в окна обслуживания соответствующих нагрузок. - Подготовлю скрипт отката аккаунта к исходному родителю и остановлю волну при появлении запрещённых API-вызовов или drift в Control Tower.

API интернет-магазина обрабатывает 40 000 запросов в секунду, 55% из Северной Америки и 45% из Европы, а checkout должен обеспечивать доступность 99,99%, RTO менее 5 минут и RPO менее 30 секунд; как спроектировать мульти-региональную архитектуру AWS без двойной продажи товара?

Я бы запустил stateless-уровень checkout в active-active, но оставил для каждой товарной позиции единственный регион записи, чтобы сохранить корректность. - Направлял бы пользователей по задержке через AWS Global Accelerator в кластеры EKS в us-east-1 и eu-west-1, при этом уровень checkout в каждом регионе рассчитал бы на все 40 000 запросов в секунду, чтобы потеря региона не превратила восстановление в гонку за мощностью. - Корзины хранил бы в глобальных таблицах DynamoDB, поскольку для них допустима eventual consistency менее секунды, а разделы остатков закрепил бы за домашним регионом и использовал там строго согласованные условные записи, исключающие два успешных резервирования. - События заказов реплицировал бы через Amazon MSK Replicator, а заказы сохранял бы в Aurora Global Database; типичная межрегиональная репликация занимает менее секунды, но RPO 30 секунд нужно измерять и использовать как условие для переключения. - Active-active вычисления примерно удваивают постоянные расходы на EKS и NAT, а единственный регион записи остатков добавляет около 70-100 мс к трансатлантическим вызовам checkout; эту задержку я принимаю ради корректных остатков.

У B2B SaaS-платформы 18 000 арендаторов, 9 000 запросов в секунду, целевая доступность 99,95%, а контракты требуют хранить данные клиентов из ЕС в ЕС, а канадских клиентов в Канаде; как построить региональные ячейки с RTO 30 минут и RPO 5 минут?

Я бы закрепил каждого арендатора за ячейкой в пределах разрешенной юрисдикции, а глобально реплицировал только управляющие метаданные без клиентских данных. - Развернул бы одинаковые ячейки Azure landing zone в West Europe, North Europe, Canada Central и Canada East, каждая с AKS, группами отработки отказа Azure SQL и реестром, который сопоставляет ID арендатора с его юридической географией. - Данные клиентов, резервные копии, логи и ключи шифрования оставил бы внутри парной географии с помощью Azure Policy и региональных Key Vault; Azure Front Door может направлять трафик глобально, но не должен кэшировать регулируемые тела ответов за пределами этой географии. - Вторичную ячейку рассчитал бы на 35% регионального пика и автомасштабирование до 100% за 20 минут, что укладывается в RTO 30 минут и стоит заметно дешевле полностью активной дублирующей мощности. - Для групп отработки отказа SQL и георезервированного хранилища задал бы проверяемый RPO менее 5 минут, принимая асинхронную репликацию и потерю до 5 минут подтвержденных записей вместо нарушения резидентности глобальной базой.

Система обработки страховых требований принимает 2 000 запросов в секунду и 6 ТБ новых документов в месяц, требует доступность 99,9%, RTO 60 минут и RPO 15 минут, а бюджет аварийного восстановления ограничен 35% стоимости основного региона; какой warm standby выбрать в AWS?

Я бы выбрал warm standby на 25% мощности с непрерывной репликацией данных и заранее развернутыми сетью, идентификацией и инфраструктурой доставки. - Основную систему запустил бы на ECS Fargate и Aurora PostgreSQL в us-east-1, а уменьшенный сервис ECS и вторичный кластер Aurora Global Database разместил бы в us-west-2; Application Auto Scaling должен восстановить полное число задач за 30 минут. - Документы реплицировал бы через S3 Cross-Region Replication, а для критичного бакета применил бы S3 Replication Time Control, чей SLA репликации 15 минут соответствует RPO, но добавляет плату за репликацию и передачу каждого гигабайта. - Заранее создал бы VPC endpoints, мульти-региональные ключи KMS, роли IAM, реплики Secrets Manager и записи Route 53, чтобы RTO 60 минут не зависел от создания инфраструктуры при переключении. - 25% вычислительной мощности вместе со вторичной базой должны уложиться в лимит 35%, но Aurora, S3 RTC и межрегиональная передача остаются постоянными расходами; pilot light я бы отклонил, потому что загрузка образов и подготовка базы делают RTO 60 минут ненадежным.

Публичный API обрабатывает 15 000 запросов в секунду в East US 2 и West Europe, требует доступность 99,99% и RTO менее 3 минут, а 20% клиентов кэшируют DNS на 10 минут вопреки TTL 30 секунд; как спроектировать переключение трафика в Azure?

Я бы поставил перед обоими регионами глобальный anycast-прокси и не использовал DNS TTL как основной механизм переключения. - Применил бы Azure Front Door Premium с проверками каждые 30 секунд и исключением origin после трех неудачных проверок, что дает около 90 секунд на обнаружение при неизменных имени хоста и edge IP для клиентов. - Запустил бы active-active стеки Application Gateway и AKS в обоих регионах, каждый с мощностью минимум на 60% от 15 000 запросов в секунду, а в нормальном режиме распределял бы трафик через Front Door в пропорции 50:50. - Azure Traffic Manager оставил бы только запасным маршрутом для endpoint Front Door, потому что рекурсивные резолверы и указанное кэширование клиентами на 10 минут не позволяют DNS-only переключению выполнить RTO 3 минуты. - Front Door Premium добавляет счет за глобальный прокси и обработку данных, а межрегиональное переполнение увеличивает egress и задержку пользователей примерно на 80-120 мс, но переключение перестает зависеть от поведения клиентского DNS.

Платежный реестр принимает 8 000 транзакций в секунду из США и Европы, должен обеспечивать доступность 99,999%, нулевую потерю подтвержденных данных и глобально сериализуемые балансы при p99 записи менее 180 мс; какую мульти-региональную архитектуру GCP предложить?

Я бы использовал мульти-региональную базу Spanner и адаптировал приложение к задержке кворума, а не ослаблял согласованность реестра. - Разместил бы сервисы Cloud Run или GKE в us-central1 и europe-west4 за глобальным внешним Application Load Balancer, а для Spanner выбрал бы конфигурацию nam-eur-asia1 или собственную конфигурацию инстанса, соответствующую двум центрам трафика. - Для изменения балансов применил бы read-write транзакции Spanner и commit timestamps; синхронная репликация Paxos дает нулевой RPO подтвержденных транзакций, но межконтинентальный кворум напрямую расходует бюджет p99 в 180 мс. - Чтения баланса выполнял бы как strong reads, а некритичные запросы истории направлял бы в bounded-staleness reads, например с отставанием 15 секунд, чтобы отчеты не конкурировали с 8 000 записей в секунду. - Мульти-региональный Spanner требует больше вычислительных ресурсов реплик, чем региональный инстанс, и тарифицирует межрегиональный трафик; если нагрузочные тесты превысят 180 мс, я бы приблизил голосующую топологию к основному источнику записей, а не создавал два записываемых реестра.

Медицинский архив хранит 1,2 ПБ в AWS, растет на 25 ТБ ежемесячно, обязан держать все копии внутри ЕС и восстанавливать последние 40 ТБ за 24 часа при RPO 4 часа; как спроектировать и проверять резервное копирование?

Я бы хранил неизменяемые резервные копии во втором регионе ЕС и рассчитал канал восстановления из требования вернуть 40 ТБ за 24 часа. - Использовал бы AWS Backup для согласованных с приложением снимков, копировал их из eu-central-1 в eu-west-1 каждые 4 часа и блокировал целевое хранилище через AWS Backup Vault Lock, чтобы срок хранения нельзя было сократить. - Архивные объекты хранил бы с S3 Versioning и межрегиональной репликацией только внутри ЕС, затем переводил старые версии в S3 Glacier Deep Archive; низкая цена хранения оплачивается ожиданием до 12 часов при стандартном извлечении. - Восстановление 40 ТБ за 24 часа требует постоянной скорости около 470 МБ/с без учета накладных расходов, поэтому я бы подготовил параллельные чтения S3, достаточную пропускную способность EC2 и EBS и запас 30%, а не считал извлечение из хранилища единственным ограничением. - Ежеквартально проводил бы полное восстановление в изолированный аккаунт eu-west-1 и измерял восстановление базы вместе с проверкой контрольных сумм; дублирование хранения, запросы извлечения и временные вычисления являются явной ценой соответствия требованиям.

Глобальный сервис совместной работы обслуживает 60 000 запросов в секунду и 30 миллионов пользователей, требует доступность 99,99% и ограничивает влияние отказа зависимости внутри одной ячейки 10% пользователей при RTO 10 минут и RPO 1 минута; как применить ячеистую архитектуру в AWS?

Я бы разделил каждый регион на независимо развертываемые ячейки по 10% арендаторов и назначил каждому арендатору детерминированную домашнюю ячейку. - Построил бы десять ячеек в us-east-1, us-west-2 и eu-west-1, каждую с отдельными группами узлов EKS, кластером Aurora, очередями SQS и квотами примерно на 6 000 запросов в секунду. - Небольшую глобальную таблицу DynamoDB использовал бы как каталог соответствия арендаторов ячейкам и кэшировал бы его в CloudFront; каталог содержит только метаданные маршрутизации, поэтому ячейка не получает доступ к клиентской базе другой ячейки. - Каждую ячейку асинхронно реплицировал бы в парную резервную через Aurora Global Database и S3 Cross-Region Replication, подавал сигнал при приближении отставания к 60 секундам и переключал за RTO 10 минут. - Десять стеков баз и очередей стоят дороже и оставляют примерно 15% резервной мощности неиспользованной в каждой ячейке, но ограничивают область влияния и позволяют переносить одну ячейку без масштабирования или переключения всех 30 миллионов пользователей.

Медиаплатформа отдает 6 ПБ в месяц и на пике принимает загрузки со скоростью 50 ГБ/с, требует доступность 99,95% и RTO 15 минут, но исходные файлы авторов из ЕС не могут покидать ЕС, тогда как производные публичные видео могут распространяться глобально; как спроектировать путь данных в GCP?

Я бы разделил исходные объекты с ограничением резидентности и глобально распространяемые производные на уровне бакетов и конвейеров. - Направлял бы авторов через глобальный внешний Application Load Balancer в региональные сервисы загрузки, а исходные файлы из ЕС записывал бы в dual-region бакет Cloud Storage в ЕС с запретом публичного доступа и ключами CMEK в EU Cloud KMS. - Для исходников из ЕС запускал бы Transcoder API или воркеры GKE в ЕС, записывал только одобренные производные в отдельный multi-region бакет Cloud Storage и отдавал их через Cloud CDN, чтобы ежемесячные 6 ПБ не возвращались к origin. - Dual-region хранилище дает региональную избыточность без вывоза исходников за пределы ЕС; из-за асинхронной репликации я бы буферизовал метаданные загрузок в региональном Pub/Sub и ограничил RPO исходного процесса измеренным отставанием репликации не более 5 минут. - Раздельные копии исходников и производных увеличивают плату за хранение, операции и репликацию, а в доставке доминирует стоимость глобального CDN egress; промежуточные исходники стоит удалять по lifecycle через 30 дней.

Платформа бронирования на пике обрабатывает 25 000 чтений и 3 000 записей в секунду, работает в двух регионах AWS, требует доступность 99,99%, RTO 5 минут и RPO 1 секунду и не может позволить двум клиентам забронировать одно место; стоит ли использовать Aurora Global Database в active-active?

Я бы не делал записи мест в Aurora active-active, а использовал один регион записи при active-active уровнях чтения и вычислений. - Трафик просмотра направлял бы через AWS Global Accelerator в локальные сервисы EKS и читатели Aurora, но резервирование мест отправлял бы текущему writer Aurora PostgreSQL и защищал уникальным ограничением места вместе с serializable-транзакцией. - Использовал бы управляемое planned failover или switchover Aurora Global Database, следил бы, чтобы GlobalDBReplicationLag был ниже 1 секунды, и запрещал переключение при превышении заявленного RPO, а не молча терял принятые бронирования. - Заранее масштабировал бы вторичный кластер EKS и инстанс базы на все 3 000 записей в секунду, чтобы изменения DNS и пулов соединений завершились в пределах RTO 5 минут. - Трансатлантические записи добавляют примерно 70-100 мс пользователям вдали от writer, а дублирующая мощность базы повышает стоимость, но разрешение конфликтов нескольких writers на уровне приложения небезопасно для эксклюзивных мест.

Сервис расчета зарплаты обрабатывает 4 миллиона записей за шестичасовое ночное окно, обязан оставаться в Австралии, требует доступность 99,9%, RTO 2 часа и RPO 15 минут, а на аварийное восстановление можно потратить не более 20% сверх основной стоимости; как сбалансировать переключение и восстановление из резервной копии в Azure?

Я бы объединил небольшой теплый уровень приложения с непрерывной репликацией состояния, а неизменяемые резервные копии оставил запасным вариантом при повреждении данных, но не основным путем двухчасового восстановления. - Основную систему запустил бы в Australia East, а warm pool AKS на 15% мощности в Australia Southeast, с образами контейнеров в геореплицированном Azure Container Registry и проверенным автомасштабированием до мощности пакетной обработки за 60 минут. - Использовал бы группы отработки отказа Azure SQL с пределом потери данных 15 минут и георезервированное Storage только в австралийских регионах; ключи зарплат хранил бы в отдельных региональных Key Vault в той же границе резидентности. - Ежедневные неизменяемые точки восстановления Azure Backup хранил бы 35 дней и ежемесячно восстанавливал все 4 миллиона записей, но для RTO 2 часа полагался бы на репликацию SQL, поскольку полное восстановление базы может занять большую часть этого окна. - Warm pool на 15% и вторичные вычисления SQL должны уложиться в наценку 20%, поэтому при переключении я бы приостановил второстепенную отчетность; полностью активные вычисления улучшили бы RTO, но превысили лимит стоимости для шестичасовой нагрузки.

Вопросы на собеседовании: Облачный архитектор

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

Смотреть пример резюме: Облачный архитектор →

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

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

Вопросы

designlanding-zone

Я построю неглубокую иерархию OU по этапам жизненного цикла и требованиям контроля, а не буду копировать организационную структуру компании.

На верхнем уровне размещу OU Security, Infrastructure, Workloads, Sandbox и Suspended, а внутри Workloads создам Production и NonProduction.
Для каждой приобретённой компании создам отдельную Quarantine OU с SCP, запрещающими выход из организации, отключение CloudTrail и использование неодобренных регионов до завершения интеграции.
На корневом уровне оставлю минимальный SCP, потому что унаследованный запрет затронет все 300 аккаунтов, а узкие ограничения назначу на самый нижний подходящий OU.
Перед переносом аккаунтов партиями по 10 проверю каждый SCP на canary-аккаунте с помощью IAM Access Analyzer и данных service last accessed.

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

designcloud-regions

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

Под корневой management group тенанта создам Platform, Landing Zones, Sandbox и Decommissioned, а под Landing Zones размещу EU и NonEU.
Внутри каждой географии создам Corp-Prod, Corp-NonProd, Online-Prod и Online-NonProd, затем распределю подписки по границе данных и среде.
На EU назначу инициативу Azure Policy allowed locations только с одобренными регионами ЕС, а на группы Prod назначу более строгие политики диагностики и допустимых SKU.
Вместо копирования инициатив буду использовать исключения Policy с владельцем и сроком действия, а изменения сначала проверю в отдельной canary-подписке.

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

css

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

Создам верхнеуровневые папки Platform, Products, Sandbox и Retired, затем для каждой продуктовой команды заведу дочерние папки Production и NonProduction, а не отдельную папку для каждого приложения.
Для независимо развёртываемых сервисов или сред с отдельными квотами, сервисными аккаунтами либо метками распределения затрат создам отдельные проекты, а общие ресурсы вынесу из продуктовых проектов.
Ограничения Organization Policy назначу на самой высокой безопасной папке, а project factory будет проставлять метки cost-center, product, environment и owner.
Проекты будут автоматически подключаться к централизованным billing accounts, а данные Cloud Billing будут экспортироваться в BigQuery для распределения затрат по командам во всех 2000 проектах.

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

Я реализую создание аккаунта как асинхронный продукт на базе AWS Control Tower Account Factory for Terraform и версионируемой схемы запроса.

Pull request будет содержать владельца, cost center, среду, классификацию данных и целевой OU, а проверки JSON Schema отклонят неполный запрос до слияния.
Account Factory создаст аккаунт, зарегистрирует его в Control Tower и применит базовый Terraform для IAM Identity Center, бюджетов, агрегации Config и обязательных тегов.
Второй этап подключит VPC аккаунта к нужной таблице маршрутизации AWS Transit Gateway через AWS RAM и зарегистрирует приватные DNS-зоны в Route 53 Profiles.
Процесс вернёт ID аккаунта и статус pipeline, будет идемпотентно повторять попытки по ID запроса и уведомит очередь платформенной команды при превышении SLO в 30 минут.

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

networkingconcurrency

Я предоставлю валидируемый контракт запроса на подписку, а один pipeline будет отвечать за создание, размещение и подключение подписки.

Запрос будет содержать имя нагрузки, среду, management group, billing scope, группу владельцев, регион и требуемый размер адресного диапазона, причём допустимые значения будут браться из центрального каталога.
Pipeline создаст подписку через Azure subscription alias, переместит её в целевую management group и дождётся наследования назначений Policy перед продолжением развёртывания.
Этап IPAM зарезервирует непересекающийся CIDR в Azure Virtual Network Manager IP address management и развернёт spoke VNet с пирингом к региональному hub.
Terraform сохранит ID подписки и выделенный диапазон, а неудачный запуск продолжится с существующего alias вместо создания дубликата подписки.

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

networking

Я размещу сеть в региональных host projects Shared VPC, а аналитическим командам буду выдавать только service projects.

Pipeline Cloud Build создаст каждый проект, назначит ему папку и billing account, включит одобренные API и дождётся распространения данных о создании проекта перед следующими шагами.
Фабрика подключит проект к одному из четырёх региональных host projects и выдаст роль Network User только на назначенные подсети, а не на весь host project.
Владельцы продукта получат роли внутри своего service project, а подсетями, маршрутами, Cloud NAT и firewall policies в host projects будет управлять только сетевая команда.
Метаданные проекта будут включать owner, cost center, region и expiry, а повтор с тем же ключом запроса приведёт существующий проект к нужному состоянию вместо создания нового.

Зачем это спрашивают: Интервьюер оценивает автоматизацию проектов GCP и отделение владения service project от администрирования Shared VPC.

dnscloud-regionslanding-zone

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

Transit Gateway, подключения Direct Connect и проверку исходящего трафика размещу в отдельных Network accounts для каждого региона, разделив таблицы маршрутизации production и nonproduction.
Route 53 Resolver endpoints и связи с общими приватными пространствами имён размещу в DNS accounts, распространяя правила и Route 53 Profiles через AWS RAM.
Pipelines приложений, pull-through caches артефактов и runtime-секреты оставлю локально в аккаунтах, чтобы потеря shared account не мешала откату или обычному развёртыванию.
Разделю Log Archive и Network accounts, потому что их объединение свяжет доступ к большим объёмам логов с привилегированными изменениями маршрутов для 250 аккаунтов.

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

terraformconsistencypartitioning

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

Иерархию и назначения политик уровня организации оставлю в небольшом foundation state, который меняет только платформенная команда.
Базовой конфигурации каждого аккаунта или подписки дам отдельный state key, а региональные network hubs вынесу в отдельные states из-за другого жизненного цикла и состава операторов.
State буду хранить в версионируемом backend с блокировкой, например S3 с DynamoDB locking или Azure Storage blob leases, а каждой pipeline identity дам доступ только к её пути state.
ID аккаунтов, ID сетей и версии политик передам через опубликованный артефакт или реестр параметров вместо широкого доступа через terraform_remote_state.

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

terraformci-cddesign

Я отделю проверку переиспользуемых модулей от plans для сред и буду последовательно выполнять apply только в пределах каждого production state.

Pull requests запустят terraform fmt, validate, TFLint, Checkov и тесты модулей, затем создадут сохранённый plan с тем же файлом блокировки провайдеров.
States nonproduction-аккаунтов получат независимые runners и блокировки, поэтому до 10 plans смогут выполняться параллельно без общих учётных данных или state.
Production потребует одобрения сохранённого plan, использует identity уровня среды с краткоживущими OIDC-данными и обеспечит один apply на state через блокировку backend и CI concurrency group.
Релизы модулей будут закреплены неизменяемым Git tag, а при продвижении изменится только ссылка на версию, без пересборки другого кода для production.

Зачем это спрашивают: Интервьюер проверяет умение совместить безопасное продвижение Terraform с полезной параллельностью и детерминированными production-применениями.

linux

Я буду считать каждый перенос аккаунта изменением политик и проверю эффективные разрешения до перемещения production-аккаунтов.

Экспортирую текущее членство в OU и прикреплённые SCP, затем вычислю унаследованные политики для каждого аккаунта, а не буду считать прямое назначение полной картиной.
Сначала создам целевые OU без новых запретов, перенесу два sandbox-аккаунта и через CloudTrail и проверки политик IAM Access Analyzer сравню ожидаемые вызовы сервисов.
По возможности добавлю целевые SCP этапами с аудитом, затем буду переносить nonproduction-аккаунты партиями по 10, а production-аккаунты в окна обслуживания соответствующих нагрузок.
Подготовлю скрипт отката аккаунта к исходному родителю и остановлю волну при появлении запрещённых API-вызовов или drift в Control Tower.

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

designcloud-regionsmulti-region

Я бы запустил stateless-уровень checkout в active-active, но оставил для каждой товарной позиции единственный регион записи, чтобы сохранить корректность.

Направлял бы пользователей по задержке через AWS Global Accelerator в кластеры EKS в us-east-1 и eu-west-1, при этом уровень checkout в каждом регионе рассчитал бы на все 40 000 запросов в секунду, чтобы потеря региона не превратила восстановление в гонку за мощностью.
Корзины хранил бы в глобальных таблицах DynamoDB, поскольку для них допустима eventual consistency менее секунды, а разделы остатков закрепил бы за домашним регионом и использовал там строго согласованные условные записи, исключающие два успешных резервирования.
События заказов реплицировал бы через Amazon MSK Replicator, а заказы сохранял бы в Aurora Global Database; типичная межрегиональная репликация занимает менее секунды, но RPO 30 секунд нужно измерять и использовать как условие для переключения.
Active-active вычисления примерно удваивают постоянные расходы на EKS и NAT, а единственный регион записи остатков добавляет около 70-100 мс к трансатлантическим вызовам checkout; эту задержку я принимаю ради корректных остатков.

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

cloud-regionscloud-modelscloud

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

Развернул бы одинаковые ячейки Azure landing zone в West Europe, North Europe, Canada Central и Canada East, каждая с AKS, группами отработки отказа Azure SQL и реестром, который сопоставляет ID арендатора с его юридической географией.
Данные клиентов, резервные копии, логи и ключи шифрования оставил бы внутри парной географии с помощью Azure Policy и региональных Key Vault; Azure Front Door может направлять трафик глобально, но не должен кэшировать регулируемые тела ответов за пределами этой географии.
Вторичную ячейку рассчитал бы на 35% регионального пика и автомасштабирование до 100% за 20 минут, что укладывается в RTO 30 минут и стоит заметно дешевле полностью активной дублирующей мощности.
Для групп отработки отказа SQL и георезервированного хранилища задал бы проверяемый RPO менее 5 минут, принимая асинхронную репликацию и потерю до 5 минут подтвержденных записей вместо нарушения резидентности глобальной базой.

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

system-designdesigncloud-regions

Я бы выбрал warm standby на 25% мощности с непрерывной репликацией данных и заранее развернутыми сетью, идентификацией и инфраструктурой доставки.

Основную систему запустил бы на ECS Fargate и Aurora PostgreSQL в us-east-1, а уменьшенный сервис ECS и вторичный кластер Aurora Global Database разместил бы в us-west-2; Application Auto Scaling должен восстановить полное число задач за 30 минут.
Документы реплицировал бы через S3 Cross-Region Replication, а для критичного бакета применил бы S3 Replication Time Control, чей SLA репликации 15 минут соответствует RPO, но добавляет плату за репликацию и передачу каждого гигабайта.
Заранее создал бы VPC endpoints, мульти-региональные ключи KMS, роли IAM, реплики Secrets Manager и записи Route 53, чтобы RTO 60 минут не зависел от создания инфраструктуры при переключении.
25% вычислительной мощности вместе со вторичной базой должны уложиться в лимит 35%, но Aurora, S3 RTC и межрегиональная передача остаются постоянными расходами; pilot light я бы отклонил, потому что загрузка образов и подготовка базы делают RTO 60 минут ненадежным.

Зачем это спрашивают: Сценарий проверяет, может ли кандидат преобразовать лимит стоимости и цели восстановления в конкретную мощность warm standby.

designdnsfailover

Я бы поставил перед обоими регионами глобальный anycast-прокси и не использовал DNS TTL как основной механизм переключения.

Применил бы Azure Front Door Premium с проверками каждые 30 секунд и исключением origin после трех неудачных проверок, что дает около 90 секунд на обнаружение при неизменных имени хоста и edge IP для клиентов.
Запустил бы active-active стеки Application Gateway и AKS в обоих регионах, каждый с мощностью минимум на 60% от 15 000 запросов в секунду, а в нормальном режиме распределял бы трафик через Front Door в пропорции 50:50.
Azure Traffic Manager оставил бы только запасным маршрутом для endpoint Front Door, потому что рекурсивные резолверы и указанное кэширование клиентами на 10 минут не позволяют DNS-only переключению выполнить RTO 3 минуты.
Front Door Premium добавляет счет за глобальный прокси и обработку данных, а межрегиональное переполнение увеличивает egress и задержку пользователей примерно на 80-120 мс, но переключение перестает зависеть от поведения клиентского DNS.

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

designserializationcloud-regions

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

Разместил бы сервисы Cloud Run или GKE в us-central1 и europe-west4 за глобальным внешним Application Load Balancer, а для Spanner выбрал бы конфигурацию nam-eur-asia1 или собственную конфигурацию инстанса, соответствующую двум центрам трафика.
Для изменения балансов применил бы read-write транзакции Spanner и commit timestamps; синхронная репликация Paxos дает нулевой RPO подтвержденных транзакций, но межконтинентальный кворум напрямую расходует бюджет p99 в 180 мс.
Чтения баланса выполнял бы как strong reads, а некритичные запросы истории направлял бы в bounded-staleness reads, например с отставанием 15 секунд, чтобы отчеты не конкурировали с 8 000 записей в секунду.
Мульти-региональный Spanner требует больше вычислительных ресурсов реплик, чем региональный инстанс, и тарифицирует межрегиональный трафик; если нагрузочные тесты превысят 180 мс, я бы приблизил голосующую топологию к основному источнику записей, а не создавал два записываемых реестра.

Зачем это спрашивают: Вопрос проверяет, защищает ли кандидат финансовые инварианты и рассматривает ли размещение кворума и задержку как измеримые архитектурные ограничения.

designbackupsvalidation

Я бы хранил неизменяемые резервные копии во втором регионе ЕС и рассчитал канал восстановления из требования вернуть 40 ТБ за 24 часа.

Использовал бы AWS Backup для согласованных с приложением снимков, копировал их из eu-central-1 в eu-west-1 каждые 4 часа и блокировал целевое хранилище через AWS Backup Vault Lock, чтобы срок хранения нельзя было сократить.
Архивные объекты хранил бы с S3 Versioning и межрегиональной репликацией только внутри ЕС, затем переводил старые версии в S3 Glacier Deep Archive; низкая цена хранения оплачивается ожиданием до 12 часов при стандартном извлечении.
Восстановление 40 ТБ за 24 часа требует постоянной скорости около 470 МБ/с без учета накладных расходов, поэтому я бы подготовил параллельные чтения S3, достаточную пропускную способность EC2 и EBS и запас 30%, а не считал извлечение из хранилища единственным ограничением.
Ежеквартально проводил бы полное восстановление в изолированный аккаунт eu-west-1 и измерял восстановление базы вместе с проверкой контрольных сумм; дублирование хранения, запросы извлечения и временные вычисления являются явной ценой соответствия требованиям.

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

dependencies

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

Построил бы десять ячеек в us-east-1, us-west-2 и eu-west-1, каждую с отдельными группами узлов EKS, кластером Aurora, очередями SQS и квотами примерно на 6 000 запросов в секунду.
Небольшую глобальную таблицу DynamoDB использовал бы как каталог соответствия арендаторов ячейкам и кэшировал бы его в CloudFront; каталог содержит только метаданные маршрутизации, поэтому ячейка не получает доступ к клиентской базе другой ячейки.
Каждую ячейку асинхронно реплицировал бы в парную резервную через Aurora Global Database и S3 Cross-Region Replication, подавал сигнал при приближении отставания к 60 секундам и переключал за RTO 10 минут.
Десять стеков баз и очередей стоят дороже и оставляют примерно 15% резервной мощности неиспользованной в каждой ячейке, но ограничивают область влияния и позволяют переносить одну ячейку без масштабирования или переключения всех 30 миллионов пользователей.

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

design

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

Направлял бы авторов через глобальный внешний Application Load Balancer в региональные сервисы загрузки, а исходные файлы из ЕС записывал бы в dual-region бакет Cloud Storage в ЕС с запретом публичного доступа и ключами CMEK в EU Cloud KMS.
Для исходников из ЕС запускал бы Transcoder API или воркеры GKE в ЕС, записывал только одобренные производные в отдельный multi-region бакет Cloud Storage и отдавал их через Cloud CDN, чтобы ежемесячные 6 ПБ не возвращались к origin.
Dual-region хранилище дает региональную избыточность без вывоза исходников за пределы ЕС; из-за асинхронной репликации я бы буферизовал метаданные загрузок в региональном Pub/Sub и ограничил RPO исходного процесса измеренным отставанием репликации не более 5 минут.
Раздельные копии исходников и производных увеличивают плату за хранение, операции и репликацию, а в доставке доминирует стоимость глобального CDN egress; промежуточные исходники стоит удалять по lifecycle через 30 дней.

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

databasecloud-regions

Я бы не делал записи мест в Aurora active-active, а использовал один регион записи при active-active уровнях чтения и вычислений.

Трафик просмотра направлял бы через AWS Global Accelerator в локальные сервисы EKS и читатели Aurora, но резервирование мест отправлял бы текущему writer Aurora PostgreSQL и защищал уникальным ограничением места вместе с serializable-транзакцией.
Использовал бы управляемое planned failover или switchover Aurora Global Database, следил бы, чтобы GlobalDBReplicationLag был ниже 1 секунды, и запрещал переключение при превышении заявленного RPO, а не молча терял принятые бронирования.
Заранее масштабировал бы вторичный кластер EKS и инстанс базы на все 3 000 записей в секунду, чтобы изменения DNS и пулов соединений завершились в пределах RTO 5 минут.
Трансатлантические записи добавляют примерно 70-100 мс пользователям вдали от writer, а дублирующая мощность базы повышает стоимость, но разрешение конфликтов нескольких writers на уровне приложения небезопасно для эксклюзивных мест.

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

backupsfailoverdisaster-recovery

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

Основную систему запустил бы в Australia East, а warm pool AKS на 15% мощности в Australia Southeast, с образами контейнеров в геореплицированном Azure Container Registry и проверенным автомасштабированием до мощности пакетной обработки за 60 минут.
Использовал бы группы отработки отказа Azure SQL с пределом потери данных 15 минут и георезервированное Storage только в австралийских регионах; ключи зарплат хранил бы в отдельных региональных Key Vault в той же границе резидентности.
Ежедневные неизменяемые точки восстановления Azure Backup хранил бы 35 дней и ежемесячно восстанавливал все 4 миллиона записей, но для RTO 2 часа полагался бы на репликацию SQL, поскольку полное восстановление базы может занять большую часть этого окна.
Warm pool на 15% и вторичные вычисления SQL должны уложиться в наценку 20%, поэтому при переключении я бы приостановил второстепенную отчетность; полностью активные вычисления улучшили бы RTO, но превысили лимит стоимости для шестичасовой нагрузки.

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

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

21
Вы проектируете сеть AWS для 12 новых VPC в трех зонах доступности, до 2 000 инстансов в каждой VPC и будущего подключения локальной сети, использующей 10.0.0.0/8. Как распределить адреса и маршруты, не создавая раннего ограничения на масштабирование?
scalingdesignnetworking
22
После поглощения 18 AWS VPC и два дата-центра используют части 10.20.0.0/16, но 40 приложений должны начать обмениваться данными за шесть месяцев, а перенумерация займет два года. Какую сетевую схему вы выберете?
communication
23
К одному Transit Gateway подключены 40 AWS VPC: 12 production VPC могут обращаться к общим DNS и логированию, 20 nonproduction VPC не должны обращаться к production, а восьми VPC общих сервисов нужны выборочные обратные маршруты. Как построить сегментацию маршрутов?
gatewaydnslogging
24
Платежный API в одной AWS VPC должен быть приватно доступен из 60 VPC разных бизнес-подразделений, пиковый трафик составляет 2 Гбит/с, а остальные подсети поставщика нельзя открывать. Вы выберете PrivateLink, VPC peering или NAT?
networkingapi
25
Дата-центр должен постоянно передавать 6 Гбит/с в 24 AWS VPC через Transit Gateway с сетевой задержкой менее 25 мс, при этом недопустим отказ из-за одного оператора или одной граничной площадки. Как спроектировать маршрутизацию Direct Connect и VPN?
designgatewaylatency
26
Компания использует 25 Azure spoke-сетей и 25 GCP VPC, ей нужны централизованные межсетевые экраны, приватное подключение 5 Гбит/с к двум дата-центрам и изоляция production от development. Какие эквиваленты вы примените для одинаковой hub-and-spoke модели в обоих облаках?
networking
27
Восемьдесят AWS VPC и два дата-центра должны разрешать приватные имена в corp.example и service.aws.internal при пике 25 000 DNS-запросов в секунду, без утечки в публичный DNS и циклов пересылки. Как спроектировать DNS?
designdnsqueries
28
Приложение AWS ежедневно передает 8 ТБ между уровнями приложений и базы данных через границы зон доступности по условной цене $0,01 за ГБ для каждого тарифицируемого направления, а также 3 ТБ в день в регион с задержкой 70 мс по $0,02 за ГБ. Как снизить стоимость передачи, не ухудшая целевой уровень восстановления?
availabilitycloud-regionshigh-availability
29
Двадцать AWS VPC отправляют 40 Гбит/с трафика обновлений и образов контейнеров в интернет, а централизованные NAT Gateway создают высокую плату за обработку и межзонную передачу. Как изменить исходящий доступ с учетом емкости и стоимости?
gatewaycapacitynetworking
30
Тридцать AWS VPC должны пропускать 15 Гбит/с east-west и интернет-трафика через сторонние межсетевые экраны с состоянием, но асимметричный обратный трафик сейчас обрывает сессии. Как спроектировать путь инспекции?
designnetworkingsessions
31
Сервис B2B-заказов требует реляционных ограничений и транзакций по нескольким строкам, обрабатывает 6000 операций записи и 25 000 чтений в секунду, хранит 8 ТБ, растёт на 2 ТБ в год и требует p99 ниже 80 мс, RPO менее 1 минуты и RTO менее 15 минут. Какую базу данных вы выберете?
databasetransactions
32
IoT-платформа принимает 300 000 показаний устройств в секунду размером менее 2 КБ каждое, хранит их онлайн 30 дней, почти всегда читает по ID устройства и времени и допускает p99 в 200 мс без соединений и транзакций между устройствами. Какое хранилище вы выберете?
transactionsjoins
33
Глобальная система бронирования работает в Северной Америке, Европе и Азии, выполняет 40 000 транзакций в секунду по строкам остатков и бронирований, не должна допускать двойное бронирование и требует локальный p99 чтения ниже 120 мс при региональном RTO менее 5 минут. Что вы выберете: Cloud Spanner или Azure Cosmos DB?
system-designcloud-regionstransactions
34
Медиакомпания хранит 6 ПБ неизменяемых мастер-копий видео, ежедневно загружает 10 ТБ, каждый месяц извлекает 2 процента объектов, должна начать восстановление любого архивного материала в течение 4 часов и защищать данные от случайного удаления семь лет. Как вы организуете хранение?
immutability
35
Платформа продуктовой аналитики принимает 20 ТБ событий в день, хранит 3 ПБ семь лет, должна возвращать дашборды руководства менее чем за 10 секунд и позволяет дата-сайентистам несколько раз в неделю сканировать произвольную историю. Вы построите хранилище данных или lakehouse?
warehouse
36
Двести узлов рендеринга должны совместно использовать POSIX-пространство на 500 ТБ, одновременно читать одни и те же крупные файлы сцен со скоростью до 80 ГБ/с, записывать временные результаты и освобождать ёмкость между ночными заданиями. Вы выберете блочное или файловое хранилище?
capacitycloud-storageconcurrency
37
Самостоятельно управляемая PostgreSQL на EC2 занимает 12 ТБ и на пике создаёт 70 000 случайных операций I/O размером 16 КБ, требует p99 хранилища ниже 2 мс, стабильно использует около 1,1 ГБ/с и растёт на 20 процентов в год. Какую конфигурацию томов EBS вы выберете?
databasepostgresdesign
38
База платежей Aurora PostgreSQL объёмом 40 ТБ требует RPO менее 5 минут и RTO менее 30 минут даже при полной потере региона, а резервные копии должны оставаться неизменяемыми 35 дней. Какую архитектуру хранения для восстановления вы реализуете?
designbackupscloud-regions
39
Сервис корзины обрабатывает 120 000 чтений и 20 000 записей в секунду в шести регионах Azure, требует, чтобы пользователь видел собственные изменения в пределах 100 мс, допускает задержку данных для других пользователей до 2 секунд и должен оставаться доступным для записи при разделении региона. Какой уровень согласованности Cosmos DB вы выберете?
consistencycloud-regionspartitioning
40
У compliance-платформы есть append-only таблица аудита PostgreSQL объёмом 70 ТБ, которая растёт на 2000 строк в секунду, обслуживает 500 запросов в секунду за последние 90 дней, выполняет менее 20 расследований в год по старым данным и должна хранить записи семь лет. Стоит ли оставлять все данные в PostgreSQL?
postgresqueries
41
Ежемесячный счет за вычисления в AWS составляет $420 000, 70% нагрузки стабильны уже год, но спрос на продукт все еще может колебаться на 25%; какой объем вы зафиксируете через Savings Plans?
42
Непроизводственные ресурсы EC2, RDS и EKS стоят $96 000 в месяц, но разработчики используют их только с 08:00 до 20:00 по будням; что вы измените, не блокируя тестирование?
kubernetesawstesting
43
Платформа EKS тратит $180 000 в месяц на рабочие узлы; 65% CPU занимают stateless-задачи, Spot дешевле на 60%, а сервис должен сохранять доступность 99,95% при прерываниях, поэтому как вы измените емкость?
capacitykubernetes
44
Новый обработчик изображений выполняет 20 миллионов задач в месяц, каждая использует 4 ГБ в течение 10 секунд; Lambda стоит $0,000016667 за ГБ-секунду, а 60 экземпляров c7g.xlarge в ECS стоят $0,145 в час, какую платформу вы выберете?
concurrencylambdacompute
45
Восемь петабайт журналов аудита хранятся в S3 Standard примерно за $188 000 в месяц; после 30 дней читается только 15%, хранить нужно год, а получение должно занимать не более нескольких часов, какую lifecycle-политику вы примените?
retentionaws
46
Медиасервис ежемесячно передает 900 ТБ между зонами доступности и 300 ТБ пользователям, из-за чего счет за трафик составляет $45 000; какие архитектурные изменения вы профинансируете первыми?
availabilityhigh-availability
47
Datadog стоит $140 000 в месяц за 60 ТБ логов и полную трассировку, но безопасность требует хранить события аутентификации 90 дней, а инженерам нужны семь дней поиска по логам приложений; как вы сократите счет?
retentionauthmonitoring
48
Торговая платформа тратит $310 000 в месяц на облако при 2,5 миллиона завершенных заказов, а финансовый отдел требует стоимость инфраструктуры ниже $0,10 на заказ до запуска на рынке с низкой маржой; что вы сделаете?
css
49
Однорегиональный SaaS-стек стоит $240 000 в месяц, должен восстанавливаться после отказа региона не более чем за четыре часа и в среднем теряет шесть часов в год при ущербе $40 000 в час; active-active добавит 85% затрат, а warm standby добавит 35% и сократит простой до двух часов, что вы выберете?
cloud-regionscloud-modelscloud
50
База платежей стоит $75 000 в месяц в одном регионе AWS; контракт требует RPO менее 5 минут и RTO менее 30 минут, восстановление из резервной копии занимает четыре часа, теплый межрегиональный кластер Aurora добавит $12 000, а active-active добавит $38 000, что вы построите?
backupscloud-regionsdatabase
51
Платформа оформления заказов в AWS обрабатывает 22 000 запросов в секунду на EKS и Aurora Global Database в us-east-1 и us-west-2, целевые RTO составляют 5 минут, а RPO 30 секунд; us-east-1 отказал 11 минут назад, повышение реплики завершилось на четвертой минуте, но Global Accelerator все еще направляет 35% трафика на неработающие поды, и RTO уже превышен. Что вы делаете сейчас и как безопасно восстанавливаете сервис?
databasekubernetes
52
Сервис заказов в Azure обрабатывает 6 000 записей в секунду с помощью AKS и связи Azure SQL Managed Instance между East US 2 и Central US, целевые RTO составляют 10 минут, а RPO 1 минуту; после сетевого разделения оба региона принимали записи 7 минут, создав 84 000 конфликтующих заказов, хотя наблюдаемое восстановление заняло 8 минут. Что вы делаете сейчас и как безопасно восстанавливаетесь после split-brain?
sqlpartitioningcloud-regions
53
Логистический API в GCP обслуживает 14 000 запросов в секунду на GKE с базой Cloud SQL for PostgreSQL объемом 9 ТБ, реплицируемой из europe-west1 в europe-west4, целевые RTO составляют 15 минут, а RPO 2 минуты; primary недоступен, реплика отстает на 18 минут, инцидент длится 6 минут. Что вы делаете сейчас и как безопасно восстанавливаетесь при таком отставании репликации?
sqldatabasepostgres
54
SaaS API в AWS обслуживает 30 000 запросов в секунду на EKS и Aurora Global Database в eu-west-1 и eu-central-1 с RTO 4 минуты; вычисления и база переключились за 3 минуты, но 62% входов все еще завершаются ошибкой, потому что callback внешнего identity provider и allowlist партнера ссылаются на ALB и NAT IP старого региона. Что вы делаете сейчас?
networkingcloud-regionscloud-models
55
Мультирегиональная SaaS-платформа в Azure обрабатывает 18 000 запросов в секунду с помощью Front Door, AKS, Cosmos DB и региональных Key Vault, целевые RTO составляют 8 минут, а RPO 1 минуту; West Europe отказал 13 минут назад, North Europe исправен, но оба региона зависят от одной привязки приватной DNS-зоны и Azure Firewall в West Europe, поэтому вход и разрешение секретов все еще не работают глобально, а RTO 8 минут превышен на 5 минут. Что вы делаете сейчас и как безопасно восстанавливаете сервис?
dnsnetworkingcloud-regions
56
Система страховых требований в AWS хранит кластер Aurora PostgreSQL объемом 24 ТБ и 110 ТБ в S3, целевые RTO составляют 6 часов, а RPO 15 минут; из-за атаки вымогателя нужно восстановление в чистом аккаунте, но за 4 часа AWS Backup восстановил только 6 ТБ базы, прогноз завершения составляет 14 часов, а выбранная точка восстановления отстает на 11 минут и также доступен защищенный нативный снимок Aurora за 13 минут до атаки. Что вы делаете сейчас и как безопасно восстанавливаете систему?
databasepostgressystem-design
57
Торговая платформа в GCP обычно обслуживает 40 000 запросов в секунду на GKE в us-central1 с мульти-региональным Spanner, имея 25-процентный warm standby в us-east1, целевые RTO составляют 12 минут, а RPO 0; после эвакуации региона us-east1 достиг насыщения CPU при 18 000 запросов в секунду, ошибки оформления заказа составляют 22%, а наблюдаемое восстановление заняло 17 минут. Что вы делаете сейчас и как безопасно восстанавливаете сервис при нехватке мощности?
capacitycloud-regionsmulti-region
58
Биллинговый конвейер в Azure обрабатывает 9 000 сообщений Service Bus в секунду и записывает их в Azure SQL Database объемом 14 ТБ, целевые RTO составляют 20 минут, а RPO 5 минут; после failover в Central US операторы повторно запустили очередь из 12 миллионов сообщений, дублирующие записи затронули 310 000 счетов, а сервис возобновился за 16 минут без потери сообщений. Что вы делаете сейчас и как безопасно восстанавливаете корректность?
queuesfailovermessaging
59
Банковский API в AWS обрабатывает 5 500 записей в секунду на EKS и Aurora Global Database, целевые RTO составляют 7 минут, а RPO 30 секунд; eu-west-1 был аварийно повышен 9 часов назад после отказа us-east-1, сервис восстановился за 6 минут при отставании 12 секунд, а us-east-1 теперь доступен, но содержит 190 миллионов устаревших строк. Что вы делаете сейчас и как безопасно выполняете failback?
databaseapiconcurrency
60
Платежный сервис в GCP записывает 7 500 транзакций в секунду в primary Cloud SQL for PostgreSQL объемом 6 ТБ в asia-southeast1 с межрегиональной репликой в asia-east1, целевые RTO составляют 10 минут, а RPO 60 секунд; primary потерян, повышение завершилось за 8 минут, но повышенная база отстает на 4 минуты 20 секунд, и в ней могут отсутствовать 1,95 миллиона подтвержденных транзакций. Что вы делаете сейчас и как безопасно восстанавливаетесь после нарушения RPO?
sqldatabasetransactions
61
Сетевой бюджет AWS составлял $45 000 на месяц, но после релиза прогноз вырос до $182 000, и финансовому отделу нужен план сдерживания затрат за четыре часа. Основное отклонение приходится на NAT Gateway. Как вы расследуете причину и сократите счет, не нарушив исходящий трафик production?
gatewaynetworkingdispersion
62
Платформа EKS была запланирована на $70 000 в месяц, но после перехода команд на Spot-ноды и Karpenter прогноз вырос до $128 000. У вас один день, чтобы найти регрессию и снизить затраты, сохранив целевую доступность API 99,95%. Что вы сделаете?
decision-makingapikubernetes
63
Azure Monitor и Log Analytics были заложены в бюджет на $25 000 в месяц, но после развертывания diagnostic settings прогноз достиг $140 000. Служба безопасности дает вам шесть часов на сокращение ingestion без потери аудиторских данных. Как вы расследуете и решите проблему?
monitoring
64
Ожидалось, что AWS Compute обойдется в $330 000 за месяц, но прогноз счета достиг $470 000, а EC2 Instance Savings Plan на $300 000 в месяц используется только на 52% вместо запланированных 92%. Нагрузки недавно сменили семейство инстансов и регион. Что вы проверите и измените до завтрашней встречи с CFO?
cloud-regionscomputeaws
65
Serverless-конвейер в GCP был запланирован на $12 000 в месяц, но после шести часов повторяющихся сбоев Cloud Billing прогнозирует $96 000. Pub/Sub вызывает Cloud Run, а неуспешные сообщения повторяются бесконечно. Как вы остановите рост затрат и исправите систему до следующего billing export?
resilienceserverlessci-cd
66
После запуска AWS в нескольких регионах p99 задержки API вырос с целевых 180 мс до 640 мс, а p50 остался около 70 мс. Окно запуска закрывается через 90 минут. Как вы проведете расследование и примете немедленное решение о продолжении или откате?
cloud-regionsmulti-regionapi
67
Сервис ingestion на Azure Event Hubs был протестирован на 120 МБ/с, но на реальном пике упирается примерно в 70 МБ/с, возвращает throttling errors, а backlog нарушит NFR в 15 минут уже через 25 минут. Как вы расследуете проблему и восстановите работу?
backlog
68
Миграция базы данных в GCP обещала p99 задержки storage ниже 20 мс при 18 000 IOPS, но production на balanced Persistent Disk достигает 240 мс, а глубина очереди продолжает расти. До обязательного отката миграции остается два часа. Как вы расследуете и исправите нехватку IOPS?
databasemigrationspromises
69
Клиентский API в GCP обещает 99,95% доступности за месяц, но показывает 99,72%, то есть около 121 минуты недоступности за 30 дней при бюджете 21,6 минуты. Большинство сбоев вызвала региональная revision Cloud Run, а переговоры о продлении начинаются завтра. Что вы расследуете и исправите сегодня?
cloud-regionsapi
70
Checkout-платформа в AWS стоит $520 000 в месяц при жестком лимите $350 000, а руководство требует сократить $170 000 за 48 часов и сохранить текущее заявление о доступности 99,99%. Второй регион работает active-active и стоит $145 000 в месяц. Как вы расследуете ситуацию, примете решение и выполните его?
cloud-regions
71
Во время переключения базы PostgreSQL объёмом 11 ТБ на Amazon Aurora задержка CDC в AWS DMS вырастает с 8 секунд до 45 минут после перевода 20% заказов на целевую базу. Расскажите о реакции в реальном времени, откате и безопасном возобновлении.
postgresrollback
72
После переноса монолита с EC2 на ECS p99 оформления заказа растёт со 180 до 950 мс, когда Application Load Balancer направляет 30% production-трафика на новые задачи. Что вы сделаете в реальном времени и как безопасно возобновите миграцию?
monolithload-balancingmicroservices
73
После перевода 15% трафика чтения с Azure SQL в East US 2 в новое развёртывание West Europe сверка находит расхождения в 2,4% из 180 миллионов строк клиентов. Расскажите о локализации, откате и безопасной второй попытке.
deploymentrollbacksql
74
Во время волны переноса 120 серверов VMware в AWS репликация загружает канал Direct Connect 10 Гбит/с до 96%, и локальная ERP начинает выдавать тайм-ауты. Как вы локализуете инцидент, откатите волну и возобновите её?
replicationincidentsrollback
75
Во время миграции 150 batch workers с GCE VM на GKE 20% заданий переходят новым workers, но 18% завершаются ответами Cloud Storage 403, а backlog Pub/Sub достигает 1,2 миллиона сообщений при SLO возраста 15 минут. Опишите локализацию, откат и безопасное возобновление.
batchslocloud-migration
76
Оповещение AWS Config показывает, что изменение Terraform сделало 14 200 приватных объектов S3 публично доступными для чтения на 23 минуты в production. Каковы ваши немедленные действия, откат и путь к безопасному восстановлению скачиваний клиентов?
terraformconfigrollback
77
Вы обнаруживаете, что workload GCP с требованием хранения только в ЕС за последние 36 часов экспортировал 180 ГБ логов приложений и три резервные копии базы в us-central1. Как вы локализуете нарушение резидентности и безопасно возобновите логирование и резервное копирование?
databaseloggingbackups
78
Развёртывание key policy AWS KMS в production удаляет роль приложения и аварийного администратора, из-за чего доля ошибок расшифровки вырастает до 18% в 40 сервисах. Расскажите о локализации, восстановлении контроля ключа, откате и безопасном возобновлении.
rollback
79
За 48 часов до аудита SOC 2 вы обнаруживаете, что после изменения Control Tower запись AWS Config была отключена в 37 production-аккаунтах на 19 дней. Что вы сделаете сейчас, как откатите drift и когда возобновите обычные релизы?
configrollbackiac
80
Новая инициатива Azure Policy с эффектами deny достигает 42 production-подписок и блокирует масштабирование node pools AKS во время пика, оставляя 600 pods в Pending. Расскажите о локализации, откате и более безопасном перезапуске политики.
scalingrollback
81
Стоимость проприетарной управляемой базы данных выросла на 35%, со $120 000 до $162 000 в месяц, а продление контракта требуется через 60 дней. В ней хранится 18 ТБ, пик составляет 7 000 записей в секунду, и продукт допускает одно окно переключения на 20 минут. Какое решение вы примете сейчас и как его выполните?
database
82
Проприетарная облачная очередь ограничена 50 000 сообщений в секунду, а измеренный рост потребует 80 000 через четыре месяца, и провайдер отказал в повышении квоты. Платформа хранит 25 ТБ событий и не допускает остановки продюсеров. Что вы выберете и что сделаете на этой неделе?
data-structures
83
Вам нужно перенести 4 ПБ из AWS в GCP, но интернет-egress стоит $0,05 за ГБ, а текущий контракт заканчивается через 90 дней. Приёмник способен принимать 40 Гбит/с, и исходный провайдер не предлагает бесплатный выход. Вы останетесь или уйдёте, и как выполните решение сейчас?
84
Провайдер прекратит поддержку управляемой среды, в которой размещены 70 Java-сервисов, через шесть месяцев. Система обслуживает 12 000 запросов в секунду с доступностью 99,95%, а команда может поддерживать либо Azure Container Apps, либо AKS, но не обе платформы. Что вы выберете и как уйдёте с закрываемого сервиса?
containers
85
Ломающее изменение Terraform provider приводит к плану замены 1 800 ресурсов в 420 state-файлах, а исправление безопасности в той же версии должно попасть в production за 14 дней. Какое решение вы примете сегодня и как выполните обновление?
terraformversioning
86
У шести инженеров есть 12 недель на запуск регулируемого процесса заказов с повторами, таймерами, историей аудита и доступностью 99,9%. Вы построите оркестрацию сами, возьмёте AWS Step Functions, Temporal Cloud или будете эксплуатировать Temporal самостоятельно, и что выберете сейчас?
decision-makingorchestration
87
Портал страховых требований должен запуститься через 10 недель при 5 000 запросов в секунду, но 94% запросов читают статус, а текущий дизайн при каждом обращении вызывает mainframe API проверки полиса с лимитом 500 вызовов в секунду; p99 равен 4,2 секунды при SLO 800 мс. Какую архитектуру вы одобрите сейчас?
designsloapi
88
Обработчик документов должен запуститься через шесть недель для 200 000 заданий в день; 70% уже реализовано на Lambda, но тесты показывают среднюю длительность шесть минут, p95 22 минуты при лимите Lambda 15 минут и 4% дублирующих результатов после повторов. Что вы развернете сейчас?
concurrencylambdadeployment
89
Безопасность требует пропускать каждый платёжный запрос через центральный inspection proxy, но тесты показывают, что он добавляет 38 мс к текущему p99 в 31 мс, а контрактный предел равен 50 мс. До запуска осталось три недели. Какой контроль вы одобрите и как докажете его пригодность?
proxytesting
90
Checkout API должен поддерживать месячную доступность 99,99% при 40 000 запросов в секунду, но сервис рекомендаций возвращает ошибки для 30% вызовов, записи лояльности уходят в timeout, а inventory работает нормально. Какую деградацию вы включите сейчас и что откажетесь деградировать?
api
91
Младший архитектор предлагает одну большую AWS VPC с маской /16 для 35 сервисов восьми команд, потому что платформу нужно запустить через шесть недель. Что вы скажете и сделаете и какой конкретный артефакт или проверку потребуете до одобрения сетевого дизайна?
designnetworkingvalidation
92
Старший архитектор предлагает active-active запись в us-east-1 и eu-west-1 для сервиса заказов с 12 000 операциями записи в секунду, но в дизайне нет модели конфликтов, а запуск через восемь недель. Что вы скажете и сделаете и какой артефакт или проверка должны появиться до решения?
validationdesignartifacts
93
Архитектор подает RFC для API на 6000 запросов в секунду с двумя вариантами: EKS показал p99 в 42 мс и $18 000 в месяц, а ECS Fargate показал p99 в 55 мс и $24 000 в месяц; SLO равен 80 мс, решение нужно принять к пятнице. Что вы скажете и сделаете и какие конкретные доказательства потребуете?
decision-makingapislo
94
За две недели до запуска ваша проверка показывает, что база PostgreSQL объемом 14 ТБ восстанавливается 11 часов при обещанном RTO в 60 минут, а межрегиональной реплики у команды нет. Что вы скажете и сделаете и какой артефакт или проверку потребуете до запуска?
databasepostgresreplication
95
Архитектор подготовил три дизайна AWS-платформы для 50 аккаунтов, каждый с подробными диаграммами, но без модели затрат, а отделу закупок нужен бюджет через пять дней. Что вы скажете и сделаете и какой конкретный артефакт или проверку потребуете?
procurementdesignvalidation
96
Две команды спорят между EKS и Lambda для сервиса с измеренной обычной нагрузкой 900 запросов в секунду, двумя десятиминутными пиками по 8000 запросов в день, средним выполнением 250 мс и бюджетом cold start в 100 мс; запуск через четыре недели. Что вы скажете и сделаете и какой артефакт или проверку потребуете?
artifactskubernetesconflict
97
Продуктовая команда просит исключение из контроля резидентности на 30 дней, чтобы обработать 4 ТБ клиентских выгрузок в us-east-1 до контрактного срока через три недели. Что вы скажете и сделаете и какой артефакт или проверку потребуете?
concurrencyerror-handlingvalidation
98
Подопечный отправляет изменение Terraform, которое заменяет модуль базовых IAM-настроек в 200 аккаунтах AWS, а окно релиза откроется через 48 часов. Что вы скажете и сделаете и какой конкретный артефакт или проверку потребуете до apply?
terraformartifactsvalidation
99
Постмортем после 95-минутного облачного сбоя содержит 40 действий вроде «улучшить мониторинг» и «пересмотреть архитектуру» без владельцев и сроков, а разбор назначен на завтра. Что вы скажете и сделаете и какой конкретный артефакт или проверку потребуете?
monitoringartifactsarchitecture
100
Новый облачный платформенный стандарт используют только 20% из 60 команд приложений, потому что onboarding занимает три дня, а цель составляет 70% внедрения за квартал. Что вы скажете и сделаете и какой конкретный артефакт или проверку потребуете?
onboardingdecision-makingvalidation

Вопросы

8Один state Terraform сейчас управляет базовыми ресурсами в 600 облачных аккаунтах, а refresh занимает 45 минут. Как вы разделите state, не потеряв согласованность?

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