Вопросы на собеседовании: Корпоративный архитектор
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior Enterprise-архитектор.
Смотреть пример резюме: Корпоративный архитектор →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Сначала я создам базовую модель портфеля с оценкой достоверности и только потом предложу волны трансформации.
- Загружу данные CMDB, финансов, IAM и сетевых потоков в LeanIX, затем свяжу каждое приложение с владельцем, годовыми затратами, стадией жизненного цикла и бизнес-способностью.
- Отсортирую 840 записей по затратам и риску, проведу интервью архитекторов только по верхним 200, а для длинного хвоста использую автоматические свидетельства.
- Отмечу факты с высокой, средней или низкой достоверностью и заблокирую вывод из эксплуатации там, где зависимости, хранение данных или идентификация остаются непроверенными.
- Представлю тепловую карту затрат, технического состояния, бизнес-критичности и достоверности, а не ложную точность инвентаризации длиной в год.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы превращать неполные данные портфеля в ограниченные и проверяемые решения без остановки всей работы.
Я буду финансировать целостные результаты бизнес-способностей, а не распределять $40M пропорционально между спонсорами.
- Оценю заявки по влиянию на выручку или затраты, регуляторному сроку, операционному риску, соответствию архитектуре и уверенности в поставке, подкрепив каждый балл метрикой.
- Зарезервирую около $8M на обязательные контроли и устаревание, а остальную работу сравню по NPV с поправкой на риск и стоимости задержки.
- Использую Planview для финансовых сценариев и LeanIX для зависимостей, чтобы заявка на фронтенд за $3M не скрывала обязательное изменение ядра за $6M.
- Представлю финансируемый портфель и границу отсечения, показав изменение выгод и рисков при снижении бюджета до $30M или росте до $50M.
Зачем это спрашивают: Сильный ответ связывает экономику портфеля с архитектурными зависимостями и явно показывает последствия границы финансирования.
Я сделаю даты готовности двух платформ критическим путём продукта и профинансирую их до обещания запуска во всех четырёх регионах.
- Построю одну карту зависимостей, связывающую каждый региональный путь с подключением identity, контрактами данных, сертификацией API, слотами мощности и ответственным владельцем платформы.
- Профинансирую общие компоненты identity и data только под названные региональные релизы с зарезервированной мощностью и датами, принятыми обеими командами.
- Поставлю stop gates на сертификации контрактов, региональном нагрузочном тесте и готовности запуска; пропуск жёсткой зависимости сдвигает регион, а не создаёт неутверждённый обход.
- Буду пересматривать критический путь каждые две недели и показывать спонсору, какую дату выручки, объём или дополнительную мощность нужно изменить при срыве обязательства платформы.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы превратить дефицит общей платформенной мощности в финансируемый критический путь с реальными stop-решениями.
Я свяжу 47 систем с потоком создания ценности онбординга и профинансирую узкие места, формирующие 18-дневный срок.
- Использую представления способностей и value stream в ArchiMate, чтобы связать этапы пути с приложениями, владельцами данных, ручными передачами и годовыми затратами.
- Измерю время в очереди и переделки на каждом этапе, что может показать меньшую важность двухдневного кредитного решения по сравнению с девятью днями ожидания проверки документов.
- Направлю инвестиции в общие способности, например проверку личности и мастер-данные клиентов, вместо независимой замены четырёх порталов дивизионов.
- Зафиксирую базовые значения полного срока, доли автоматической обработки и стоимости онбординга, чтобы дорожная карта отвечала за бизнес-результат, а не за диаграммы.
Зачем это спрашивают: Здесь проверяется, приводят ли модели способностей к измеримым инвестиционным решениям, а не остаются статичной документацией.
Я отделю структурную экономию от равномерного урезания и защищу контроли регулируемых процессов.
- Свяжу контракты и облачные счета с LeanIX, затем сгруппирую дублирующие CRM, отчётные, интеграционные системы и системы управления документами по способностям.
- Сначала рассмотрю контракты с продлением в ближайшие 12 месяцев, приложения с менее чем 50 активными пользователями и технологии без поддержки производителя.
- Проверю каждого кандидата по требованиям хранения, legal hold, разделения обязанностей и непрерывности бизнеса до учёта экономии.
- Покажу финансам валовый потенциал выше $25M, поскольку миграция, расторжение и параллельная эксплуатация снизят чистую экономию первого года к цели $18M.
Зачем это спрашивают: Интервьюер оценивает, умеете ли вы находить достоверную экономию портфеля с учётом стоимости выхода и обязательных контролей.
Я не выдам следующий транш инициативе, которая не попадёт в принадлежащий финансам реестр выгод до заседания комитета.
- Для каждой инициативы зафиксирую baseline, цель, формулу расчёта, источник данных, дату реализации и одного бизнес-владельца, способного изменить процесс, создающий выгоду.
- Разделю денежную экономию, предотвращённые затраты, выручку, снижение риска и сервисные результаты, чтобы несопоставимые обещания не складывались в одно число.
- Буду выдавать финансирование по gates результата: сначала доказанный baseline, затем связанное с инициативой изменение adoption, счёта, длительности процесса или контроля.
- Ежеквартально покажу прогноз и реализованные выгоды отдельно и остановлю либо изменю работу, если владелец не может объяснить отклонение финансовыми данными.
Зачем это спрашивают: Сильный ответ делает выгоды измеримыми и закреплёнными за владельцем до финансирования, а не принимает неподтверждённые обещания roadmap.
Я стандартизирую корпоративные способности и контракты, сохранив обоснованные различия дивизионов за их границами.
- Проведу доменные воркшопы и определю общие bounded contexts Customer, Offer, Order и Fulfillment с одним ответственным владельцем каждого корпоративного контракта.
- Создам целевое представление ArchiMate, разделяющее глобальные платформы и компоненты дивизионов, с причинами вариативности вроде регулирования, канала или задержки.
- Зафиксирую общие идентификацию, схемы событий, наблюдаемость и идентификаторы клиента, но разрешу отдельный движок исполнения заказов при экономическом обосновании.
- Определю трёхлетний переходный путь с измеримыми точками сближения вместо единственной схемы будущего, игнорирующей текущие обязательства.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы создавать согласованность между дивизионами, не подменяя стандартизацию одинаковой реализацией.
Я рассмотрю пятый дивизион как проверку явной модели вариативности, а не выдам общее исключение.
- Разложу бюджет 120 мс между шлюзом, идентификацией, сервисом и данными по данным OpenTelemetry, не предполагая заранее медленную работу общей платформы.
- Оставлю регулируемые записи в локальном регионе, а через корпоративный контракт данных открою только разрешённые агрегаты или токены.
- Расширю эталонную архитектуру региональным паттерном, если его используют минимум два сценария, иначе оформлю ограниченный по времени ADR для дивизиона.
- Пересчитаю стоимость цели, поскольку региональные реплики, управление ключами и поддержка могут добавить $1.2M в год при общей логической архитектуре.
Зачем это спрашивают: Здесь оценивается способность учитывать конкретные ограничения дивизиона через управляемую вариативность и количественную стоимость.
Я временно оставлю мейнфрейм системой учёта за новыми корпоративными контрактами, а не стану ждать полной конвергенции четыре года.
- Размещу версионированные клиентские API за Kong и буду публиковать изменения через Kafka с CDC-инструментом Debezium там, где это допускает семантика транзакций.
- Добавлю anti-corruption layer, чтобы структуры записей COBOL и коды дивизиона не проникали в целевую клиентскую модель.
- Сначала перенесу сценарии с преобладанием чтения, затем буду передавать владение записью по клиентским сегментам с контролями сверки.
- Назначу каждому мосту владельца, предел пропускной способности, условие закрытия и крайнюю дату, чтобы переходная интеграция не стала постоянной.
Зачем это спрашивают: Интервьюер хочет увидеть конкретный мост от ограничений legacy к целевому владению и контроли против его превращения в постоянную архитектуру.
Я спроектирую одну способность с явными уровнями сервиса, а не заставлю каждый дивизион оплачивать 99.99%.
- Определю базовый и критический уровни с конкретными SLO, RTO, RPO, часами поддержки и лимитами транзакций в сервисном контракте.
- Сохраню единые платёжный API и схему событий, но дам критическому уровню мультирегиональное развёртывание и более строгие бюджеты зависимостей.
- Отнесу дополнительную стоимость устойчивости на потребителей критического уровня, сделав видимой премию примерно $2M в год.
- Проверю оба уровня автоматизированными учениями по восстановлению и опубликую расход error budget, чтобы дивизионы выбирали по фактам.
Зачем это спрашивают: Сильный ответ превращает разные потребности дивизионов в общую архитектуру с прозрачными уровнями сервиса и стоимости.
Я перенесу ограниченную часть финансирования из временных проектов в постоянный value stream урегулирования с контролем результатов.
- Сопоставлю путь от регистрации страхового случая до выплаты и назначу одного бизнес-владельца и одного технического владельца всего потока вместо шести локальных спонсоров.
- Дам потоку 12-месячный бюджетный конверт, привязанный к длительности цикла, доле автоматической обработки, потерям и числу обращений клиентов.
- Буду отдельно финансировать общие платформы, используемые более чем тремя потоками, по открытой формуле распределения, а не прятать платформенные затраты в бюджете урегулирования убытков.
- Начну с 20% дискреционных расходов на два квартала, поскольку одновременная смена всех 70 проектов перегрузит финансовые контроли и управление поставкой.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы сделать финансирование value stream рабочим через владение, метрики и контролируемый переход.
Я разделю финансирование идентификации на стратегическую базу и переменную плату по потреблению.
- Профинансирую основные контроли, платформенный инжиниринг и минимальную устойчивость централизованно, поскольку они полезны каждому потоку даже при малом объёме.
- Распределю переменную стоимость по активным идентификаторам, объёму аутентификаций и премиальным функциям вроде step-up verification, используя данные FinOps, а не только численность.
- Опубликую удельные цены и сервисные уровни в Backstage, чтобы поток видел стоимость выбора доступности 99.99% или SMS MFA.
- Буду пересматривать формулу дважды в год, поскольку жёсткий chargeback может подтолкнуть команды к дублирующим решениям идентификации и повысить корпоративный риск.
Зачем это спрашивают: Здесь проверяется, можно ли сделать экономику общей платформы прозрачной без стимулов к архитектурной фрагментации.
Я заменю контроль проектных ворот квартальными результатами и архитектурными ограничителями, а не уберу ответственность.
- Дам каждой способности скользящую дорожную карту с двумя бизнес-метриками, одним SLO надёжности и удельной экономикой вроде стоимости заказа или изменения полиса.
- Буду выделять финансирование ежеквартально по данным OKR, реестра выгод и прогноза поставки вместо отчёта о проценте завершения.
- Потребую ADR и автоматические проверки политик для решений о регулируемых данных, корпоративных контрактах или годовых затратах выше $500K.
- Остановлю или изменю способность после двух кварталов без результата и подтверждённого обучения, сохранив постоянные команды, выполняющие сервисные обязательства.
Зачем это спрашивают: Интервьюер хочет увидеть конкретную операционную модель, сохраняющую контроль руководства при постоянном владении способностью.
Я откажусь от полного комплекта документов TOGAF и попрошу спонсора утвердить четыре результата для решений в пределах 90 дней.
- К 15-му дню выпущу один документ по scope и architecture vision с бизнес-результатами, регулируемыми границами, владельцами решений и явными исключениями из объёма.
- К 45-му дню выпущу одно связанное представление baseline, target и transition только для value streams, систем, данных и зависимостей, меняемых программой $30M.
- К 75-му дню выпущу один roadmap зависимостей и один связанный реестр решений с пакетами работ, рисками, контролями, ADR, владельцами и stop conditions.
- Комитет трансформации подпишет scope на 30-й день и целевые решения на 60-й, а internal audit выборочно проверит трассировку контролей на 90-й день до следующего funding gate; полный каталог ADM и модель всей компании исключены.
Зачем это спрашивают: Интервьюер оценивает, способны ли вы дать твёрдое и проверяемое обязательство на 90 дней, не превращая TOGAF в документооборот.
Я использую официальные строки и столбцы Zachman только для классификации существующих доказательств и выявления существенных пробелов.
- Проиндексирую артефакты по What, How, Where, Who, When и Why в официальных строках Scope Contexts, Business Concepts, System Logic, Technology Physics, Component Assemblies и Operations Instances.
- Начну с 20 регулируемых приложений и свяжу каждый классифицированный артефакт с источником, владельцем, версией, контролем и доказательством хранения в репозитории.
- Я не буду придумывать перспективы аудитора или оператора, заполнять пустые ячейки догадками или создавать артефакт только ради внешней полноты матрицы.
- Аудиторы проверят выборку к 30-му дню, архитектурный комитет назначит владельцев существенных пробелов к 60-му, а internal audit повторит выборку на 90-й день до масштабирования паттерна.
Зачем это спрашивают: Сильный ответ точно применяет Zachman как схему классификации артефактов с явными audit gates, а не как лекцию о фреймворке или операционную модель.
Я принесу комитету одну рекомендацию и три представления ArchiMate, а не проведу руководство по всему репозиторию.
- В рекомендации укажу выбранную операционную модель, два решающих допущения, измеримый негативный сценарий и решение, которое нельзя делегировать.
- Представление способностей и value stream покажет центральное и дивизионное владение вместе с клиентскими результатами каждого варианта.
- Представление взаимодействия приложений покажет общие платформы, границы доверия и дубли ответственности, а implementation-view покажет зависимости и переходные состояния на 24 месяца.
- Низкоуровневые объекты и незатронутые домены останутся вне scope; комитет решит к 30-му дню, architecture assurance проверит трассу на 60-й, а internal audit выборочно проверит связь решения с контролями на 90-й день до финансирования.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы дать ясную рекомендацию руководству максимум в четырёх результатах и закрепить decision и audit gates.
Я сначала согласую точное значение показателя 50%, а затем сокращу концентрацию в критичных функциях, формирующих этот знаменатель.
- В реестр DORA внесу только договоры с ICT third-party providers вместе с сервисами, локациями, заменяемостью и обязанностями выхода; внутренние зависимости workloads останутся в архитектурном репозитории.
- Совет и risk function подпишут один основной знаменатель, например расходы на провайдера для критичных функций, а долю нагрузок и выручку под риском я покажу отдельно, не смешивая их.
- Перенесу выбранные клиентские или аналитические домены и создам независимо восстанавливаемый путь CI/CD только там, где это существенно снижает согласованный показатель концентрации.
- Ежеквартально пересмотрю подписанные числитель и знаменатель, показывая рядом проверенное восстановление и остаточный ущерб, чтобы косметический перенос workloads не считался compliance.
Зачем это спрашивают: Интервьюер проверяет, применяете ли вы DORA только к ICT third parties и измеряете ли лимит совета через явный и защищаемый знаменатель.
Я согласую требуемый scope выхода с регулятором и буду считать частичные репетиции прогрессом, а не доказательством полного выхода.
- Определю полный тест как согласованные с регулятором критичные пути, объём данных, identity, ключи, операции, RTO, RPO и допустимые деградированные функции для всех сервисов в scope.
- Сначала создам открытые выгрузки, преобразование схем, альтернативную инфраструктуру, внешние runbooks и договорные права для проприетарной БД и другого сложного состояния.
- Проведу последовательные тесты от export и restore к одному пути на 20% объёма, затем ко всему согласованному scope; каждый этап останется частичным до финального упражнения.
- Если стоимость или безопасность не позволяют полный тест, получу явное согласие регулятора на сокращённый scope и остаточный риск, а не назову репетицию 20% полным доказательством выхода.
Зачем это спрашивают: Сильный ответ отличает последовательные доказательства выхода от полного теста и оставляет регулятору решение о любом сокращении scope.
Я назначу уровни непрерывности затронутым путям и проверю выгрузки и ручные режимы до покупки дублирующих SaaS-платформ.
- Свяжу 65% с конкретными пользовательскими путями и классифицирую зависимости identity, CRM и collaboration по максимальному простою, допустимой потере данных и возможной длительности ручной работы.
- Закреплю в контракте проверяемые выгрузки identity, записей CRM, конфигурации и audit evidence с частотой каждого уровня, сохраняя recovery-копии вне границы отказа поставщика.
- Отрепетирую потерю поставщика с break-glass identity, очередью клиентских изменений, утверждёнными offline-контактами и деревом звонков, явно указав пределы по пользователям, странам и времени.
- Повышу уровень при провале recovery target или росте числа критичных путей у одного поставщика; выберу замену или ручной маршрут, если экономика active-active не доказана.
Зачем это спрашивают: Интервьюер оценивает управление концентрацией SaaS через уровни и испытанную непрерывность, а не нереалистичный дизайн дублирующего облака.
Я отклоню универсальную переносимость и подпишу три уровня за десять дней, чтобы 60-дневные доказательства покрывали существенный риск выхода от провайдера.
- Tier 1 охватывает согласованные с регулятором критичные пути и требует проверенного развёртывания, восстанавливаемых данных, внешних ключей и артефактов и названных замен проприетарных сервисов.
- Tier 2 требует проверяемого export и оценённого плана replatform, а Tier 3 может принять lock-in с владельцем, оценкой выхода и trigger пересмотра.
- Product leaders могут оставить native services вне Tier 1, но обязаны показать предотвращённые затраты $8M и риск простоя, принятый бизнес-владельцем риска.
- До встречи с регулятором проверю один путь Tier 1 целиком и честно покажу проваленные контроли; неверная классификация критичного сервиса блокирует его запуск, а не ослабляет уровень.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы к сроку разрешить дорогой спор о переносимости через конкретный scope и последствия ошибки.
Закрытые вопросы
- 21
В вашем technology radar 65 позиций, но команды считают его субъективным и игнорируют; как сделать следующий квартальный радар доказательным?
- 22
Поставщик просит CTO сразу поместить новую generative AI платформу в Adopt после шестинедельного пилота одной команды; какие доказательства вы потребуете?
procurementdecision-making - 23
База данных с отметкой Hold в радаре всё ещё поддерживает 75 приложений, а поддержка производителя закончится через 30 месяцев; как превратить решение радара в действие?
procurementdatabase - 24
Architecture observability для 1 200 сервисов показывает runtime-вызовы, расходящиеся с утверждёнными контрактами и SLO-диаграммами, но команда не хочет очередной очистки CMDB; что вы построите?
sloobservabilityconflict - 25
Эталонная архитектура запрещает прямой доступ к БД между доменами, но 140 команд выпускают сотни изменений в неделю; как реализовать fitness-функцию?
databasearchitecture - 26
Безопасность требует одобренную аутентификацию и TLS для всех 900 API, но ручные архитектурные ревью охватывают только 5% релизов; что вы автоматизируете?
authtlsarchitecture - 27
CTO просит одну ежемесячную метрику здоровья архитектуры для 120 команд; что вы покажете, не создавая vanity score?
monitoring - 28
Центральная архитектура требует один API gateway для пяти дивизионов, но двум регулируемым дивизионам нужны локальные продукты; партнёрский запуск через 60 дней, а ещё месяц спора стоит $3M, кто и что решает?
gatewayapi-gatewayapi - 29
Одной из 110 команд нужно нарушить утверждённый стандарт хранилища данных ради запуска продукта через восемь недель; как сработает процесс исключения?
concurrencyerror-handling - 30
Четыре дивизиона выдают противоречащие друг другу исключения по шифрованию до вступления регуляции через 90 дней; как делегировать решения без четырёх режимов контроля?
encryptionerror-handlingdelegation - 31
Два архитектора дивизионов спорят о владении доменом Customer, задержав общую платформу на три месяца; как вы разрешите решение по дизайну?
conflictownershipdesign - 32
До начала разработки внутренняя платформа просит $12M для 120 команд, но adoption подтвердили только 25; какое решение по финансированию вы примете?
decision-making - 33
Платёжный API нужно запустить через 75 дней на Java, .NET и Node.js; security требует единый обязательный framework, владельцы стеков оценивают rewrite в $2M, а пробел контроля остановит запуск, что вы стандартизируете?
estimationapi - 34
До запуска platform golden path для 70 команд исследование показывает, что 80% подтверждённого спроса приходится на три типа workloads; какие архетипы и non-goals вы выберете?
- 35
Ритейлер хочет заменить монолитный commerce suite до роста лицензии на $7M через 30 месяцев; как спроектировать композируемую цель?
monolithdesignmicroservices - 36
Предложение композируемой страховой платформы содержит 38 независимо развёртываемых компонентов для восьми команд; как понять, что декомпозиция избыточна?
componentsdeployment - 37
API композируемой платформы поставщика требуют его workflow engine и проприетарный формат событий для каждого компонента; как оценить lock-in до покупки за $15M?
procurementcomponentsapi - 38
У предприятия 17 ESB, 2 400 point-to-point интерфейсов и пятилетнее окно модернизации; какую цель integration mesh вы предложите?
types - 39
Шесть доменов публикуют 300 событий, но потребители не знают, какие из них авторитетны, а ломающие изменения происходят часто; как управлять enterprise event mesh?
versioning - 40
Логистической компании нужно связать 200 современных API, 600 ночных файлов и 40 партнёрских EDI-каналов; как избежать единственного паттерна интеграции?
api - 41
Пять дивизионов предлагают 30 data products, но бюджет следующего года поддержит только восемь; как выбрать продукты для финансирования?
- 42
Data product Customer обслуживает 35 команд, но каждая по-разному определяет активного клиента; как задать контракт без централизации всех аналитических определений?
- 43
В глобальном федеративном data catalog конфликтуют классификации 400 наборов в регионах ЕС, США и Сингапура; как установить authority без переноса raw data?
classificationcloud-regions - 44
Компания может приобрести платёжную фирму за $600M со 180 приложениями, 70 инженерами и шестилетней PCI-платформой; какой архитектурный due diligence вы проведёте за четыре недели?
architecture - 45
Поглощение уже завершено, а соглашение о переходных услугах для identity, сети и файлового обмена истекает через 120 дней; от него зависят 2 400 пользователей и 35 приложений. Как выстроить выход к Day 120?
- 46
Нужно выстроить очерёдность портфеля модернизации за $35M, охватывающего мейнфрейм, 14 интеграционных узлов и 220 приложений за три года; с чего начать?
- 47
Предложение модернизации за $50M обещает экономию $18M в год, но требует четырёх лет параллельной эксплуатации 300 приложений; как проверить бизнес-кейс?
budgetpromises - 48
Финансовая платформа должна обслуживать клиентов ЕС и Ближнего Востока, хранить регулируемые записи в регионе и обеспечивать общегрупповое выявление мошенничества за пять минут; какую архитектуру предложить?
cloud-regions - 49
Шесть проектных продуктовых команд передают свои сервисы центральной операционной группе; lead time изменения равен 21 дню, а 40% инцидентов severity 1 связаны с передачей владения. Как вы перестроите продуктовую операционную модель?
incidentsownershipseverity-priority - 50
Исполнительный комитет выбирает модернизацию платформы заказов: сдерживание за $12M, поэтапную замену за $28M или полную трансформацию за $46M; как представить выбор?
- 51
После поглощения у компании стоимостью $6 млрд остаются три ERP-платформы в 42 странах; дубли поставщиков вызывают расхождение в 7% счетов, но до Day 1 осталось 90 дней и приём заказов нельзя останавливать. Что вы сделаете в первую очередь?
- 52
У двух объединившихся компаний 85 000 сотрудников в Okta и Microsoft Entra ID; среди 1 400 дублирующихся identity есть 63 привилегированные, а на устранение нарушения SOX дано 30 дней без массового сброса паролей. Как вы отреагируете?
passwords - 53
После слияния отчёт о выручке для совета различается на 11% между тремя lakehouse, региональные raw data должны оставаться локально, а подписанный отчёт нужен через 60 дней; что вы сделаете?
cloud-regions - 54
После поглощения найдены 1 400 приложений, два стека идентификации, три ERP и четыре аналитические платформы; руководство ждёт $12 млн ежегодной синергии через 18 месяцев, но бюджет интеграции первого года ограничен $4 млн, а бизнес-подразделения отвергают big bang. Как вы выстроите порядок работ?
- 55
Четырёхчасовой сбой AWS us-east-1 отключает сервисы, отвечающие за 70% выручки; переключение Route 53 работает, но вторичная база отстаёт на 47 минут, договорный RTO равен 30 минутам, а дубли платежей недопустимы. Что вы измените?
databasefailover - 56
Сбой control plane Azure блокирует развёртывания и ротацию секретов для 900 приложений, хотя запущенные нагрузки продолжают работать; контракты с доступностью 99,95% под угрозой, но у вас только шесть месяцев и $2 млн, чего недостаточно для переноса всего во второе облако. Что вы профинансируете?
secretsdeployment - 57
Учение по аварийному восстановлению показывает, что второе облако выдерживает лишь 15% сезонного пика в 4 раза выше нормы для 240 сервисов; совет директоров требует мультиоблачной устойчивости за 90 дней, но в платформенной команде 12 инженеров и нет бюджета на двойную работу всех нагрузок. Как вы пересмотрите обязательство?
multi-cloud - 58
Облачная миграция стоимостью $30 млн отстаёт на девять месяцев, израсходовала 70% бюджета, перенесла только 35% из 320 приложений и увеличила удельную стоимость облака на 22%; совет ждёт решение по восстановлению за две недели, а аренда ЦОДа заканчивается через 12 месяцев. Что вы рекомендуете?
migrationscloud-migration - 59
До регуляторного выхода из ЦОДа шесть месяцев, но запланированная волна из 40 приложений превышает доступную мощность поставки на 18 приложений, а продление аренды влечёт штраф $1M. Как вы перепланируете портфель?
capacity - 60
В модернизации стоимостью $30 млн системный интегратор сообщает о 80% готовности, но репозитории и production подтверждают 45%; осталось $3 млн и два квартала, а смена подрядчика займёт восемь недель. Как выбрать между восстановлением и расторжением?
procurementsystem-design - 61
При глобальном переходе на SAP S/4HANA в 28 странах сверка запасов через четыре часа расходится на 2,4%; магазины откроются через шесть часов, точка rollback истекает через 90 минут, а приём заказов должен оставаться доступным. Вы откатитесь?
rollbackreact - 62
Через семь часов после запуска ERP банковский интерфейс создаёт дубли payment instructions для 18 000 обязательств по счетам; rollback удалит 120 000 корректных заказов, до обязательного закрытия 36 часов, а банк может приостановить settlement лишь на два часа. Каков ваш план сдерживания?
rollbacktypes - 63
Второй ERP cutover назначен через 45 дней после того, как устаревшие mappings сломали 17 из 300 интерфейсов; годовое закрытие нельзя перенести, как сертифицировать интерфейсы до повтора?
resiliencetypes - 64
Security-релиз меняет REST-ответ для 40 команд-потребителей при 12 000 запросов в секунду; errors растут до 35%, rollback снова откроет критичную уязвимость, а полного списка consumers нет. Что вы сделаете в первый час?
restvulnerabilitiesrollback - 65
Kafka producer добавляет enum value, которое ломает 40 consumers при 8 млн событий в минуту; lag достигает 90 минут, а privacy rules запрещают replay raw PII через 24 часа. Как вы восстановитесь?
piikafkaconcurrency - 66
EOL поставщика заставляет отключить контракт API через 60 дней для 40 потребителей, но в Backstage указаны только 28 владельцев, а старый шлюз нельзя использовать после срока; клиентский трафик равен 6 000 запросов в секунду, параллельная работа ограничена 30 днями. Как провести безопасную миграцию?
procurementapigateway - 67
Согласованный с аудитом scope требует за 90 дней межсервисного шифрования для 24 регулируемых сервисов и их путей; всего существует 80 команд, adoption Istio равен 18%, а платформа поддерживает десять команд в месяц. Что вы измените без пересмотра scope?
encryptiondecision-making - 68
У шести архитекторов накопилось 120 архитектурных ревью с ожиданием семь недель, что задерживает 30 продуктовых команд; регулятор требует независимого ревью для высокорисковых изменений, но найм заморожен на два квартала. Как разблокировать поставку?
backlogarchitecture - 69
Новый корпоративный стандарт шифрования повышает p99 latency на 45% для 30 edge-продуктов и нарушает клиентский SLA 100 мс; до compliance четыре месяца, постоянные исключения запрещены. Какое жёсткое решение вы примете?
encryptionlatency - 70
CASB обнаруживает 3 ТБ клиентских данных в неутверждённой CRM с публичной ссылкой в 12 странах; уведомление об утечке может потребоваться в течение 72 часов, но удаление tenant уничтожит доказательства. Что вы сделаете?
alerting - 71
DLP фиксирует 260 случаев, когда 4 000 сотрудников вставляли исходный код и клиентский текст в публичные генеративные AI-инструменты; поддержка зависит от них во время сезонного пика, а полная блокировка браузера нарушит SLA ответов. Как сдержать риск?
incidents - 72
Обнаружено 900 OAuth-разрешений для 140 неутверждённых SaaS, а токен уволенного сотрудника продолжает выгружать payroll-данные; до закрытия payroll 24 часа, поэтому одновременный отзыв всех разрешений нарушит критичные операции. Какова ваша последовательность?
oauthtokenscloud - 73
Поставщик middleware объявляет EOL через 12 месяцев для платформы, используемой 400 приложениями и клиентскими сервисами с доступностью 99,99%; есть только $6 млн, полный rewrite оценён в $18 млн и три года. Что вы обещаете?
procurementestimationmiddleware - 74
Поставщик payroll SaaS становится неплатёжеспособным, обслуживая 70 000 сотрудников в 18 странах; source escrow отстаёт на шесть месяцев, до payday десять дней, а локальную налоговую отчётность нельзя задержать. Каково ваше первое recovery-решение?
cloud-modelscloud - 75
Проприетарная БД для 60 регулируемых медицинских приложений достигает EOL через девять месяцев; повторная сертификация замены занимает 12 месяцев, поддержку продлить нельзя, а невалидированные изменения остановят поставки. Как закрыть разрыв?
procurementdatabasesoft-skills - 76
Регулятор даёт 120 дней на прекращение передачи raw customer data ЕС в США, но 2 ПБ уже питают глобальный аналитический продукт стоимостью $40M в год; перестроить продукт до срока невозможно. Какое архитектурное решение вы примете?
estimationarchitecture - 77
Новое правило residency требует хранить identity logs шести из 40 стран локально, а SOC нужны 90 дней глобальной истории обнаружения; срок 60 дней, текущий Entra tenant выгружает всё в один US SIEM. Как разрешить конфликт?
estimation - 78
Регулятор требует customer-managed encryption keys через четыре месяца для 900 приложений, но 35 legacy-систем не умеют работать с KMS, а простой свыше 20 минут нарушит обязательства публичного сервиса. Что вы пообещаете регулятору?
encryptionsystem-design - 79
Расходы на облако растут с $3 млн до $6 млн в месяц за три недели без роста трафика; CFO требует немедленной заморозки, но завтра retail-платформа входит в пик 5x, а оплаченные reservations нельзя отменить. Что вы сделаете сегодня?
- 80
В 220 Kubernetes-кластерах простаивает 60% capacity с годовым waste $8M; предыдущий rightsizing вызвал 14 OOM-инцидентов, а finance требует 25% экономии за 90 дней без снижения SLO 99,95%. Как вы поступите?
kubernetesfinopscapacity - 81
Межоблачная репликация 5 млрд событий в день стоит $900 000 в месяц за egress; finance ограничивает сумму $400 000, business требует RPO пять минут, а EU raw events нельзя вывозить из региона. Что вы измените?
replicationcloud-regions - 82
В data mesh опубликовано 24 data products, но девять нарушают freshness SLO, а у семи нет владельцев; через 21 день нужен регуляторный отчёт, зависящий от пяти проблемных продуктов. Как восстановить владение и поставку?
ownershipslo - 83
Домены заказов и возвратов публикуют конфликтующие схемы customer balance для 80 млн записей, создавая ежемесячное расхождение $2M; оба вице-президента отвергают владение другого, до закрытия квартала 14 дней, а central warehouse нельзя перестроить. Что вы решите?
schemawarehousereact - 84
Промосервис прыгает с 2 млн до 80 млн событий Kafka в минуту, циклы retry насыщают 600 интеграций, появляются дубли платёжных запросов; маркетинг отказывается отменять активную кампанию, а принятые заказы нельзя потерять. Как сдержать event storm?
kafkaresilience - 85
Сбой SAP оставляет в очереди 600 ночных файлов и EDI transfers, угрожая экстренным поставкам в 22 странах; до восстановления SAP четыре часа, как контролировать backlog?
backlogdata-structures - 86
Architecture repository импортирует неверный граф зависимостей, и автоматический shutdown plan во время инцидента теперь нацелен на 70 исправных consumers; что вы сделаете?
incidentsarchitecturedependencies - 87
Модернизация стоимостью $18M поставила новые сервисы, но 72% случаев всё ещё проходят ручной workflow, а клиентский cycle time не улучшился; совет проверит adoption через 90 дней, нового бюджета нет. Что вы измените?
decision-making - 88
Трансформация стоимостью $45 млн обещала снизить операционные расходы на 20%, но через 18 месяцев они выросли на 12%; перенесено 110 приложений, отмена угрожает регуляторному этапу через шесть месяцев, а CFO профинансирует лишь один квартал. Что вы предложите?
milestonespromisesresilience - 89
Сорок из 220 приложений запланированы к выводу ради экономии $5 млн в год, но найдено 600 незадокументированных зависимостей Excel и RPA; лицензии продлеваются через 60 дней, а бизнес не примет blackout. Как вывести приложения?
dependenciesexcelconcurrency - 90
На mainframe, запланированном к выводу через 18 месяцев, остаются три приложения и семь лет записей обязательного хранения; поддержка поставщика заканчивается через шесть месяцев, извлечено лишь 92% архива, а аудиторы требуют запись за четыре часа. Что вы сделаете?
procurement - 91
Критическая CVE затрагивает четыре форка бесхозной общей Java-библиотеки аутентификации, которую используют 90 команд, а крайний срок до эксплуатации уязвимости составляет 30 дней. Как вы сдержите риск и выпустите исправление?
estimationauth - 92
Одобренную event platform используют лишь 15% из 300 сервисов, потому что её golden path не поддерживает сообщения SAP и PII, поэтому команды продолжают добавлять point-to-point связи; число интеграционных инцидентов выросло на 35%, руководство отказывается от обязательной миграции. Что вы сделаете?
incidentsmigrationspii - 93
В реестре архитектурных исключений 180 waivers, из них 70 просрочены, а 12 относятся к доступным из интернета системам с критичными уязвимостями; пять архитекторов могут проверить лишь 20 в неделю, аудит начнётся через 30 дней, полное отключение запрещено. Как погасить долг?
system-designvulnerabilitieserror-handling - 94
После поглощения у 160 из 430 архитектурных исключений нет ответственного владельца, а audit evidence нужно через 45 дней; как сделать унаследованную позицию контролей защищаемой?
ownershiparchitectureerror-handling - 95
Executive dashboard показывает 92% architecture compliance для 700 приложений, но команды манипулируют знаменателем, а нерепрезентативный spot check находит 28% нарушений; бонусы зависят от score, отчёт совету нужен через десять дней. Что вы сообщите?
architecture - 96
CEO хочет запуск в шести странах через четыре недели ради контракта $25 млн, но threat model показывает отсутствие трёх критичных контролей в 45 сервисах; задержка потеряет контракт, клиент принимает только одну production-дату. Что вы рекомендуете?
threat-modeling - 97
CFO требует ERP go-live до годового закрытия ради избежания штрафа $2M, но финальная репетиция превышает двухчасовой recovery target на 70 минут, а 6 из 140 финансовых интерфейсов не проходят сверку; до даты пять дней, новая полная репетиция не помещается. Каково ваше go-решение?
reacttypes - 98
Архитектор, которого вы менторите, одобрил синхронную цепочку из 14 сервисов для checkout на 6 000 транзакций в секунду, и она вызвала каскад в Black Friday; RCA нужен через 48 часов, релизы заморожены на семь дней, а архитектора исключили из встреч по инциденту. Что вы сделаете?
mentoringincidentstransactions - 99
После регионального сбоя review показывает, что 150 из 500 сервисов не умеют failover, хотя roadmap финансирует новые продукты на два квартала; запуск назначен через восемь недель, перенаправить можно только $5 млн, договорный RTO равен 45 минутам. Как исправить roadmap?
roadmapincidentscloud-regions - 100
После инцидента в CMDB отсутствуют 220 из 900 приложений, а 30% записей владельцев recovery неверны; следующий сезонный пик начнётся через десять недель, как поддерживать доверие к inventory?
incidentsownership