Спроектируйте landing zone в GCP для 40 инженерных команд, 220 проектов, нагрузок в США и ЕС, SLO платформы 99,95% и выдачи проекта не дольше 30 минут.

Я бы строил landing zone вокруг границ отказа, владения и резидентности, а не слепо копировал организационную структуру. - Bootstrap, security, networking и logging проекты я бы вынес в отдельные платформенные папки, а папки нагрузок разделил по production-статусу и резидентности в США или ЕС. - Project factory создавал бы проекты, API, бюджеты, IAM-группы, подключения Shared VPC, log sinks и базовые политики по одной одобренной заявке менее чем за 30 минут. - Organization Policy и IAM на уровне папок задавали бы defaults, а выдача прав на проекты оставалась узкой, чтобы одна команда не администрировала чужую часть из 220 проектов. - Я бы запускал factory и policy checks на отказоустойчивых региональных runners, измерял успешность и возраст provisioning и держал документированный ручной путь для SLO 99,95%.

Как бы вы спроектировали Shared VPC для 90 service projects в трех регионах, 20 команд, SLO сети 99,99% и on-premises сети, занимающей 10.0.0.0/8 еще 12 месяцев?

Я бы использовал несколько ограниченных доменов Shared VPC, а не превращал один host project в общий blast radius компании. - Отдельные host projects для production, nonproduction и регулируемых нагрузок владели бы региональными подсетями, Cloud Routers, NAT, firewall policy и connectivity, а изменения требовали бы участия двух платформенных команд. - IAM на уровне подсетей разрешал бы группам service projects использовать только назначенные primary и secondary ranges, а центральный IPAM предотвращал бы пересечения во всех 90 проектах. - Я бы резервировал privately used ranges вне RFC1918 или транслировал конфликтующие маршруты 10.0.0.0/8 на гибридной границе до завершения перенумерации on-premises. - Региональные пути, резервные Cloud Routers, flow logs, quota alerts и синтетические проверки достижимости сделали бы SLO 99,99% измеримым, а не предполагаемым.

Спроектируйте изоляцию SaaS-платформы с 12 000 tenants, 60 регулируемыми enterprise tenants, тремя обслуживающими регионами, SLO 99,95% и лимитом не более 2% общей мощности на одного tenant.

Я бы использовал модель cells с общим размещением по умолчанию и выделенными cells для 60 tenants, которым нужна жесткая граница. - Каждая региональная общая cell обслуживала бы примерно до 500 tenants и имела собственные GKE или Cloud Run compute, data partition, service accounts, quotas и failure budget. - Регулируемые tenants получали бы отдельные проекты и data stores, когда этого требует контрактная изоляция, а единые API платформы сохраняли бы одинаковую эксплуатацию. - Tenant identity передавалась бы в подписанных claims и повторно проверялась на уровне данных, а per-tenant rate limits не позволяли бы превысить 2% мощности cell. - Глобальные placement metadata направляли бы tenant в его домашний регион, а проверенная эвакуация cell и ограниченная репликация поддерживали бы SLO 99,95% без глобализации данных.

Как бы вы управляли политиками в 300 GCP-проектах и шести регионах, если опасные конфигурации нужно блокировать в течение часа, обычные проекты запускать за 48 часов, а исключения должны истекать через 30 дней?

Я бы сделал централизованно наследуемые preventive controls настройкой по умолчанию, а каждое исключение оформлял как код с истечением срока. - Organization Policy блокировала бы service account keys, неодобренные регионы, public IP и unrestricted sharing на уровне организации или папки, а custom constraints закрывали бы пробелы managed constraints. - Проверки Terraform plan и policy tests останавливали бы изменения до apply, а запросы Cloud Asset Inventory находили бы ресурсы вне одобренного пути в часовом контрольном окне. - Workflow исключений требовал бы владельца, риск, компенсирующий контроль и expiry, затем помещал workload в узкую папку или правило по tag не более чем на 30 дней. - Наборы политик проходили бы тесты в staging folder до продвижения, а шаблоны project factory удерживали бы compliant delivery заметно внутри 48 часов.

Спроектируйте распределение затрат и chargeback для 240 проектов, 30 команд и ежемесячных расходов GCP в $1,8 млн, если 95% затрат нужно назначить к третьему рабочему дню, а общие расходы платформы удержать ниже 12%.

Я бы сделал владельца затрат обязательной частью создания проекта и рассчитывал chargeback из detailed billing export. - Каждый проект имел бы проверенные metadata cost center, product, environment и owner, а resource hierarchy служила бы fallback, когда сервис не сохраняет labels. - Detailed billing export в BigQuery сначала распределял бы прямые расходы, затем Shared VPC, observability и support по измеряемому потреблению, например bytes, vCPU-hours или active services. - Reservations и committed use discounts амортизировались бы на их пользователей, а не зачислялись только billing account, чтобы unit cost оставался экономически честным. - Ежедневные dashboards отслеживали бы unallocated spend, team budgets, forecasts и долю платформы 12%, а alerts первого дня оставляли бы два дня на устранение пробелов.

Спроектируйте глобальную доставку для retail-сайта с 150 000 запросов в секунду из четырех origins, p95 ниже 250 мс, SLO 99,99% и edge-бюджетом $120 000 в месяц.

Я бы поставил один global external Application Load Balancer перед региональными origins и включил поведение cache в расчет мощности. - Cloud CDN кэшировал бы versioned static assets и безопасные API-ответы с явными cache keys и TTL, достигая origin offload ratio, совместимого с бюджетом $120 000. - Cloud Armor применял бы managed WAF rules, adaptive protection, rate limits и bot controls до попадания трафика в четыре origins. - Региональные backends публиковали бы health checks и имели warm capacity на потерю одного региона, а weighted routing поддерживал бы canary без DNS cutover. - Edge, cache, Armor и origin latency имели бы отдельные SLI, а синтетические проверки с ключевых рынков контролировали бы p95 250 мс и SLO 99,99%.

Спроектируйте гибридное подключение двух data centers к GCP для постоянного трафика 20 Гбит/с, p95 сетевой задержки ниже 20 мс, доступности 99,99% и восстановления маршрутов за пять минут.

Я бы использовал Dedicated Cloud Interconnect как основной путь, а HA VPN только как аварийный путь меньшей мощности. - Для топологии с доступностью 99,99% я бы создал четыре Interconnect connections в двух metropolitan areas, разместил две connections каждого metro в разных edge availability domains и создал по одному VLAN attachment на каждой connection. - Раздельные Cloud Routers, customer routers, питание и carrier paths устраняли бы общие точки отказа, а BGP priorities и проверенное обнаружение отказа обеспечивали бы восстановление быстрее пяти минут. - HA VPN сохранял бы control и critical traffic при более широком отказе Interconnect, но не рассчитывался и не описывался бы как путь для всего постоянного потока 20 Гбит/с. - Каждый attachment в норме оставался бы ниже 50% utilization, а тесты loss, latency, learned routes и отказа всех четырех путей доказывали бы capacity и availability.

Как бы вы построили hub-and-spoke сеть для 35 VPC, 12 on-premises сегментов и трех регионов GCP, если app spokes не должны общаться транзитивно, а сходимость маршрутов должна быть меньше двух минут?

Я бы использовал глобальную модель hub в NCC и явно задал trust boundaries вместо выдуманных regional hubs. - Hub NCC является глобальным; для trust domains, которые никогда не должны обмениваться routes, я бы использовал отдельные hubs, а внутри hub разделял production, nonproduction и regulated connectivity через route tables и spoke groups. - Региональными компонентами были бы Cloud Routers, VLAN attachments, HA VPN tunnels и regional hybrid spokes, тогда как VPC spokes подключали бы сети к глобальному control plane. - Import и export rules разрешали бы app spokes достигать общих inspection, DNS и одобренных on-premises prefixes без получения routes других app spokes. - Резервные regional attachments, summarized advertisements, route-diff tests, Connectivity Tests и convergence probes проверяли бы двухминутную цель.

Спроектируйте публикацию через Private Service Connect для payments API, который используют 40 проектов, с 20 000 запросов в секунду в трех регионах, p99 ниже 100 мс, SLO 99,99% и без VPC peering.

Я бы публиковал по одному региональному service attachment на serving region и выдавал каждому consumer private endpoint в его VPC. - Региональные producer backends за поддерживаемыми internal load balancers масштабировались бы независимо, а consumer никогда не получал бы маршруты producer VPC. - Connection preferences, project allowlists, endpoint quotas и выделенные NAT subnets контролировали бы подключение 40 проектов и делали каждого consumer видимым. - Private DNS возвращал бы endpoint региона consumer, а клиенты повторяли бы запрос в другой опубликованный регион только в рамках idempotency-контракта payments API. - Connection count, rejections, latency и regional capacity по каждому endpoint измерялись бы против p99 100 мс и рассчитывались на потерю одного региона.

Спроектируйте DNS для 300 private zones, 50 VPC и двух on-premises data centers с SLO разрешения 99,99% и восстановлением после потери forwarding path за пять минут.

Я бы централизовал пути hybrid resolution, сохранив явное владение authoritative zones и split-horizon behavior. - Cloud DNS private zones связывались бы только с разрешенными VPC, а DNS peering публиковал бы central service zones без копирования 300 zones. - Inbound forwarding endpoints обслуживали бы запросы on-premises, а outbound forwarding policies направляли бы corporate suffixes на резервные resolvers в обоих data centers. - Conditional rules имели бы одного владельца и не создавали circular forwarding, а response policies использовались бы для контролируемых overrides, не для случайных записей. - Query logs, synthetic lookups, resolver health и проверенный secondary forwarding route обеспечивали бы SLO 99,99% и пятиминутное восстановление.

Спроектируйте контролируемый egress для 10 000 workloads в 200 проектах, с PCI-сегментацией, пиком 25 Гбит/с, 500 одобренными web domains и бюджетом сетевой безопасности $80 000 в месяц.

Я бы оставил private traffic к Google APIs вне интернета и применял egress controls по протоколу, не считая Cloud NAT фильтром. - Private Google Access или endpoints Private Service Connect достигали бы поддерживаемых Google APIs, Secure Web Proxy применял бы политику 500 HTTP и HTTPS domains, а Cloud NGFW или одобренные appliances проверяли бы нужные non-web flows. - Cloud NAT является региональным распределенным managed data plane без зонального gateway для шардирования и без фиксированного потолка throughput gateway; путь 25 Гбит/с все равно ограничивают bandwidth VM и network interfaces. - Число reserved external IPs и minimum или maximum ports на VM я бы рассчитал по пиковому числу concurrent endpoints, скорости открытия connections, destination fan-out, protocol timeouts, требованиям endpoint-independent mapping и региональным квотам адресов и NAT. - NAT, proxy, firewall и flow telemetry отслеживали бы allocation failures, ports per VM, connection rate, bytes, blocked flows и inspection cost относительно бюджета $80 000.

Спроектируйте региональный GKE fleet для 180 сервисов в трех регионах, 20 deploy в день, serving SLO 99,99%, RTO 10 минут и RPO ноль для принятых запросов.

Я бы запустил независимый regional cluster в каждом регионе и добавил явные fleet services вместо предположения, что их дает registration. - Fleet Workload Identity задавала бы общую workload identity, а Config Sync и Policy Controller распространяли бы configuration и применяли policies во всех трех clusters. - Multi Cluster Services публиковал бы service discovery, а Multi Cluster Gateway программировал бы глобальную traffic surface; одна fleet registration не дает этих runtime guarantees. - Сервисы использовали бы один immutable artifact и contract с regional values только для endpoints, capacity и residency, а каждый surviving region держал бы проверенный failover headroom. - Принятые writes фиксировались бы в datastore с RPO ноль до ответа об успехе, а квартальные тесты отключения региона проверяли бы Multi Cluster Gateway и RTO 10 минут независимо от ремонта Kubernetes.

Выберите GKE Standard или Autopilot для 70 stateless-сервисов 25 команд, с восьмикратными пиками трафика, SLO 99,9%, бюджетом $90 000 в месяц и шестью privileged node agents, которые нельзя убрать.

Я бы предложил Autopilot как workload tier по умолчанию и меньший Standard tier для шести исключений с privileged agents. - Autopilot снимает администрирование nodes и тарифицирует запрошенные pod resources, что подходит 70 stateless-сервисам при настроенных requests, concurrency и startup time. - Standard clusters принимали бы workloads, которым действительно нужны privileged node access, custom node configuration или capacity controls вне стандартной operating model Autopilot. - Оба tiers имели бы общие artifact, identity, policy, observability и deployment interfaces, чтобы команды не строили две несвязанные платформы. - Я бы ежемесячно сравнивал cost per request и выполнение SLO, потому что завышенные requests в Autopilot и idle nodes в Standard одинаково могут нарушить бюджет $90 000.

Стали бы вы внедрять GKE Enterprise для 12 GKE clusters и четырех on-premises Kubernetes clusters в шести регионах, если policy drift нужно исправлять за 15 минут, а дополнительные расходы платформы ограничены $40 000 в месяц?

Я бы внедрил GKE Enterprise только в том случае, если его fleet governance заменит достаточно отдельных инструментов и труда для оправдания лимита $40 000. - Fleet membership, Config Sync, Policy Controller и Cloud Service Mesh оценивались бы на сценариях configuration и policy для 16 clusters, а не покупались ради названия. - Я бы провел pilot на двух clusters и измерил convergence конфигурации до 15 минут, policy coverage, upgrade effort и поведение при потере on-premises connectivity. - Workload portability оставалась бы на Kubernetes APIs и Git, а Google-specific fleet features скрывались бы за документированными platform contracts. - Decision gate сравнивал бы лицензии и operations cost с текущим stack, и я бы отказался от пакета без улучшения governance SLO или итоговой стоимости.

Спроектируйте service mesh для 120 сервисов в четырех GKE clusters, 60 000 запросов в секунду, обязательного mTLS, SLO 99,99% и не более 15 мс дополнительной p99 latency.

Я бы использовал managed Cloud Service Mesh с узким baseline traffic policies и доказал стоимость data plane до широкого rollout. - Fleet-wide workload identity и strict mTLS заменяли бы общие certificates, а authorization policies привязывались бы к service identities, не к pod IP. - Timeouts, retries и circuit breaking задавались бы по dependency, а retry budgets не давали бы отказавшему сервису умножить 60 000 запросов в секунду. - Sidecar CPU, memory, connection pools и telemetry sampling проходили бы load tests, чтобы overhead mesh укладывался в 15 мс p99. - Я бы подключал mesh canary по namespace и сохранял прямой rollback, а здоровье control plane и proxies стало бы явной частью SLO 99,99%.

Спроектируйте multi-cluster ingress для трех региональных GKE clusters с 100 000 запросов в секунду, целью regional failover пять минут, canary 5%, без session affinity и с SLO 99,99%.

Я бы использовал GKE multi-cluster Gateway для программирования единой global load-balancing surface через fleet-aware ресурсы Gateway API. - Multi-cluster Services публиковали бы одинаковые backends из всех трех clusters, а health checks и service capacity задавались бы независимо по регионам. - Weights в HTTPRoute направляли бы 5% на canary backend, а immutable releases позволяли бы мгновенно откатить route weight без изменения DNS. - Отказ от session affinity делал бы запросы переносимыми, а приложения выносили бы session state и применяли idempotency к retries во время regional shift. - Каждая пара оставшихся регионов держала бы failover headroom, а synthetic probes и плановое отключение региона проверяли бы цели пять минут и 99,99%.

Спроектируйте GKE tenancy для 40 команд и 2 000 pods в шести clusters, с изоляцией PCI workloads, onboarding команды за один день и лимитом 5% CPU общего cluster на команду.

Я бы использовал namespaces для обычных команд и dedicated clusters или node boundaries там, где PCI threat model требует более сильной изоляции. - Onboarding workflow создавал бы namespace, bindings Workload Identity Federation, RBAC groups, NetworkPolicies, quotas, limits и observability ownership за один день. - ResourceQuota и admission policy ограничивали бы каждого shared tenant 5% allocatable CPU, пока одобренный capacity request не изменит лимит. - Default-deny east-west networking и service identity не позволяли бы членству в namespace стать неявным доверием между командами. - PCI workloads использовали бы отдельные проекты и clusters при требовании kernel, node или administrator isolation, принимая дополнительную стоимость без преувеличения защиты namespaces.

Спроектируйте upgrades и capacity GKE для восьми clusters на 5 000 vCPU, с завершением upgrades за 30 дней, SLO 99,95%, экономией compute 35% и переживанием потери одной zone вместе с Spot eviction.

Я бы отделил покрытие цены от гарантии capacity и держал надежную on-demand базу под слоем Spot. - Release channels, maintenance windows, проверки version skew и canary cluster продвигали бы upgrades через nonproduction и production внутри 30 дней. - Regional clusters, topology spread, PodDisruptionBudgets и controlled surge upgrades сохраняли бы replicas во время drain зоны или node pool. - Eligible baseline usage получал бы committed use discounts для снижения цены, но capacity после потери одной зоны обеспечивали бы zonal reservations для critical node pools; CUD сам по себе capacity не резервирует. - Spot pools принимали бы только checkpointable или overprovisioned work, а rightsizing, reservation coverage, disruption tests и unit cost доказывали бы экономию 35% без нарушения 99,95%.

Спроектируйте платформу Cloud Run для 80 сервисов и 30 команд, обслуживающую 60 000 запросов в секунду с p99 ниже 300 мс, SLO 99,95% и compute-бюджетом $70 000 в месяц.

Я бы стандартизировал regional Cloud Run service contract и поставил multi-region services за global external Application Load Balancer. - Шаблон задавал бы service identity, ingress, secrets, CPU, memory, concurrency, maximum instances, logging и deploy policy, не открывая все настройки 30 командам. - Latency-sensitive services держали бы измеренное число minimum instances, а development и tolerant services масштабировались бы до нуля для защиты бюджета $70 000. - Maximum instances и concurrency с учетом downstream не позволяли бы пику 60 000 запросов в секунду исчерпать databases или regional quotas. - Per-revision latency, cold starts, saturation, cost per request и regional health управляли бы gradual rollout и SLO 99,95%.

Спроектируйте event platform для двух миллионов ежедневных Storage, audit и custom events на Eventarc и Cloud Run functions, с p95 завершения ниже 30 секунд, retries в течение 24 часов и без повторного создания invoice.

Я бы нормализовал каждый source как CloudEvent и сделал эффект invoice идемпотентным за пределами delivery semantics trigger. - Eventarc filters направляли бы узкие event types в небольшие Cloud Run functions или services с отдельными identities вместо одного универсального handler. - Critical flows, которым нужны управляемые retention, dead letters или replay, проходили бы через явные Pub/Sub topic и subscription, а не зависели только от direct trigger. - Handler занимал бы immutable event ID в transactional invoice ledger до создания invoice, поэтому retries не повторяли бы бизнес-эффект. - Event age, retry count, dead-letter volume и end-to-end p95 отслеживались бы, а retention и replay за 24 часа тестировались бы на разных schema versions.

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

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

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

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

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

Вопросы

designslo

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

Bootstrap, security, networking и logging проекты я бы вынес в отдельные платформенные папки, а папки нагрузок разделил по production-статусу и резидентности в США или ЕС.
Project factory создавал бы проекты, API, бюджеты, IAM-группы, подключения Shared VPC, log sinks и базовые политики по одной одобренной заявке менее чем за 30 минут.
Organization Policy и IAM на уровне папок задавали бы defaults, а выдача прав на проекты оставалась узкой, чтобы одна команда не администрировала чужую часть из 220 проектов.
Я бы запускал factory и policy checks на отказоустойчивых региональных runners, измерял успешность и возраст provisioning и держал документированный ручной путь для SLO 99,95%.

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

designslonetworking

Я бы использовал несколько ограниченных доменов Shared VPC, а не превращал один host project в общий blast radius компании.

Отдельные host projects для production, nonproduction и регулируемых нагрузок владели бы региональными подсетями, Cloud Routers, NAT, firewall policy и connectivity, а изменения требовали бы участия двух платформенных команд.
IAM на уровне подсетей разрешал бы группам service projects использовать только назначенные primary и secondary ranges, а центральный IPAM предотвращал бы пересечения во всех 90 проектах.
Я бы резервировал privately used ranges вне RFC1918 или транслировал конфликтующие маршруты 10.0.0.0/8 на гибридной границе до завершения перенумерации on-premises.
Региональные пути, резервные Cloud Routers, flow logs, quota alerts и синтетические проверки достижимости сделали бы SLO 99,99% измеримым, а не предполагаемым.

Зачем это спрашивают: Сильный ответ ограничивает blast radius Shared VPC и решает пересечение адресов без ослабления владения или доступности.

designcapacityslo

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

Каждая региональная общая cell обслуживала бы примерно до 500 tenants и имела собственные GKE или Cloud Run compute, data partition, service accounts, quotas и failure budget.
Регулируемые tenants получали бы отдельные проекты и data stores, когда этого требует контрактная изоляция, а единые API платформы сохраняли бы одинаковую эксплуатацию.
Tenant identity передавалась бы в подписанных claims и повторно проверялась на уровне данных, а per-tenant rate limits не позволяли бы превысить 2% мощности cell.
Глобальные placement metadata направляли бы tenant в его домашний регион, а проверенная эвакуация cell и ограниченная репликация поддерживали бы SLO 99,95% без глобализации данных.

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

configerror-handling

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

Organization Policy блокировала бы service account keys, неодобренные регионы, public IP и unrestricted sharing на уровне организации или папки, а custom constraints закрывали бы пробелы managed constraints.
Проверки Terraform plan и policy tests останавливали бы изменения до apply, а запросы Cloud Asset Inventory находили бы ресурсы вне одобренного пути в часовом контрольном окне.
Workflow исключений требовал бы владельца, риск, компенсирующий контроль и expiry, затем помещал workload в узкую папку или правило по tag не более чем на 30 дней.
Наборы политик проходили бы тесты в staging folder до продвижения, а шаблоны project factory удерживали бы compliant delivery заметно внутри 48 часов.

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

design

Я бы сделал владельца затрат обязательной частью создания проекта и рассчитывал chargeback из detailed billing export.

Каждый проект имел бы проверенные metadata cost center, product, environment и owner, а resource hierarchy служила бы fallback, когда сервис не сохраняет labels.
Detailed billing export в BigQuery сначала распределял бы прямые расходы, затем Shared VPC, observability и support по измеряемому потреблению, например bytes, vCPU-hours или active services.
Reservations и committed use discounts амортизировались бы на их пользователей, а не зачислялись только billing account, чтобы unit cost оставался экономически честным.
Ежедневные dashboards отслеживали бы unallocated spend, team budgets, forecasts и долю платформы 12%, а alerts первого дня оставляли бы два дня на устранение пробелов.

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

designslolatency

Я бы поставил один global external Application Load Balancer перед региональными origins и включил поведение cache в расчет мощности.

Cloud CDN кэшировал бы versioned static assets и безопасные API-ответы с явными cache keys и TTL, достигая origin offload ratio, совместимого с бюджетом $120 000.
Cloud Armor применял бы managed WAF rules, adaptive protection, rate limits и bot controls до попадания трафика в четыре origins.
Региональные backends публиковали бы health checks и имели warm capacity на потерю одного региона, а weighted routing поддерживал бы canary без DNS cutover.
Edge, cache, Armor и origin latency имели бы отдельные SLI, а синтетические проверки с ключевых рынков контролировали бы p95 250 мс и SLO 99,99%.

Зачем это спрашивают: Интервьюер оценивает, как load balancing, caching, security, failover capacity и стоимость соединяются в одном дизайне глобального трафика.

designlatency

Я бы использовал Dedicated Cloud Interconnect как основной путь, а HA VPN только как аварийный путь меньшей мощности.

Для топологии с доступностью 99,99% я бы создал четыре Interconnect connections в двух metropolitan areas, разместил две connections каждого metro в разных edge availability domains и создал по одному VLAN attachment на каждой connection.
Раздельные Cloud Routers, customer routers, питание и carrier paths устраняли бы общие точки отказа, а BGP priorities и проверенное обнаружение отказа обеспечивали бы восстановление быстрее пяти минут.
HA VPN сохранял бы control и critical traffic при более широком отказе Interconnect, но не рассчитывался и не описывался бы как путь для всего постоянного потока 20 Гбит/с.
Каждый attachment в норме оставался бы ниже 50% utilization, а тесты loss, latency, learned routes и отказа всех четырех путей доказывали бы capacity и availability.

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

communication

Я бы использовал глобальную модель hub в NCC и явно задал trust boundaries вместо выдуманных regional hubs.

Hub NCC является глобальным; для trust domains, которые никогда не должны обмениваться routes, я бы использовал отдельные hubs, а внутри hub разделял production, nonproduction и regulated connectivity через route tables и spoke groups.
Региональными компонентами были бы Cloud Routers, VLAN attachments, HA VPN tunnels и regional hybrid spokes, тогда как VPC spokes подключали бы сети к глобальному control plane.
Import и export rules разрешали бы app spokes достигать общих inspection, DNS и одобренных on-premises prefixes без получения routes других app spokes.
Резервные regional attachments, summarized advertisements, route-diff tests, Connectivity Tests и convergence probes проверяли бы двухминутную цель.

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

designslonetworking

Я бы публиковал по одному региональному service attachment на serving region и выдавал каждому consumer private endpoint в его VPC.

Региональные producer backends за поддерживаемыми internal load balancers масштабировались бы независимо, а consumer никогда не получал бы маршруты producer VPC.
Connection preferences, project allowlists, endpoint quotas и выделенные NAT subnets контролировали бы подключение 40 проектов и делали каждого consumer видимым.
Private DNS возвращал бы endpoint региона consumer, а клиенты повторяли бы запрос в другой опубликованный регион только в рамках idempotency-контракта payments API.
Connection count, rejections, latency и regional capacity по каждому endpoint измерялись бы против p99 100 мс и рассчитывались на потерю одного региона.

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

designdnsslo

Я бы централизовал пути hybrid resolution, сохранив явное владение authoritative zones и split-horizon behavior.

Cloud DNS private zones связывались бы только с разрешенными VPC, а DNS peering публиковал бы central service zones без копирования 300 zones.
Inbound forwarding endpoints обслуживали бы запросы on-premises, а outbound forwarding policies направляли бы corporate suffixes на резервные resolvers в обоих data centers.
Conditional rules имели бы одного владельца и не создавали circular forwarding, а response policies использовались бы для контролируемых overrides, не для случайных записей.
Query logs, synthetic lookups, resolver health и проверенный secondary forwarding route обеспечивали бы SLO 99,99% и пятиминутное восстановление.

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

formsdesign

Я бы оставил private traffic к Google APIs вне интернета и применял egress controls по протоколу, не считая Cloud NAT фильтром.

Private Google Access или endpoints Private Service Connect достигали бы поддерживаемых Google APIs, Secure Web Proxy применял бы политику 500 HTTP и HTTPS domains, а Cloud NGFW или одобренные appliances проверяли бы нужные non-web flows.
Cloud NAT является региональным распределенным managed data plane без зонального gateway для шардирования и без фиксированного потолка throughput gateway; путь 25 Гбит/с все равно ограничивают bandwidth VM и network interfaces.
Число reserved external IPs и minimum или maximum ports на VM я бы рассчитал по пиковому числу concurrent endpoints, скорости открытия connections, destination fan-out, protocol timeouts, требованиям endpoint-independent mapping и региональным квотам адресов и NAT.
NAT, proxy, firewall и flow telemetry отслеживали бы allocation failures, ports per VM, connection rate, bytes, blocked flows и inspection cost относительно бюджета $80 000.

Зачем это спрашивают: Интервьюер ждет protocol-aware egress controls, private API access, масштабируемый NAT и правдоподобную модель стоимости.

deploymentkubernetesdesign

Я бы запустил независимый regional cluster в каждом регионе и добавил явные fleet services вместо предположения, что их дает registration.

Fleet Workload Identity задавала бы общую workload identity, а Config Sync и Policy Controller распространяли бы configuration и применяли policies во всех трех clusters.
Multi Cluster Services публиковал бы service discovery, а Multi Cluster Gateway программировал бы глобальную traffic surface; одна fleet registration не дает этих runtime guarantees.
Сервисы использовали бы один immutable artifact и contract с regional values только для endpoints, capacity и residency, а каждый surviving region держал бы проверенный failover headroom.
Принятые writes фиксировались бы в datastore с RPO ноль до ответа об успехе, а квартальные тесты отключения региона проверяли бы Multi Cluster Gateway и RTO 10 минут независимо от ремонта Kubernetes.

Зачем это спрашивают: Интервьюер проверяет, отделяет ли fleet design региональный stateless compute от гарантий данных, стоящих за RTO и RPO.

kubernetesslo

Я бы предложил Autopilot как workload tier по умолчанию и меньший Standard tier для шести исключений с privileged agents.

Autopilot снимает администрирование nodes и тарифицирует запрошенные pod resources, что подходит 70 stateless-сервисам при настроенных requests, concurrency и startup time.
Standard clusters принимали бы workloads, которым действительно нужны privileged node access, custom node configuration или capacity controls вне стандартной operating model Autopilot.
Оба tiers имели бы общие artifact, identity, policy, observability и deployment interfaces, чтобы команды не строили две несвязанные платформы.
Я бы ежемесячно сравнивал cost per request и выполнение SLO, потому что завышенные requests в Autopilot и idle nodes в Standard одинаково могут нарушить бюджет $90 000.

Зачем это спрашивают: Сильный ответ выбирает платформу по workload и сохраняет единый developer contract для двух operating modes.

kubernetesiacdecision-making

Я бы внедрил GKE Enterprise только в том случае, если его fleet governance заменит достаточно отдельных инструментов и труда для оправдания лимита $40 000.

Fleet membership, Config Sync, Policy Controller и Cloud Service Mesh оценивались бы на сценариях configuration и policy для 16 clusters, а не покупались ради названия.
Я бы провел pilot на двух clusters и измерил convergence конфигурации до 15 минут, policy coverage, upgrade effort и поведение при потере on-premises connectivity.
Workload portability оставалась бы на Kubernetes APIs и Git, а Google-specific fleet features скрывались бы за документированными platform contracts.
Decision gate сравнивал бы лицензии и operations cost с текущим stack, и я бы отказался от пакета без улучшения governance SLO или итоговой стоимости.

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

designservice-meshslo

Я бы использовал managed Cloud Service Mesh с узким baseline traffic policies и доказал стоимость data plane до широкого rollout.

Fleet-wide workload identity и strict mTLS заменяли бы общие certificates, а authorization policies привязывались бы к service identities, не к pod IP.
Timeouts, retries и circuit breaking задавались бы по dependency, а retry budgets не давали бы отказавшему сервису умножить 60 000 запросов в секунду.
Sidecar CPU, memory, connection pools и telemetry sampling проходили бы load tests, чтобы overhead mesh укладывался в 15 мс p99.
Я бы подключал mesh canary по namespace и сохранял прямой rollback, а здоровье control plane и proxies стало бы явной частью SLO 99,99%.

Зачем это спрашивают: Сильный ответ рассматривает identity, resilience policy, overhead data plane и безопасность rollout как измеримые части service mesh design.

designslodeployment-strategies

Я бы использовал GKE multi-cluster Gateway для программирования единой global load-balancing surface через fleet-aware ресурсы Gateway API.

Multi-cluster Services публиковали бы одинаковые backends из всех трех clusters, а health checks и service capacity задавались бы независимо по регионам.
Weights в HTTPRoute направляли бы 5% на canary backend, а immutable releases позволяли бы мгновенно откатить route weight без изменения DNS.
Отказ от session affinity делал бы запросы переносимыми, а приложения выносили бы session state и применяли idempotency к retries во время regional shift.
Каждая пара оставшихся регионов держала бы failover headroom, а synthetic probes и плановое отключение региона проверяли бы цели пять минут и 99,99%.

Зачем это спрашивают: Интервьюер проверяет, делают ли Gateway API, здоровье backends, statelessness, canary routing и capacity multi-cluster failover реальным.

kubernetesdesignonboarding

Я бы использовал namespaces для обычных команд и dedicated clusters или node boundaries там, где PCI threat model требует более сильной изоляции.

Onboarding workflow создавал бы namespace, bindings Workload Identity Federation, RBAC groups, NetworkPolicies, quotas, limits и observability ownership за один день.
ResourceQuota и admission policy ограничивали бы каждого shared tenant 5% allocatable CPU, пока одобренный capacity request не изменит лимит.
Default-deny east-west networking и service identity не позволяли бы членству в namespace стать неявным доверием между командами.
PCI workloads использовали бы отдельные проекты и clusters при требовании kernel, node или administrator isolation, принимая дополнительную стоимость без преувеличения защиты namespaces.

Зачем это спрашивают: Сильный ответ сопоставляет границу tenancy с threat model и автоматизирует quotas, identity, networking и onboarding.

designcapacityslo

Я бы отделил покрытие цены от гарантии capacity и держал надежную on-demand базу под слоем Spot.

Release channels, maintenance windows, проверки version skew и canary cluster продвигали бы upgrades через nonproduction и production внутри 30 дней.
Regional clusters, topology spread, PodDisruptionBudgets и controlled surge upgrades сохраняли бы replicas во время drain зоны или node pool.
Eligible baseline usage получал бы committed use discounts для снижения цены, но capacity после потери одной зоны обеспечивали бы zonal reservations для critical node pools; CUD сам по себе capacity не резервирует.
Spot pools принимали бы только checkpointable или overprovisioned work, а rightsizing, reservation coverage, disruption tests и unit cost доказывали бы экономию 35% без нарушения 99,95%.

Зачем это спрашивают: Интервьюер оценивает, спроектированы ли вместе скорость upgrades, zonal resilience, гарантии capacity и экономика Spot.

designsloserverless-containers

Я бы стандартизировал regional Cloud Run service contract и поставил multi-region services за global external Application Load Balancer.

Шаблон задавал бы service identity, ingress, secrets, CPU, memory, concurrency, maximum instances, logging и deploy policy, не открывая все настройки 30 командам.
Latency-sensitive services держали бы измеренное число minimum instances, а development и tolerant services масштабировались бы до нуля для защиты бюджета $70 000.
Maximum instances и concurrency с учетом downstream не позволяли бы пику 60 000 запросов в секунду исчерпать databases или regional quotas.
Per-revision latency, cold starts, saturation, cost per request и regional health управляли бы gradual rollout и SLO 99,95%.

Зачем это спрашивают: Сильный ответ превращает настройки Cloud Run, regional routing, защиту downstream и unit cost в переиспользуемую платформу.

designserverless-containersevents

Я бы нормализовал каждый source как CloudEvent и сделал эффект invoice идемпотентным за пределами delivery semantics trigger.

Eventarc filters направляли бы узкие event types в небольшие Cloud Run functions или services с отдельными identities вместо одного универсального handler.
Critical flows, которым нужны управляемые retention, dead letters или replay, проходили бы через явные Pub/Sub topic и subscription, а не зависели только от direct trigger.
Handler занимал бы immutable event ID в transactional invoice ledger до создания invoice, поэтому retries не повторяли бы бизнес-эффект.
Event age, retry count, dead-letter volume и end-to-end p95 отслеживались бы, а retention и replay за 24 часа тестировались бы на разных schema versions.

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

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

21
Спроектируйте backpressure Pub/Sub для 50 000 сообщений в секунду с десятиминутными пиками до 300 000, размером сообщения 1 КБ, freshness SLO пять минут и consumers, масштабируемыми до 400 000 сообщений в секунду за две минуты.
designslomessaging
22
Спроектируйте обработку заказов на Pub/Sub для 100 000 событий в секунду и двух миллионов tenants, с последовательностью внутри заказа, нулем повторных списаний, consumers в двух регионах и восстановлением за 15 минут.
designmessagingconcurrency
23
Спроектируйте asynchronous checkout API с постоянной нагрузкой 20 000 запросов в секунду, ответом за 200 мс, dispatch в fulfillment fleet с лимитом 25 000 операций в секунду, завершением за 15 минут и fairness для 500 tenants.
designapiasync
24
Спроектируйте batch execution для 20 000 container jobs в день, где 60% завершаются за 15 минут, 10% требуют GPU, все должны закончиться за шесть часов, а compute-бюджет ограничен $25 000 в месяц.
designbatchcontainers
25
Выберите Cloud SQL, AlloyDB или Spanner для relational control plane SaaS на 25 000 транзакций в секунду в трех регионах, с p99 чтения ниже 50 мс, RPO ноль при потере региона, SLO 99,999% и 40 ТБ данных.
sqltransactionsslo
26
Спроектируйте ledger в Spanner для 8 000 writes в секунду из пяти регионов, externally consistent balances, p99 записи ниже 120 мс, RPO ноль и доступности 99,999%.
design
27
Спроектируйте BigQuery lakehouse для 3 ПБ имеющихся данных, ежедневной загрузки 50 ТБ, 200 аналитиков, p95 dashboard ниже пяти секунд, EU data residency и analytics-бюджета $180 000 в месяц.
bigquerydesign
28
Спроектируйте Dataflow pipeline для одного миллиона событий в секунду, p99 freshness 10 секунд, допустимого опоздания 15 минут, replay за семь дней, RTO 15 минут и отсутствия duplicate business records.
designci-cd
29
Спроектируйте Cloud Storage для 5 ПБ media в двух регионах, если 80% объектов не читаются после 90 дней, retrieval должен занимать менее часа, durability не ниже одиннадцати девяток, RPO 15 минут, а storage-бюджет равен $60 000 в месяц.
designobject-storage
30
Спроектируйте data residency для 8 000 SaaS tenants в ЕС и США, включая 200 регулируемых EU tenants, с нулевым пересечением customer data, двумя serving regions на географию и SLO 99,95%.
designslocloud
31
Спроектируйте backup для 500 ТБ в databases, persistent data GKE и Cloud Storage, с RPO 15 минут, RTO четыре часа, обычным retention 35 дней, immutable copies на 90 дней и бюджетом $40 000 в месяц.
designbackupsobject-storage
32
Спроектируйте disaster recovery для приложения AlloyDB на 40 ТБ и 30 000 транзакций в секунду, с RPO меньше минуты, RTO 15 минут, SLO 99,99% и стоимостью DR не выше 45% primary cost.
designslotransactions
33
Спроектируйте zero-trust access для 6 000 сотрудников, 800 workloads и 250 проектов, без service account keys, с privileged sessions не дольше часа и отзывом доступа за 15 минут.
sessionszero-trustidentity
34
Спроектируйте VPC Service Controls для 120 проектов с 4 ПБ в BigQuery и Cloud Storage, тремя vendors, нулевой unauthorized exfiltration, onboarding vendor за один час и непрерывной работой CI pipelines.
designnetworkingobject-storage
35
Спроектируйте CMEK для 300 PCI-проектов в двух регионах, с rotation keys каждые 90 дней, emergency revocation за 15 минут, SLO 99,99% и без доступа приложения к raw key material.
designslo
36
Спроектируйте device-context governance в Access Context Manager для 6 000 сотрудников и 300 contractors в 25 странах, требуя managed devices для production access, revocation за 15 минут, contractor exceptions короче восьми часов и access SLO 99,9%.
designsloerror-handling
37
Спроектируйте Security Command Center для 300 проектов и одного миллиона assets в PCI scope, направляя поддерживаемые event-driven critical findings за пять минут, выполняя containment high-confidence threats за 15 минут и закрывая findings с owner за 24 часа.
eventsdesign
38
Спроектируйте Binary Authorization и SLSA-aligned supply chain для 200 сервисов и 100 ежедневных deployments, допуская только builds с provenance, помещая running images с новыми critical findings в quarantine за 15 минут и поддерживая audited emergency deployment.
authsupply-chaindesign
39
Спроектируйте audit evidence для SOC 2 и PCI в 180 проектах регионов ЕС и США, с retention 12 месяцев, результатами queries за десять минут, без log gaps и выдачей evidence за один рабочий день.
retentionqueriesdesign
40
Спроектируйте infrastructure platform на Terraform и Crossplane для 70 команд, 500 GCP-проектов, 30 resource requests в день, self-service delivery за 20 минут и RTO control plane два часа.
terraformiacdesign
41
Спроектируйте Terraform state для 1 000 ресурсов в 80 environments и 20 инженеров, с concurrent plans, восстановлением за 30 минут и ограничением любого failed apply одним application environment.
terraformdesignconcurrency
42
Спроектируйте policy as code для 400 Terraform modules и 40 команд, с 95% compliant delivery, блокировкой critical violations менее чем за пять минут и истечением исключений через 14 дней.
terraformdesignerror-handling
43
Спроектируйте GitOps для 15 GKE clusters и 300 сервисов, с 200 deployments в день, convergence за десять минут, rollback за пять минут и без human production credentials.
deploymentrollbackgitops
44
Спроектируйте self-service portal Backstage для 600 разработчиков и 40 команд, с созданием production-ready сервиса за 15 минут, adoption golden path 80% за шесть месяцев и SLO portal 99,9%.
designslodecision-making
45
На шестой неделе миграции 450 прекращенных Deployment Manager stacks в 120 проектах одна волна Terraform import предлагает пересоздать 38 production resources; как восстановиться без downtime и удержать recreation ниже 1%?
terraformdeployment
46
Спроектируйте observability platform для 120 сервисов и 40 команд, с availability SLO 99,95%, p99 latency objectives 300 мс, burn alerts за пять минут и telemetry-бюджетом $60 000 в месяц.
designsloobservability
47
Спроектируйте квартальный multi-region DR game day для commerce platform с 60 сервисами, 30 ТБ данных, 80 000 запросов в секунду, SLO 99,99%, RTO 20 минут и RPO пять минут.
designslo
48
Сократите годовой GCP-бюджет $4,2 млн на 20% за три месяца в 45 командах, сохранив SLO 99,95% и peak capacity на 30% выше прогноза.
capacityslo
49
Спроектируйте migration waves для 25 legacy applications на 180 VMs со 120 ТБ данных, закрытием двух data centers через девять месяцев, максимум четырьмя часами downtime на приложение, RPO 15 минут и post-migration SLO 99,9%.
designslomigrations
50
Задайте platform standard для 25 команд и 140 сервисов на GKE и Cloud Run, с adoption 70% за шесть месяцев, onboarding за один день, SLO 99,95% и долей исключений ниже 10%.
onboardingdecision-makingslo
51
Новая Organization Policy привела к сбою 83% rollout с 10 canary-проектов на 200 production-проектов, при этом SLO выдачи проекта равен 30 минутам, а запуск начнется через четыре часа; как восстановить rollout?
slodeployment-strategiesguardrails
52
Cloud Asset Inventory сообщает о 27 неожиданных выдачах прав уровня Owner в 40 проектах за 18 минут при baseline ноль в день и SLO реакции на IAM-инцидент 15 минут; что вы сделаете?
slo
53
Ключ сервисного аккаунта с доступом к шести production-проектам публичен уже 14 минут, исходящий трафик в 3,5 раза выше обычного baseline 2 Гбит/с, а SLO containment ключа равен 10 минутам; как вы отреагируете?
slo
54
Изменение Access Context Manager отклоняет 72% запросов IAP и Cloud Console от 4 800 managed laptops в 25 странах при workforce-access SLO 99,9%, а payroll cutover начинается через два часа; как отличить stale device context от реального noncompliance и восстановить доступ?
slocontext-managers
55
Отключение одной версии Cloud KMS key за шесть минут приводит к сбою 78% запросов от 60 сервисов при baseline ошибок 0,005% и serving SLO 99,99%; как восстановить сервис?
slo
56
Renewal controller на базе Certificate Authority Service не работает шесть часов; 2 400 из 12 000 workload mTLS certificates истекают за 30 минут, handshake failures растут с baseline 0,005% до 14%, а serving SLO равен 99,99%; как предотвратить fleet outage?
mtlsslo
57
Одна BGP-сессия Interconnect анонсирует непредусмотренный 10.42.16.0/20 с priority 80, вытесняя ожидаемый 10.42.16.0/20 с priority 100 и отправляя в blackhole 30% из 12 Гбит/с hybrid traffic; как восстановиться менее чем за пять минут?
sessions
58
Региональный producer Private Service Connect за десять минут подключает 45 consumer projects; в NAT subnet service attachment остаются четыре свободных адреса, 31 новая endpoint connection переходит в PENDING или NEEDS_ATTENTION, а ошибки payments API достигают 18% при SLO 99,99%; как восстановить consumers?
slonetworkingprivate-connectivity
59
Доля SERVFAIL в private Cloud DNS после одного изменения forwarding растет с 0,005% до 38% для 300 zones и 50 VPC при resolution SLO 99,99% и цели восстановления пять минут; что вы сделаете?
dnsslo
60
Глобальный external Application Load Balancer после backend release возвращает 22% HTTP 503 при 80 000 запросов в секунду, хотя health балансировщика остается зеленым, connection pools достигают лимита 10 000, а serving SLO равен 99,99%; как восстановить работу?
load-balancingslohttp
61
Error rate Kubernetes API регионального GKE-кластера достигает 65% за 20 минут, но существующие workloads продолжают обслуживать 99,97% из 70 000 запросов в секунду при SLO 99,9%; как управлять инцидентом control plane?
kubernetesapiincidents
62
Upgrade GKE node pool в двух из восьми кластеров удваивает API p99 с 220 до 480 мс и повышает ошибки с 0,02% до 3%, при SLO 99,95% и еще 5 000 nodes в очереди на upgrade; что вы сделаете?
kubernetesapidata-structures
63
После обновления GKE node image packet loss растет с 0,02% до 7% на 900 из 3 600 nodes, а service p99 превышает цель 300 мс при оставшихся 25 минутах error budget; как изолировать kernel regression?
kubernetesreliability
64
Ошибочная external metric за восемь минут увеличивает HPA с 30 до 1 200 replicas, поднимает прогноз compute cost до $40 000 в день и загрузку database с 45% до 95% при API SLO 99,9%; как остановить runaway scaling?
databasereplicationapi
65
GKE upgrade за 45 минут не выполнил drain ни одного из 600 nodes, потому что 140 workloads имеют PDB с minAvailable, равным числу replicas, при deadline upgrade 24 часа и serving SLO 99,95%; что вы сделаете?
kubernetesreplicationslo
66
Включение strict mTLS для 120 сервисов вызывает 35% HTTP 503 при 60 000 запросов в секунду, потому что у 18 legacy workloads нет sidecars, и за четыре минуты нарушается SLO 99,99%; как восстановить работу?
mtlshttpslo
67
Изменение Multi-cluster Gateway route отправляет 30% EU checkout traffic в US cluster, повышая p99 с 240 мс до 1,9 секунды при 45 000 запросов в секунду и SLO 99,95%; как исправить routing incident?
gatewaysloincidents
68
Binary Authorization блокирует emergency image во время активного exploit, 12 критичных сервисов нужно развернуть за SLO mitigation 20 минут, а обычный attestation pipeline занимает 45 минут; как безопасно использовать break-glass?
authsupply-chaindeployment
69
Скомпрометированный digest образа Artifact Registry работает в 17 сервисах шести GKE-кластеров, подозрительный egress на 2% выше baseline 20 Гбит/с, а containment нужно завершить за 15 минут; как вы отреагируете?
artifactsregistrieskubernetes
70
После rollout общей client library 35 Cloud Run callers выпускают service-to-service ID tokens с aud api.example.com, хотя 12 private targets принимают только их run.app URL; 68% из 20 000 запросов в секунду возвращают 401 при SLO 99,95%, как восстановиться?
sloserverless-containersapi
71
Плановый switchover primary AlloyDB завершается за 70 секунд, но общий connection DNS отправляет writer traffic в read pool; 38% writes падают, read p99 достигает 2,1 секунды, а приложение выполняет 28 000 транзакций в секунду с RTO пять минут, что вы сделаете?
transactionsdns
72
После IAM cleanup в destination project 96% из восьми миллионов daily events от 18 source projects перестают достигать центрального private Cloud Run service; freshness Eventarc имеет SLO две минуты, а recovery RTO 15 минут, как восстановить cross-project delivery?
sloserverless-containersevents
73
Плохой release subscriber Pub/Sub подтверждает сообщения до commit writes 12 минут при 80 000 сообщений в секунду и оставляет 57,6 млн missing records; snapshot за пять минут до rollout существует, retention равен семи дням, RTO 30 минут, а duplicate effects должны остаться нулевыми, как восстановиться?
retentionsnapshotmessaging
74
Одно malformed Pub/Sub message вызывает retry storm, который 12 минут потребляет 35% CPU subscriber, повышает redelivery с 1% до 48% и угрожает пяти минутам processing SLO для 4 миллионов валидных сообщений; что вы сделаете?
resilienceslomessaging
75
Один tenant публикует 1 200 Pub/Sub messages в секунду средним размером 1 КБ под одним ordering key и превышает throughput key около 1 МБ/с; lag достигает 35 минут, а продукт требует freshness пять минут и полный порядок tenant, какое требование вы оспорите и что измените?
messagingthroughput
76
Release Dataflow группирует один миллион событий размером 1 КБ в секунду по customer_id; один tenant создает 38%, OOM restarts workers достигают 900 в час, shuffle backlog равен 6 ТБ, а p99 freshness растет с 30 секунд до 15 минут, как восстановиться?
backlog
77
On-demand BigQuery после выпуска dashboard увеличивает scanned bytes с 200 ТБ до 1,6 ПБ в день, прогноз monthly analysis cost растет с $40 000 примерно до $300 000, а аналитикам нужно вернуть сервис за 30 минут; как локализовать взрыв query cost?
queriesbigquery
78
Governance rollout прикрепляет policy tags к 420 columns BigQuery и заменяет row access policies на 180 tables; 52 из 60 команд получают Access Denied, восемь видят ноль rows, 240 dashboards падают при recovery SLO 30 минут, как восстановиться без лишнего раскрытия данных?
schemabigqueryslo
79
Regional HA failover Cloud SQL занимает 11 минут вместо RTO две минуты при 18 000 транзакций в секунду, application errors достигают 32% при baseline 0,1%; как диагностировать и исправить инцидент?
sqldatabasetransactions
80
Cloud SQL for PostgreSQL объемом 10 ТБ вырастает с 8,2 до 9,9 ТБ во время runaway load, automatic storage increase включен, но ограничен 10 ТБ, free space падает до 0,8%, а 12% writes падают при 22 000 транзакций в секунду; как восстановиться?
sqltransactionspostgres
81
В 14:03 оператор удаляет database orders объемом 1,8 ТБ в Cloud SQL for PostgreSQL; detection занимает восемь минут, RPO accepted orders равен нулю, PITR включен, traffic составляет 22 000 writes в секунду, а RTO 45 минут, как восстановиться и выполнить cutover?
sqldatabasepostgres
82
После запуска settlement batch ответы ABORTED Spanner растут с 0,4% до 31%, а commit p99 с 90 мс до 1,4 секунды при 45 000 транзакций в секунду; transaction statistics показывают contention 12 account rows и locks batch на четыре секунды, как восстановиться?
transactionsbatch
83
При rollout schema Spanner удаляется compatibility column, которую еще читают 30% из 600 clients, из-за чего request failures растут с baseline 0,1% до 9% при 40 000 запросов в секунду, а SLO дает пять минут на rollback; что вы сделаете?
schemarollbackslo
84
Изменение lifecycle Cloud Storage снижает object age с 365 до 30 дней и за два часа удаляет 18 ТБ обязательных audit exports, тогда как policy требует хранение семь лет, а restore RTO равен четырем часам; как восстановить данные?
retentionobject-storage
85
Автоматизация 90-дневной CMEK rotation переключает 80 ресурсов на replacement CryptoKey без grants для service agents, поэтому 62% новых writes падают, хотя старые reads работают, при SLO 99,99%; чем это отличается от сбоя из-за отключенного ключа?
slo
86
Регион GCP теряет 85% capacity для commerce platform на 70 000 запросов в секунду, ошибки достигают 28%, SLO равен 99,99%, RTO 15 минут, а RPO пять минут; как активировать disaster recovery?
capacityslo
87
Ежеквартальный restore test для 40 ТБ production data обнаруживает, что последние 14 daily backups не проходят checksum validation или не имеют доступа к KMS keys, несмотря на RTO четыре часа и RPO 15 минут; что вы сделаете?
validationbackups
88
Три parallel Terraform applies обходят защиту GCS backend: один job использует -lock=false, второй backend prefix управляет теми же resources, а break-glass account вручную загружает state; canonical state обрезан и следующий plan предлагает 600 creates, как восстановиться за 30 минут?
terraform
89
IAM cleanup удаляет roles/cloudkms.cryptoKeyEncrypterDecrypter у service agent Cloud Storage на CMEK, защищающем 190 objects Terraform state; 48 команд получают KMS-related 403, а plan service имеет SLO 15 минут, как безопасно восстановить доступ?
terraformsloobject-storage
90
Semantically invalid constraint Policy Controller через Config Sync достигает 15 GKE clusters и за шесть минут отклоняет 91% deployments; 3 200 objects по-прежнему имеют status SYNCED, recovery SLO равен десяти минутам, а плохая policy совпадает и с platform namespaces, как безопасно откатиться?
deploymentconfigrollback
91
Скомпрометированный service account Cloud Build публикует backdoored images в девять Artifact Registry repositories, и 23 deployments используют их за 25 минут при SLO containment supply chain 15 минут; как вы отреагируете?
deploymentartifactsregistries
92
Fleet rollout NetworkPolicy блокирует collectors Managed Service for Prometheus в 18 из 24 GKE clusters от scrape 9 000 targets и записи samples; ingestion падает на 82% на 12 минут, paging SLO становится слепым, а observability RTO равен десяти минутам, как восстановиться?
observabilitykubernetesmonitoring
93
Application logs раскрывают email addresses и bearer tokens в шести миллионах Cloud Logging entries за 48 часов и экспортируют их через 12 sinks, тогда как policy требует containment за 30 минут и подтвержденное удаление за семь дней; как вы отреагируете?
tokenslogging
94
Один сбой dependency вызывает 600 pages за 20 минут из 80 Cloud Monitoring policies, median acknowledgement растет с двух до 14 минут, а on-call SLO равен пяти минутам; как взять alert storm под контроль?
monitoringdependenciesalerting
95
Canary на 30% traffic расходует 22% monthly error budget для SLO 99,95% за 40 минут, baseline burn rate был 0,4, а release gate допускает не более 2% budget за час; что вы сделаете?
reliabilitydeployment-strategies
96
Raw detailed billing export и invoice показывают $2,0 млн за месяц, но chargeback сообщает только $1,6 млн, потому что join с effective-dated owners отбрасывает 18% rows в 320 проектах; $400 000 скрыты от team statements, books закрываются через 48 часов, а attribution должна превышать 99%, как восстановиться?
joins
97
Трехлетний committed use discount стоит $900 000 в год, eligible usage после platform migration падает на 45%, и finance прогнозирует $250 000 annual waste при неизменных SLO и traffic; как работать с overcommit?
soft-skillsmigrationsslo
98
Запуск через 72 часа должен увеличить traffic с 20 000 до 200 000 запросов в секунду, но regional API quota одобрена только на 50 000, launch SLO равен 99,9%, а burst budget составляет $60 000; что вы сделаете?
sloapi
99
Во время migration database объемом 25 ТБ при 40 000 транзакций в секунду traffic cutover на 30% показывает 0,8% row mismatches при rollback gate 0,1%, RPO ноль и оставшихся 20 минутах change window; как выполнить rollback?
databasetransactionsmigrations
100
Крупный региональный инцидент GCP вызывает 35% ошибок в четырех продуктах на 120 000 запросов в секунду при SLO 99,99%, RTO 20 минут и RPO пять минут; организуйте incident command с точной частотой коммуникаций и recovery gates.
incidentsslo

Вопросы

1Спроектируйте landing zone в GCP для 40 инженерных команд, 220 проектов, нагрузок в США и ЕС, SLO платформы 99,95% и выдачи проекта не дольше 30 минут.

2Как бы вы спроектировали Shared VPC для 90 service projects в трех регионах, 20 команд, SLO сети 99,99% и on-premises сети, занимающей 10.0.0.0/8 еще 12 месяцев?

3Спроектируйте изоляцию SaaS-платформы с 12 000 tenants, 60 регулируемыми enterprise tenants, тремя обслуживающими регионами, SLO 99,95% и лимитом не более 2% общей мощности на одного tenant.

6Спроектируйте глобальную доставку для retail-сайта с 150 000 запросов в секунду из четырех origins, p95 ниже 250 мс, SLO 99,99% и edge-бюджетом $120 000 в месяц.

9Спроектируйте публикацию через Private Service Connect для payments API, который используют 40 проектов, с 20 000 запросов в секунду в трех регионах, p99 ниже 100 мс, SLO 99,99% и без VPC peering.

10Спроектируйте DNS для 300 private zones, 50 VPC и двух on-premises data centers с SLO разрешения 99,99% и восстановлением после потери forwarding path за пять минут.

11Спроектируйте контролируемый egress для 10 000 workloads в 200 проектах, с PCI-сегментацией, пиком 25 Гбит/с, 500 одобренными web domains и бюджетом сетевой безопасности $80 000 в месяц.

12Спроектируйте региональный GKE fleet для 180 сервисов в трех регионах, 20 deploy в день, serving SLO 99,99%, RTO 10 минут и RPO ноль для принятых запросов.

13Выберите GKE Standard или Autopilot для 70 stateless-сервисов 25 команд, с восьмикратными пиками трафика, SLO 99,9%, бюджетом $90 000 в месяц и шестью privileged node agents, которые нельзя убрать.

15Спроектируйте service mesh для 120 сервисов в четырех GKE clusters, 60 000 запросов в секунду, обязательного mTLS, SLO 99,99% и не более 15 мс дополнительной p99 latency.

16Спроектируйте multi-cluster ingress для трех региональных GKE clusters с 100 000 запросов в секунду, целью regional failover пять минут, canary 5%, без session affinity и с SLO 99,99%.

17Спроектируйте GKE tenancy для 40 команд и 2 000 pods в шести clusters, с изоляцией PCI workloads, onboarding команды за один день и лимитом 5% CPU общего cluster на команду.

18Спроектируйте upgrades и capacity GKE для восьми clusters на 5 000 vCPU, с завершением upgrades за 30 дней, SLO 99,95%, экономией compute 35% и переживанием потери одной zone вместе с Spot eviction.

19Спроектируйте платформу Cloud Run для 80 сервисов и 30 команд, обслуживающую 60 000 запросов в секунду с p99 ниже 300 мс, SLO 99,95% и compute-бюджетом $70 000 в месяц.

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