{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "Patrones de arquitectura",
   "q": "Arquitectura canónica: app web moderna en GCP",
   "a": "Cloud DNS + Cloud LB (global HTTPS) → Cloud Run (API) + GCS/CDN (frontend) → Cloud SQL (HA) + Memorystore (caché) → Secret Manager/IAM.\nObservabilidad: Cloud Ops. CI/CD: Cloud Build + Artifact Registry. IaC: Terraform.\nEscala: Run auto, SQL read replica si hace falta. DR: backup cross-region.\nEs el punto de partida del 80% de proyectos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Backend for a mobile app: qué cambia en el diseño",
   "a": "Auth de usuarios finales: Identity Platform/Firebase Auth (JWT en headers).\nAPIs optimizadas para móvil: payloads pequeños, paginación por cursor, batching en BFF.\nPush: FCM. Offline: Firestore local cache.\nCDN para assets, Cloud Run para API — el tráfico móvil es spiky: serverless absorbe picos sin pagos fijos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Multi-tenant SaaS en GCP: 3 modelos de aislamiento",
   "a": "Pool (todos los tenants en la misma BD con tenant_id + row-level security) — barato.\nSilos (BD/proyecto por tenant) — máximo aislamiento, caro de operar a escala.\nBridge (BD compartida, esquema o servicio por tenant grande).\nHíbrido realista: pool para pequeños, silo para enterprise (cada silo es un proyecto con Terraform).",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "API management: API Gateway vs Apigee vs Endpoints",
   "a": "API Gateway (serverless, barato): auth JWT, routing a Cloud Run/Functions, quotas — para APIs simples.\nApigee (enterprise): portal de desarrolladores, monetización, analítica por producto de API, políticas avanzadas — para exponer APIs COMERCIALES.\nEndpoints (legado, quizá evitar en nuevo).\nPuerta de entrada + WAF (Cloud Armor) completa el borde.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Exponer Cloud Run con dominio propio: opciones",
   "a": "1) Domain mapping directo de Cloud Run (simple, sin LB).\n2) LB global + serverless NEG → Cloud Armor + CDN + certificado gestionado (el estándar para prod serio).\n3) Firebase Hosting rewrites a Run (frontend + API juntos).\nDNS: CNAME/A al endpoint. TTL bajo durante cutover.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Procesamiento de archivos que suben usuarios: patrón completo",
   "a": "1) Backend firma V4 signed URL → cliente sube directo a GCS (no pasa por la API).\n2) Notificación: Eventarc (GCS finalize) o Pub/Sub → Cloud Run procesa (valida, transformar, guarda metadata en SQL/Firestore).\n3) Estado y errores: tabla de jobs + Cloud Tasks retry.\nVentajas: API ligera, escala automática, resumable uploads nativos.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Aplicación multi-región activa-activa: checklist",
   "a": "Datos: Spanner multi-región (o SQL cross-region replicas manual), GCS multi-region, Memorystore regional por región.\nTráfico: LB global anycast → Cloud Run en 2+ regiones (health checks regionales).\nEstado de sesión: stateless + JWT; caché por región.\nDNS/routing: LB decide por latencia; failover automático.\nPruebas: caos regional simulado cada trimestre.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Webhooks entrantes (pagos, mensajería): diseño robusto",
   "a": "Endpoint idempotente por event id (dedup table) → aceptar 200 RÁPIDO y encolar el procesamiento (Pub/Sub/Tasks) → worker procesa con reintentos.\nVerificación de firma del proveedor (HMAC) ANTES de aceptar.\nReplay safety: proveedores re-envían; tu sistema debe tolerarlo.\nMonitoreo de latencia y tasa de fallo por proveedor.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Jobs nocturnos y batch sin servidores: opciones y criterio",
   "a": "Cloud Run Jobs: contenedor batch, paralelismo por índice, retry por tarea — el default moderno.\nCloud Scheduler + Tasks: encadenar pasos con rate control.\nBatch service: para cómputo HPC masivo (miles de VMs spot).\nDataflow: si es procesamiento de datos continuo/paralelo real.\nCriterio: duración, paralelismo, dependencias.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Hybrid y multi-cloud: Anthos y el sentido real",
   "a": "Anthos/GKE Enterprise: plano de gestión para GKE on-cloud, on-prem y otros clouds — políticas, config sync y service mesh unificados.\nCasos reales: migración gradual, cumplimiento de datos on-prem, evitar vendor lock-in de plataforma.\nCosto: licencias + complejidad operativa significativa — justificar con requisito concreto, no con moda.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "CQRS aplicado: lectura escalada con BigQuery/Firestore",
   "a": "Escrituras en Cloud SQL (transaccional, normalizado) → CDC/Dataflow → vistas denormalizadas en Firestore (consultas de app) o BigQuery (analítica).\nEl servicio de escritura no compite con lecturas masivas; cada lado optimiza su patrón.\nLag eventual de segundos: aceptable para feeds/dashboards, no para saldo bancario.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Anti-patrones GCP frecuentes (y cómo se ven en la factura)",
   "a": "VMs sin apagar en dev (24/7 por hábito) → CUD de cosas que no necesitas.\nLogs ruidosos sin exclusiones → Cloud Logging caro.\nEgress directo de GCS a usuarios sin CDN → transfer cost alto.\nNAT de 1 instancia pero min-instances altas en Run.\nBigQuery sin particionar → scans de TB por dashboard.\nCada uno tiene fix mecánico — auditar mensualmente.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Diseñe un sistema de notificaciones para 10M usuarios» — boceto GCP",
   "a": "API recibe evento → Pub/Sub (topic notificaciones) → Dataflow/Cloud Run workers por canal: FCM (push), SendGrid (email), SMS — cada canal con rate limiting propio (Cloud Tasks).\nPreferencias de usuario en Firestore (por usuario, lectura rápida). Dedup + throttling por usuario.\nMétricas: entregados/fallidos por canal; DLQ para fallos; reintentos.\nEscala: fan-out por shards (region/hash) para no hotspotean.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Tu Cloud Run API se cae a las 3 a.m.» — runbook de diagnóstico",
   "a": "1) Dashboards: error rate, latencia, instancias, saturación.\n2) Logs con traceId de requests fallidos → excepción dominante.\n3) Dependencias: estado de Cloud SQL (failover?), límites de cuota (429?), circuit breakers abiertos.\n4) Deploy reciente? → rollback de revisión (1 comando) mientras se investiga.\n5) Postmortem sin culpa + alerta que debió dispararse antes.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Necesito garantizar que facturas NUNCA se pierden» — patrón",
   "a": "Escritura transaccional a Cloud SQL (factura + outbox event en la MISMA tx).\nPublisher outbox (poller/CDC Debezium) → Pub/Sub con retention + DLQ.\nConsumidor idempotente persiste en destino; reconciliación diaria compara conteos origen/destino.\nBackups PITR + retention de GCS = durabilidad de datos; el outbox resuelve la entrega.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Reduzca el 40% del costo sin tocar features» — plan de ataque",
   "a": "1) Billing export: top SKUs y por label/equipo — dónde está el dinero REAL.\n2) Quick wins: dev apagado de noche (scheduler), IPs estáticas huérfanas, snapshots viejos, logs con exclusion.\n3) Compute: right-sizing con Recommender, spot en batch, CUDs sobre la base estable.\n4) Datos: storage classes por edad, particionado BQ, CDN para egress.\n5) Medir y repetir; presupuesto + alertas para sostener.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Migrar una app on-prem con BD a GCP» — camino realista",
   "a": "Fase 0: inventario y assessment (compatibilidad, tamaño, latencia).\nLift & shift: Compute Engine + Cloud VPN/Interconnect + DMS para la BD (CDC, cutover controlado).\nDespués (no en paralelo): contenerizar → Cloud Run/GKE, reemplazar componentes por managed (Secrets, Storage).\nCutover por dominios con rollback planeado. Nunca modernizar y migrar a la vez.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«La app es lenta solo para usuarios de otro continente» — diagnóstico",
   "a": "Medir: ¿latencia de red (TTFB) o de aplicación (server time)? RUM/ping desde esa región.\nRed: LB global anycast + CDN para estáticos (edge caching) — el fix más común.\nDatos: BD en una sola región = RTT por query → read replica regional o caché local (Memorystore) de datos calientes.\nVerificar handshake TLS y keep-alive (conexiones nuevas por request matan latencia).",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Otro equipo debe consumir nuestros datos» — cómo exponerlos bien",
   "a": "Opciones por acoplamiento: API REST/gRPC directa (sync, acopla), Pub/Sub topic con schema (eventos, desacopla), vista/materialized en BigQuery con data sharing (analítica), Data Share/Analytics Hub para datasets gobernados.\nContrato: schema versionado + SLA + auth por SA del consumidor con rol mínimo (publisher/invoker).\nNunca: acceso directo a TU base de datos (acoplamientoletal).",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Cumplo GDPR/PII en GCP» — controles concretos",
   "a": "Residencia: org policy resourceLocations + regiones de datos de cada servicio.\nAcceso: IAM mínimo + VPC-SC (perímetro) + CMEK si aplica.\nCiclo de vida: retención automática (GCS lifecycle, BQ table expiration), derecho al olvido = jobs de borrado trazables.\nDetección: Sensitive Data Protection escaneando buckets/tablas.\nAuditoría: data access logs habilitados y exportados.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Necesito un chat en tiempo real» — componentes GCP",
   "a": "Transporte: WebSocket con STOMP (GKE) o SSE + polling (Cloud Run) — mantener conexiones requiere always-allocated CPU en Run o websockets en GKE.\nFan-out: Pub/Sub entre instancias/réplicas (todos los pods reciben el mensaje del room).\nPersistencia: Firestore (realtime listeners para clientes web/móvil gratis).\nPresencia y rate limiting: Memorystore.\nFirebase Realtime/Firestore directo simplifica si el equipo es pequeño.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Buscador sobre millones de documentos» — dónde entra cada servicio",
   "a": "Ingesta: GCS + Eventarc → Dataflow (parse/enrich) → índice.\nBúsqueda full-text gestionada: Elastic Cloud en Marketplace, Vertex AI Search (antes Enterprise Search), o pg_trgm/tsvector en Cloud SQL para escala chica.\nEmbeddings: Vertex AI text-embedding + vector search (Matching Engine) para semántica.\nQueries: API en Cloud Run con caché de resultados calientes.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«¿Compute Engine o Cloud Run para un microservicio Java?» — respuesta estructurada",
   "a": "Preguntar primero: estado, tráfico (spiky?), equipo, licencias.\nDefault Cloud Run: contenedor, autoscaling, revisiones/canary gratis, sin parcheo de SO.\nCompute Engine si: JVM tuning profundo (heap grande, GC específico), licencias por core/nodo, red especial (multicast), sidecars del sistema.\nGKE si ya hay plataforma k8s y muchos servicios con mesh.\nJustifica con costo operativo, no con preferencia.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Zero downtime deploy» — opciones por plataforma GCP",
   "a": "Cloud Run: revisiones + traffic split (canary 5% → 100%), rollback instantáneo.\nGKE: rolling update (maxSurge/maxUnavailable) o canary con Gateway API/Istio.\nMIG: rolling updater con health checks.\nBase de datos: migraciones compatibles (expand → deploy → contract) para que N y N+1 convivan.\nLa parte dura casi siempre es el SCHEMA, no el deploy.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Rate limiting global para una API multi-región» — diseño",
   "a": "Límite por API key/usuario: contador distribuido en Memorystore (Redis) — pero Redis por región ≠ global consistente.\nOpciones: Redis global vía replicas + read local (aproximado), contador en Spanner (consistente, costo), o rate limit por-región (suficiente en la práctica).\nEn el borde: Cloud Armor rate-based por IP (grueso) + fino por identidad en la app.\nDocumentar el trade-off de precisión.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Auditoría: quién vio/exports datos de clientes» — implementación",
   "a": "Data Access audit logs (ADMIN_READ/DATA_READ) habilitados para los servicios de datos sensibles → sink a BigQuery.\nQueries: por objeto accedido, por usuario, por método (get/download).\nAlertas: log-based metric para accesos masivos anómalos (exfil detection).\nAplicación: tabla de acceso a PII con propósito (por qué lo vio) si el compliance lo exige.",
   "nivel": "intermedio",
   "clave": false
  }
 ]
}