Вопросы на собеседовании: AWS-инженер
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Старший облачный инженер.
Смотреть пример резюме: AWS-инженер →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я бы использовал Control Tower и разделил OU с нагрузками по средам и регуляторным границам.
- Аккаунты Log Archive и Audit размещу в Security OU, а делегированное управление сервисами безопасности отделю от администрирования нагрузок.
- Создам Infrastructure, Sandbox, Nonproduction, Production и Regulated OU, чтобы SCP следовали устойчивым границам доверия, а не названиям команд.
- При регистрации применю обязательные детективные и превентивные контроли, а для Regulated OU добавлю ограничения по регионам данных и сети.
- Перемещение аккаунтов между OU разрешу только через проверяемый процесс, потому что наследуемые SCP могут немедленно отозвать права.
Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат превратить организацию из 60 аккаунтов в явные административные и регуляторные границы.
Я бы оставил небольшой набор SCP с запретами, привязанный к общим инвариантам организации и исключениям конкретных OU.
- Одна базовая политика запретит выход из организации, отключение сервисов безопасности и изменение центральных назначений логов.
- Отдельные SCP зададут разрешенные регионы, ограничения регулируемых сервисов и сетевые правила production, чтобы у каждой политики был один владелец изменений.
- Права буду выдавать через IAM-политики и permission boundaries, потому что SCP задают максимум разрешений и сами доступ не предоставляют.
- Эффективные политики сначала проверю в canary OU с типовыми ролями, а затем продвину по иерархии OU.
Зачем это спрашивают: Интервьюер проверяет точное понимание семантики SCP, квот и безопасной композиции политик в масштабе организации.
Я бы федеративно подключил корпоративный провайдер идентификации к IAM Identity Center и выдавал доступ через синхронизированные группы.
- Определю permission sets по рабочим функциям, например ReadOnly, Developer, Billing и PlatformAdmin, с длительностью сессии 1 час.
- Назначения групп на наборы аккаунтов автоматизирую, а прямые назначения пользователям запрещу, чтобы прием и увольнение оставались проверяемыми.
- На стороне провайдера потребую устойчивую к фишингу MFA и буду использовать краткоживущие учетные данные ролей вместо IAM access keys.
- Сохраню две строго контролируемые аварийные роли вне федерации, защищенные аппаратной MFA и ежеквартальными проверками доступа.
Зачем это спрашивают: Интервьюер проверяет, масштабируется ли схема идентификации на 800 человек при сохранении краткоживущего доступа и аварийного пути.
Я бы оставил management account в AWS Organizations только для биллинга и изменений организации, а не для ежедневных операций безопасности.
- Делегирую GuardDuty, Security Hub и IAM Access Analyzer аккаунту Security Tooling, которым владеет команда безопасности.
- Для расследований только на чтение и агрегации Config использую отдельный Audit account, чтобы доступ к доказательствам был отделен от изменения контролей.
- Включу автоматическое подключение всей организации для новых аккаунтов и регионов, чтобы выдача аккаунтов не создавала пробелы покрытия.
- Изменения делегированных администраторов буду отслеживать через organization trails и оповещать о назначениях вне утвержденных account ID.
Зачем это спрашивают: Интервьюер оценивает разделение обязанностей и централизованное администрирование сервисов в 60 аккаунтах.
Я бы предоставил процесс на Account Factory for Terraform или Control Tower Account Factory с проверяемой схемой заявки на аккаунт.
- До вызова CreateAccount заявка фиксирует владельца, cost center, среду, класс данных, сетевой профиль и целевой OU.
- Асинхронный пайплайн дождется создания аккаунта и применит базовые роли, логирование, бюджеты, назначения идентификации и сетевые подключения.
- Ключи идемпотентности и автомат состояний предотвратят дубли аккаунтов при throttling API Organizations или повторных запросах.
- Буду измерять p95 от заявки до готовности против цели 30 минут и заранее открывать обращения, когда квоты аккаунтов организации достигнут 80 процентов.
Зачем это спрашивают: Интервьюер ожидает конкретный self-service дизайн, учитывающий асинхронные AWS API, управление и цель выдачи за 30 минут.
Я бы хранил требования к квотам в метаданных аккаунта и нагрузки, а не обнаруживал ограничения при запуске.
- Проверю емкость аккаунтов Organizations, региональные квоты EC2 On-Demand vCPU, лимиты EIP, NAT Gateway и ограничения конкретных сервисов.
- Автоматизирую запросы на увеличение через Service Quotas из каждого целевого аккаунта, потому что многие квоты региональны и привязаны к аккаунту.
- Минимум за 2 недели проведу проверку емкости с нужными семействами инстансов и Availability Zones.
- Если емкость закреплена договоренностью, дополню Capacity Reservations утвержденным резервным регионом, а не буду полагаться только на повышение квоты.
Зачем это спрашивают: Интервьюер проверяет, различает ли кандидат регулируемые квоты и реальную региональную емкость и умеет ли планировать за несколько недель.
Я бы развернул по одному Transit Gateway в каждом регионе в центральном Network account и поделился им через Resource Access Manager.
- Вместо единого плоского домена маршрутизации использую отдельные таблицы TGW для production, nonproduction, shared services и inspection.
- Региональные TGW соединю peering только для утвержденных префиксов и агрегирую CIDR VPC, чтобы контролировать распространение и проверку маршрутов.
- Межсегментные потоки направлю через региональные inspection VPC, оставив большой трафик внутри одного VPC локальным.
- Проверю пропускную способность attachments и appliances против профиля 10 Гбит/с, затем опубликую flow logs и алерты загрузки для каждого пути.
Зачем это спрашивают: Интервьюер оценивает дизайн доменов маршрутизации, централизованное владение, инспекцию и учет пропускной способности в мультиаккаунтном масштабе.
Я бы выбрал Cloud WAN, когда единая глобальная политика и жизненный цикл сегментов важнее прямого управления таблицами маршрутов по регионам.
- В одной core network policy определю сегменты production, nonproduction, shared services и регулируемых нагрузок.
- Региональные TGW или VPC буду подключать через управляемую автоматизацию, а для связи между сегментами потребую явные segment actions.
- Через policy change sets предварительно проверю влияние маршрутов во всех 5 регионах до применения.
- Если среда останется в 2 регионах и у нее будет одна сетевая команда, TGW будет проще и избавит от накладных расходов Cloud WAN на политики и обработку данных.
Зачем это спрашивают: Интервьюер проверяет, следует ли выбор сервиса масштабу организации и операционной модели, а не новизне технологии.
Я бы завершил каналы Direct Connect на разных colocation-площадках и на разных клиентских маршрутизаторах.
- Использую Direct Connect Gateway с ассоциациями Transit Gateway, чтобы централизованно управлять разрешенными маршрутами VPC между аккаунтами.
- Построю туннели site-to-site VPN через разных интернет-провайдеров и буду анонсировать их как менее предпочтительные BGP-пути.
- Приоритет маршрутов задам через BGP communities и явные префиксы, исключая случайные асимметричные пути через stateful firewall.
- Ежеквартально проверю отключение каждого канала и площадки, отслеживая сходимость переключения против сетевой цели 60 секунд.
Зачем это спрашивают: Интервьюер оценивает физическое разнесение, поведение BGP, централизованное подключение и измеримую резервную схему.
Я бы разместил inbound и outbound endpoints Route 53 Resolver в shared-services VPC как минимум в 2 Availability Zones.
- Из AWS буду пересылать только конкретные on-premises суффиксы, а из on-premises условно направлять приватные пространства имен AWS на inbound endpoints.
- Для выдачи 120 приватных зон разрешенным VPC применю Route 53 Profiles или автоматизированные ассоциации hosted zones.
- Централизую Resolver query logs и обнаружение всплесков NXDOMAIN, циклов forwarding и нехватки емкости endpoints.
- Согласую TTL и автоматизацию развертывания с целью 5 минут, не снижая TTL для записей, которые редко меняются.
Зачем это спрашивают: Интервьюер проверяет split-horizon DNS, условную пересылку, мультиаккаунтные ассоциации и компромиссы распространения.
Я бы публиковал каждый сервис за Network Load Balancer как endpoint service из выделенных provider accounts.
- ARN организации не является допустимым allowed principal для endpoint service, поэтому автоматизация развернет список из 40 аккаунтов в явные ARN корня аккаунта или утвержденных ролей и будет сверять добавления и удаления.
- Если для широкого обнаружения нужен `*`, я оставлю обязательное подтверждение и перед приемом каждого запроса проверю аккаунт, роль, сервис и среду через процесс авторизации.
- Потребители создадут interface endpoints в собственных подсетях, а проверенный private DNS и центральный каталог свяжут все 15 сервисов с endpoint, портом, владельцем и SLA.
- Буду отслеживать отклоненные и ожидающие запросы, здоровье NLB, объем данных endpoints и почасовую стоимость, поскольку 15 сервисов в 40 аккаунтах могут создать сотни endpoints.
Зачем это спрашивают: Интервьюер оценивает адресную изоляцию PrivateLink и точные правила principals и подтверждения для авторизации 40 аккаунтов-потребителей.
Я бы развернул egress и inspection VPC в каждом регионе, чтобы региональная зависимость не уводила интернет-трафик между регионами.
- Маршрут по умолчанию из workload направлю через TGW appliance mode на резервированные firewall endpoints Gateway Load Balancer.
- NAT Gateway размещу после инспекции в каждой Availability Zone и сохраню зональную привязку, чтобы избежать межзональных расходов и асимметричного состояния.
- Через SCP и Config rules заблокирую Internet Gateway в workload, назначение публичных IP и неутвержденные обходные пути выхода.
- Масштабирую и нагрузочно проверю firewall fleet выше 20 Гбит/с, а через TGW peering или Cloud WAN буду анонсировать только утвержденные межрегиональные префиксы.
Зачем это спрашивают: Интервьюер проверяет централизованную инспекцию, симметричную маршрутизацию, региональную независимость и защиту от обхода.
Я бы размещал каждый сервис по ограничениям исполнения, а не заставлял все 12 работать на одной платформе.
- Lambda выберу для коротких stateless обработчиков всплесков, если лимиты длительности, пакета и concurrency подходят для роста в 20 раз.
- ECS Fargate использую для контейнерных сервисов с долгими процессами, которым не нужны Kubernetes API или контроль хоста.
- EKS выберу только при уже существующей в организации Kubernetes-компетенции, нужной нескольким командам, а EC2 оставлю для ограничений ядра, GPU или лицензирования.
- Перед выбором стандарта сравню в нагрузочном тесте p99 старта, стабильную утилизацию, потребность в операционной команде и месячную стоимость.
Зачем это спрашивают: Интервьюер оценивает размещение нагрузок по конкретным ограничениям, а не по предпочтению сервиса.
Я бы выбрал EC2, потому что ограничения ядра, памяти, локального NVMe и лицензирования требуют контроля уровня хоста.
- Семейство memory-optimized или storage-optimized выберу только после бенчмарка движка на реальных запросах и сценариях spill.
- Если лицензия привязана к сокету или хосту, использую Dedicated Hosts и проверю переносимость лицензии до финансовых обязательств.
- Размещу инстансы в Auto Scaling group для замены, сохраняя долговечное состояние вне instance-store NVMe.
- Для нужных Availability Zones применю Capacity Reservations, а Savings Plans куплю только на стабильную базовую нагрузку, совместимую с обязательствами по семейству.
Зачем это спрашивают: Интервьюер проверяет, перевешивают ли жесткие ограничения хоста и лицензии стандартное предпочтение управляемых контейнеров.
Для регулируемых нагрузок я бы использовал отдельные AWS-аккаунты и EKS-кластеры, потому что namespaces не являются жесткой границей арендатора.
- В общих кластерах дам каждой команде namespace с группами RBAC, ResourceQuota, LimitRange и NetworkPolicies с запретом по умолчанию.
- Применю EKS Pod Identity или IRSA с одной узкой IAM-ролью на workload и никогда не буду выдавать приложениям роль worker node.
- Через admission policy закреплю разрешенные образы, security contexts и размещение узлов, а для чувствительных общих нагрузок выделю отдельные node pools.
- Распределю стоимость control plane, узлов и observability по меткам команд, одновременно ограничив потребление CPU, памяти и pod шумными соседями.
Зачем это спрашивают: Интервьюер оценивает понимание разницы между мягкой Kubernetes-tenancy и жесткой границей аккаунта и кластера.
Я бы не обещал оба ограничения одинаково для всех: сервисам с жестким лимитом потери 10% нужно минимум 90% непрерываемых реплик, а гибкие workloads возьмут дополнительный Spot для достижения 70% по платформе.
- Определю Karpenter NodePools с разнообразными семействами, размерами инстансов и Availability Zones вместо узкого Spot fleet.
- Критичные реплики распределю по зонам и узлам, резервируя on-demand емкость минимум для 90% каждого ограниченного сервиса.
- PodDisruptionBudgets применю для добровольной консолидации, но не буду выдавать их за защиту от принудительного прерывания EC2.
- Включу обработку прерываний и буду отслеживать pending time, потерю реплик и долю Spot до повышения гибких workloads к цели 70%.
Зачем это спрашивают: Интервьюер проверяет, сочетает ли кандидат экономику Karpenter с контролем прерываний на уровне приложения.
Я бы внедрял mesh только ради возможностей, которые 120 сервисов не могут надежно получить через более простые общие библиотеки или gateways.
- Измерю latency и CPU sidecar или ambient data plane под production-трафиком и отклоню дизайн, если p99 превысит 10 мс.
- Начну с mTLS identity и телеметрии трафика, а не с retries на каждом переходе, потому что многослойные повторы усиливают нагрузку.
- Сначала подключу 10 низкорисковых сервисов и определю обходные пути для протоколов и нагрузок, с которыми mesh работает плохо.
- В план емкости команды из 4 человек включу ротацию сертификатов, обновления proxy, отладку политик и on-call нагрузку.
Зачем это спрашивают: Интервьюер оценивает, включает ли решение о mesh latency, численность команды, поведение retries и постепенную проверку внедрения.
Я бы предоставил версионируемые шаблоны утвержденного runtime, IaC, пайплайна, телеметрии, проверок безопасности и метаданных владения.
- Запрос в портале создаст репозиторий, привязки аккаунта и среды, least-privilege роль, dashboards, alerts и процесс развертывания.
- Для хранилищ данных и очередей дам extension points внутри paved road, чтобы команды не форкали весь шаблон.
- Опубликую измеримые контракты, включая bootstrap за 15 минут, длительность пайплайна, поддерживаемые версии и границы поддержки платформы.
- Для всех 18 команд буду отслеживать внедрение, расхождение с шаблоном, неудачные развертывания и время до первого production-релиза.
Зачем это спрашивают: Интервьюер проверяет, является ли golden path поддерживаемым продуктом с контрактами и точками расширения, а не каркасом репозитория.
Я бы применил progressive canary, потому что частота развертываний и цель отката 5 минут требуют автоматических данных, а не ручного подтверждения.
- Направлю 2 процента трафика на новую версию и буду переходить по фиксированным этапам, только пока error rate и p99 latency остаются в пределах.
- Сравню canary и baseline по метрикам CloudWatch или OpenTelemetry и автоматически верну трафик при нарушении порогов.
- Изменения базы сделаю обратно совместимыми через expand and contract, чтобы обе версии приложения работали во время canary.
- Blue-green оставлю для редких изменений платформы или зависимостей, когда дублирование всей среды оправдано быстрым переключением трафика.
Зачем это спрашивают: Интервьюер оценивает выбор стратегии развертывания по SLA, частоте релизов, времени отката и совместимости данных.
Я бы запустил основной кластер Aurora в регионе записи и заранее подготовленный secondary cluster в регионе восстановления.
- Использую storage replication Global Database и буду контролировать межрегиональный replication lag против RPO менее секунды.
- Чтения направлю на региональные readers, но все записи оставлю на primary endpoint, сохраняя одного авторитетного writer.
- Автоматизирую managed failover или switchover с обновлением Route 53 либо endpoint приложения и проверю выполнение за 60 секунд.
- Схему, parameter groups, secrets, емкость и зависимости приложения заранее сделаю одинаковыми в обоих регионах.
Зачем это спрашивают: Интервьюер проверяет, связывает ли кандидат топологию Aurora и поведение endpoints с измеримыми RPO и RTO.
Закрытые вопросы
- 21
Aurora должна обслуживать пользователей в 3 регионах с локальными чтениями менее 50 мс, но конфликты межрегиональной записи запрещены; какую топологию вы выберете?
- 22
Lambda API может достигать 10 000 одновременных вызовов, а Aurora допускает только 800 подключений приложения; как вы используете RDS Proxy?
proxyserverlessconcurrency - 23
Как бы вы спроектировали DynamoDB global table для 200 000 записей в секунду в 3 регионах, если для каждого item нужна детерминированная обработка конфликтов?
dynamodbdesign - 24
Один клиент создает 40% из 1 000 000 записей DynamoDB в секунду, а текущим partition key служит tenant ID; как вы устраните горячую партицию?
dynamodbpartitioning - 25
DynamoDB Streams должны передавать 50 000 событий в секунду 8 потребителям, но дублирующиеся побочные эффекты запрещены; какую архитектуру вы предложите?
dynamodbarchitecture - 26
Как бы вы спроектировали хранение в S3 для 5 ПБ регулируемых объектов со сроком хранения 7 лет, межрегиональным RPO менее 15 минут и запретом удаления сохраненных данных любым администратором?
designobject-storageaws - 27
API обслуживает 100 000 чтений в секунду, допускает устаревание данных на 5 секунд и обновляется через события; как вы объедините ElastiCache и event-driven consistency?
eventsconsistencyapi - 28
Как бы вы спроектировали zero-trust IAM для 800 людей и 2 000 workloads в 60 аккаунтах, если сессии людей ограничены 1 часом, а долгоживущие access keys запрещены?
sessionszero-trustiam - 29
Как бы вы спроектировали KMS-шифрование для 60 аккаунтов и 3 регионов, если регулируемым командам требуется разделение ключей, а центральная безопасность должна контролировать политики?
encryptiondesign - 30
Десять тысяч секретов приложений в 60 аккаунтах должны ротироваться каждые 30 дней без доступа платформенной команды к открытому тексту; как вы используете Secrets Manager?
secrets - 31
Как бы вы спроектировали агрегацию GuardDuty, Security Hub и Config для центральной безопасности во всех 60 аккаунтах и включенных регионах, чтобы новые findings высокой серьезности были видны за 5 минут?
aggregationconfigseverity-priority - 32
Как бы вы спроектировали неизменяемое аудит-логирование для 60 аккаунтов со сроком хранения 7 лет, legal hold и жестким запретом администраторам workload изменять логи?
retentiondesignlogging - 33
Как бы вы спроектировали контроли supply chain в AWS для платформы, которая собирает 200 контейнерных образов в день, если production может запускать только подписанные образы с отслеживаемым происхождением?
designcontainers - 34
Двенадцать аккаунтов обрабатывают регулируемые данные ЕС, которые не должны покидать eu-west-1 и eu-central-1, а общая платформа работает в 3 глобальных регионах; как вы обеспечите границу?
concurrency - 35
Для 60 аккаунтов, 12 команд и жесткого требования проверять план перед каждым изменением как вы выберете между Terraform Enterprise, AWS CDK и CloudFormation?
terraformiac - 36
Как бы вы спроектировали tenancy state в Terraform Enterprise для 60 аккаунтов и 400 workspaces, чтобы одна команда не могла выполнить plan против state другой команды?
terraformdesign - 37
Двадцати командам нужны переиспользуемые IaC-модули, а 80% новых сервисов должны следовать golden path в течение 6 месяцев; как вы построите программу модулей?
designiac - 38
Каждый pull request IaC для 60 аккаунтов должен получить результаты policy as code за 10 минут; какие контроли вы добавите в пайплайн?
ci-cdiaccode-review - 39
Как бы вы спроектировали контроль, который обнаруживает несанкционированный IaC drift для 25 000 ресурсов AWS за 15 минут без автоматического затирания аварийных изменений?
iacdesign - 40
Новый сетевой baseline нужно развернуть в 60 аккаунтах за 5 волн с жесткой остановкой, если validation не пройдет более чем в 1 аккаунте; как сделать rollout безопасным?
validation - 41
Customer API имеет целевую доступность 99,95% за 30 дней; как вы определите его SLO и политику error budget?
sloapi - 42
Как бы вы спроектировали telemetry на CloudWatch и OpenTelemetry для 200 сервисов, создающих 1 000 000 spans в минуту, если расходы на observability ограничены 5% стоимости AWS?
observabilitymonitoringdesign - 43
Какой из подходов backup-and-restore, pilot light, warm standby и active-active вы бы выбрали для приложения tier-1 с RTO 15 минут и RPO 5 минут в 2 регионах?
backups - 44
Как бы вы спроектировали неизменяемые backups для 60 аккаунтов с ежедневными recovery points, регулируемым хранением 7 лет и жестким запретом скомпрометированным администраторам аккаунтов удалять backups?
designbackupsimmutability - 45
Как бы вы спланировали ежеквартальный game day для сервиса с доступностью 99,99%, RTO 30 минут, RPO 1 минута и жестким запретом видимого для клиентов прерывания?
- 46
Нужно провести Well-Architected reviews для 40 workloads за 90 дней без отчетов ради чек-листа; как вы организуете программу?
- 47
Ежемесячные расходы AWS составляют $1,2 млн в 60 аккаунтах, а 70% compute usage стабильно; как вы рассчитаете обязательства Savings Plans и Reserved Instances?
- 48
Как бы вы распределили минимум 95% ежемесячных расходов AWS в $1,2 млн между 60 аккаунтами и 18 продуктовыми командами, если общие сетевые и платформенные затраты составляют 20%?
- 49
Руководство требует за 6 месяцев сократить ежемесячные расходы AWS на 25% от $900 000 без снижения клиентского SLA 99,95%; каков ваш конкретный план?
- 50
Двенадцать команд не согласны по 3 вариантам AWS-платформы, решение RFC нужно принять за 2 недели, а 4 инженера под вашим менторством должны помочь задать техническое направление; как вы поведете решение?
conflictmentoringdecision-making - 51
Route 53 направляет 60% из 18 000 запросов в секунду в us-east-1; CloudWatch зеленый, но 3 внешних пробника фиксируют 38% ошибок checkout уже 7 минут после изменения health check. Какое решение по маршрутизации вы примете и какие данные ограничат восстановление?
dnsmonitoring - 52
Изменение Transit Gateway в организации из 220 аккаунтов распространило 10.42.0.0/16 из development в production; VPC Flow Logs показывают 14 000 отклоненных соединений, а 6 платежных сервисов недоступны 9 минут. Как вы локализуете утечку и решите, что маршрутизация безопасна?
gatewaynetworking - 53
Канал Direct Connect на 10 Гбит/с упал 12 минут назад, BGP перевел трафик на два VPN-туннеля по 2 Гбит/с, но packet capture показывает обратный трафик через Direct Connect и 31% timeout API при 3,5 Гбит/с. Что вы измените и какое условие предотвратит повторную асимметрию?
hybrid-networkingapi - 54
Checkout VPC имеет 48 000 одновременных исходящих соединений; NAT ErrorPortAllocation достигает 9 200 в минуту, TLS timeout партнера равны 27%, а Flow Logs показывают scraper с 40 соединениями в секунду на задачу. Как вы локализуете сбой и ограничите восстановление egress?
resiliencenetworkingtls - 55
ALB вырос с 24 000 до 61 000 запросов в секунду после promotion; target 5xx достиг 18%, логи показывают target_reset, а 640 задач ECS используют лишь 70% CPU. Вы масштабируете, откатите или измените ALB и как восстановите сервис?
rollback - 56
После обновления правила Route 53 Resolver 73 VPC не разрешают corp.internal уже 11 минут; query logs показывают 82% SERVFAIL, ENI outbound endpoint исправны, а on-premises DNS отвечает напрямую за 12 мс. Что вы откатите и что докажет восстановление?
queriesdnsendpoints - 57
Новый endpoint service PrivateLink создали вокруг replacement NLB; 46 новых endpoints ожидают acceptance, а 160 существующих endpoints по-прежнему используют старый service и видят 34% reset после изменения его NLB. Что вы восстановите и как ограничите миграцию?
migrationsendpointsasync - 58
Изменение маршрута отправляет 94 ТБ в сутки регулируемого трафика клиентов из ЕС через us-east-1 уже 27 минут, нарушая утвержденную границу резидентности; потоковая телеметрия показывает 38 Гбит/с между регионами. Как вы локализуете инцидент, сохраните данные и восстановите соответствие?
incidents - 59
Смешанный EC2 fleet потерял 78% Spot-емкости за 6 минут при пике 32 000 запросов в секунду; завершаются 420 инстансов, очередь достигает 2,8 миллиона, а notices дают 2 минуты. Как вы восстановитесь без второй перегрузки?
capacitycomputedata-structures - 60
Auto Scaling rollout заменил 180 из 240 инстансов launch template с неисправным user data; EC2 console показывает cloud-init exit 1, здоровых хостов ALB осталось 54, а ошибки достигли 23% за 8 минут. Что вы откатите и как безопасно замените флот?
scalingcomputerollback - 61
Deployment ECS из 320 задач Fargate достиг steady state, но 5xx checkout выросли с 0,3% до 11%; память равна 58%, circuit breaker не сработал, а трассировки указывают на новый image digest. Что вы сделаете и какого recovery gate не хватило?
deploymentcontainersresilience - 62
Кластер EKS с 900 узлами имеет 19% ошибок; p99 Kubernetes API равен 14 секундам, 37 узлов находятся в NotReady, а AWS Health чист после rollout CNI 6 минут назад. Вы замените узлы, откатите rollout или выполните failover и что докажет восстановление?
kubernetesrollbackapi - 63
Консолидация Karpenter выводит 140 узлов EKS за 9 минут при disruption budget 10%; 2 300 pods находятся в Pending, p99 платежей достиг 4,2 секунды, а логи показывают несовместимые topology constraints. Что вы остановите и как восстановите планирование?
kuberneteskubernetes-autoscalingjobs - 64
После обновления sidecar App Mesh на 85 сервисах p99 вырос со 180 мс до 1,9 секунды, а retries утроили трафик до 72 000 запросов в секунду; X-Ray показывает 640 мс в Envoy при CPU приложения 46%. Вы настроите или откатите и как восстановитесь?
rollback - 65
Ошибка retries увеличила Lambda с 8 000 до 54 000 вызовов в секунду; concurrency достигла 95 000, throttles затронули 14 функций, а возраст старого сообщения SQS равен 41 минуте. Какое решение по concurrency вы примете и как безопасно разгрузите очередь?
resilienceserverlessqueues - 66
Сканирование ECR нашло критическую RCE-уязвимость в базовом image для 1 700 контейнеров в 26 сервисах; признаков эксплуатации нет, но исправленный image не проходит 9% canary health checks. Вы остановите production, примете риск или откатите и какие условия зададите?
containershealth-checksrollback - 67
Writer Aurora PostgreSQL переключился за 38 секунд, но 1 200 задач переподключились одновременно; соединения достигли 14 800 из 15 000, CPU равен 96%, а ошибки checkout остаются 17% спустя 6 минут. Как вы остановите шторм и решите, что writer безопасен?
postgres - 68
У RDS PostgreSQL осталось 90 ГБ на томе gp3 12 ТБ, место убывает на 18 ГБ в час, replica lag равен 27 минутам, а Performance Insights связывает рост с неудачным созданием индекса 4 часа назад. Вы добавите место, отмените работу или выполните failover и как восстановитесь?
indexespostgresreplication - 69
Реплика RDS MySQL с 68% чтений каталога отстала на 46 минут при 21 000 записей в секунду на primary; DiskQueueDepth равен 190, а старые цены вызывают 7% несовпадений корзины. Вы продвинете, отключите или перестроите реплику и что ограничит восстановление?
replicationrds - 70
Таблица DynamoDB orders получает 180 000 записей в секунду, а merchant-8842 создает 42%, то есть примерно 75 600 записей в секунду; throttles достигают 31 000 в секунду, и merchant встречается в 87% ошибок. Как вы локализуете hot key без потери порядка заказов?
dynamodbthrottle - 71
Global table DynamoDB принимала записи в us-east-1 и eu-west-1 во время разделения на 13 минут; после репликации у 26 400 профилей конфликтуют адреса, а CloudTrail подтверждает запись в обоих регионах. Какая копия победит и как вы восстановитесь?
replicationdynamodbpartitioning - 72
Оператор удалил 18 миллионов объектов из versioned S3 bucket; 6,2 миллиона delete markers уже реплицированы, Object Lock отсутствует, а 44% скачиваний падают спустя 17 минут. Что вы восстановите первым и как исправите destination?
replicationawsobject-storage - 73
Primary ElastiCache Redis переключился за 54 секунды, но 700 инстансов не переподключились, hit rate упал с 93% до 8%, CPU Aurora достиг 94%, а p99 checkout равен 3,8 секунды. Вы выполните flush, failback или throttling и как предотвратите stampede?
rediscachingthrottle - 74
Очередь заказов SQS выросла с 40 000 до 12,6 миллиона за 35 минут; самое старое сообщение имеет возраст 29 минут, ошибки Lambda равны 0,2%, а write latency Aurora растет с 12 до 140 мс выше concurrency 4 000. Как вы разгрузите ее и определите восстановление?
concurrencydata-structureslambda - 75
GuardDuty сообщает об IAM key, использованном из 3 стран за 11 минут; CloudTrail показывает 286 AssumeRole и 41 изменение security groups, а владелец считает ключ неактивным. Как вы локализуете компрометацию и решите, что аккаунты безопасны?
iam - 76
Новый SCP с ошибочным условием действует в 310 аккаунтах, и 74 production roles теряют доступ к AWS API; CloudTrail фиксирует attachment в 14:06, а break-glass roles тоже не работают. Как вы выйдете из lockout и какое условие позволит применить политику снова?
linuxapi - 77
Customer key KMS для 96 сервисов отключен автоматизацией; 63% decrypt падают, CloudTrail показывает DisableKey 8 минут назад, а 4 ТБ записей используют этот ключ. Вы включите, смените или восстановите его и как докажете восстановление?
encryptiondata-structures - 78
Secrets Manager сменил пароль базы для 380 задач, но клиенты кешируют его на 24 часа; ошибки аутентификации достигли 71%, старый секрет действителен еще 5 минут, а finishSecret успешен. Что вы откатите и как восстановитесь?
authsecretspasswords - 79
GuardDuty сообщает об эксфильтрации S3: EC2 role прочитала 7,4 ТБ за 2 часа; Flow Logs показывают отправку 3,1 ТБ на незнакомый IP при норме 20 ГБ в сутки. Вы завершите, заблокируете или сохраните инстанс и что ограничит восстановление?
computeobject-storageaws - 80
Security обнаруживает 19-часовой пробел CloudTrail в 84 аккаунтах; доставка S3 остановилась в 02:11, CloudTrail Lake содержит события для 61 аккаунта, а IAM-инцидент мог быть в 08:40. Как вы сохраните данные и решите, что аудит восстановлен?
incidentscoverageaws - 81
AWS Config сообщает о публичном S3 bucket с 2,3 миллиона payroll-объектов; логи показывают 18 400 анонимных GET за 36 минут, Block Public Access отключен в 10:02, а legal требует решение за 15 минут. Что вы сделаете и когда сервис возобновится?
configawsobject-storage - 82
Audit logs EKS показывают создание cluster-admin bindings одним service account в 4 кластерах; за 22 минуты запущены 63 privileged pods, 9 узлов обращались к mining pool, хотя token должен лишь перечислять pods. Как вы локализуете escalation и восстановите доверие?
kubernetestokensescalation - 83
Workspace Terraform Enterprise потерял state lock во время apply; изменены 320 из 500 ресурсов, последний state на 14 МБ меньше, а следующий plan удаляет 86 живых ресурсов. Что вы восстановите и какие данные разрешат новый apply?
terraform - 84
Обновление общего Terraform module в 74 workspaces меняет default с private на public и планирует замену 1 900 load balancers; 11 уже выполнили apply, а Config показывает 7 публичных endpoints. Как вы остановите blast radius и восстановите потребителей?
terraformconfigload-balancing - 85
Обновление CloudFormation для stack из 260 ресурсов падает на ресурсе 214 с UPDATE_ROLLBACK_FAILED; изменены 37 ресурсов, замена базы заблокирована, а ошибки API равны 28%. Вы продолжите rollback, импортируете или восстановите и что ограничит recovery?
rollbackiacapi - 86
Deployment CDK успешен для 48 stacks, но drift detection находит 312 различий IAM и security groups после экстренного изменения; 6 roles имеют AdministratorAccess, активной аварии нет. Вы перезапишете или сохраните drift и какое условие используете?
deploymentiaciam - 87
Role pipeline создает 23 IAM users и отключает 16 CloudWatch alarms за 9 минут; сессия пришла из одного build, а 140 production accounts доверяют role. Как вы локализуете компрометацию CI role и восстановите delivery?
sessionsiamci-cd - 88
Во время 21-минутной аварии checkout дашборды зеленые из-за остановки ingestion в одном аккаунте; логи ALB показывают 36% 5xx, collectors теряют 84 миллиона spans, а status page заявляет 99,99%. Как вы работаете вслепую и решите, что мониторинг надежен?
monitoring - 89
Новый пакет alarms создает 48 000 уведомлений за 3 часа в 260 аккаунтах; только 6 связаны с клиентами, p95 подтверждения равен 19 минутам, а реальный database alarm пропущен. Что вы заглушите и какие данные позволят активацию?
reactdatabase - 90
Canary направляет 5% трафика на release 12 минут; p99 растет с 260 мс до 1,4 секунды, ошибки остаются 0,4%, а gate проходит, проверяя только 5xx ниже 1%. Вы выполните promotion или rollback и как исправите gate?
deployment-strategiesrollback - 91
us-east-1 недоступен 7 минут для платежей с RTO 10 минут и RPO 30 секунд; lag Aurora Global Database равен 18 секундам, standby имеет 40% емкости, а Route 53 все еще отправляет 22% в east. Вы активируете DR сейчас и что ограничит восстановление?
capacitydnsdatabase - 92
Тест должен восстановить snapshot Aurora 9 ТБ в пределах RTO 4 часа, но спустя 3 часа читается 22% горячих данных, а 31% validation queries падают; AWS Backup сообщает о завершении. Вы примете, смените метод или объявите провал и как восстановитесь?
queriessnapshotvalidation - 93
Суточный темп AWS вырос на 40% с $82 000 до $114 800 за 6 часов; Cost Explorer относит $21 000 к NAT и $9 600 к transfer us-east-1 после release при неизменном клиентском трафике. Что вы остановите и какие данные разрешат обычную работу?
networking - 94
Годовой Compute Savings Plan на $1,8 миллиона покрывает 72% baseline, но спрос падает на 35% уже 3 месяца, а utilization равен 61%; finance просит сегодня решить о новом обязательстве на 1 год под запуск. Каково решение и какие данные могут его изменить?
- 95
Региональный дефицит capacity выводит 600 инстансов EC2; recovery Auto Scaling group запрашивает 600 c7i.4xlarge, но в региональном quota Standard On-Demand vCPU свободно лишь 240 vCPU, и запуски падают с VcpuLimitExceeded. Как вы локализуете quota-инцидент и ограничите восстановление?
scalingcapacitycompute - 96
Control Tower обнаруживает 186 drifted resources в 42 из 500 аккаунтов после обновления landing zone; 17 обязательных log buckets перешли с требуемого SSE-KMS на default SSE-S3 и получили 2,8 миллиона объектов, 9 controls отключены, а vending создает 12 аккаунтов в час. Что вы остановите и как восстановите governance?
iacawslanding-zone - 97
Внешний аудит PCI через 72 часа, но Security Hub показывает 1 840 failed controls в 230 аккаунтах; 93% пришли из нового стандарта, 14 раскрывают пути к card data, а automation падает в 6%. Что вы исправите первым и какие данные поддержат compliance?
- 98
Инцидент затрагивает 38% checkout уже 24 минуты; на bridge 46 человек, 7 команд одновременно меняют систему, а клиентские обновления без владельца, пока ошибки растут с 12% до 19%. Как вы возьмете command и какое условие восстановления примените?
incidentsjoins - 99
Инженер middle-уровня предлагает на 15 минут открыть весь ingress security groups для 0.0.0.0/0, чтобы восстановить сервис с 62% timeout; Reachability Analyzer показывает одно отсутствующее правило порта 8443, 12 команд используют VPC, а до RTO осталось 9 минут. Как вы скорректируете решение и безопасно восстановитесь?
resiliencenetworkingmentoring - 100
Авария на 67 минут вызвала неуспешные заказы на $2,4 миллиона; триггером было изменение timeout ALB, но данные показывают задержку alert 19 минут, отсутствие owner rollback и пропуск DR-теста 8 месяцев. Можно профинансировать только 2 действия. Что вы выберете и как проверите recovery capability?
rollbackalertingprioritization