{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "Bases de datos",
   "q": "Cloud SQL flags y mantenimiento: los detalles que evitan sustos",
   "a": "Flags (database flags): slow_query_log=ON, max_connections, timezone, character_set.\nMaintenance window (día/hora) + maintenance timing (earlier/later) — Google patchea ahí; HA hace failover real (prueba el rebalanceo).\nRejections en producción: siempre el warning de 'patching imminent' por email/monitoring.\nInstance restart por flag = planificar ventana.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Cross-region disaster recovery para Cloud SQL: pasos",
   "a": "1) Read replica cross-region continua (asincrónica) en la región DR.\n2) Backups también en la región secundaria (backup replication).\n3) Drill: promover la réplica (promote) y apuntar la app vía connection name por región/flag.\n4) RTO estimado = promoción (~min) + redirect; RPO = lag de réplica (segundos-min).\nAutomatizar el failover con Workflows + alerta de región caída.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Observabilidad y SRE",
   "q": "Managed Service for Prometheus y Grafana en GCP",
   "a": "Managed Prometheus: ingesta de métricas de Prometeo gestionada (pagas por samples), sin operar servers — GKE lo scrapea automático.\nCloud Monitoring soporta PromQL.\nGrafana: hosted por Google en Cloud Monitoring (dashboards de PromQL) o self-hosted en GKE contra el datasource managed.\nMigración típica: Prometheus self-hosted → managed para quitar ops.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Observabilidad y SRE",
   "q": "Log analytics y queries sobre logs en BigQuery",
   "a": "Log Analytics (bucket de logs con Linked dataset): consultar logs en BigQuery con SQL — tendencias de errores, latencia por endpoint desde LOGS (no métricas).\nEjemplo: SELECT httpRequest.requestUrl, COUNT(*) FROM logs WHERE severity='ERROR' GROUP BY 1 ORDER BY 2 DESC.\nRetención extendida barata vs default 30 días.\nBase de análisis de incidentes post-mortem.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "Cloud Run y websockets/SSE: limitaciones reales",
   "a": "SSE/streaming HTTP: soportado bien (response streaming) — dashboards push simples.\nWebSockets: soportados (gen2) PERO con concurrencia por instancia: cada instancia mantiene sus conexiones; scaling por conexiones requiere métricas custom.\nAlways-allocated CPU obligatorio para mantener conexiones vivas entre requests.\nTimeouts: 60 min máx por request; reconexión del cliente debe estar diseñada.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "Cold start de JVM en Cloud Run: checklist completo",
   "a": "1) Startup CPU boost ON (2 vCPU al arrancar).\n2) Imagen distroless + JVM headless; AppCDS/CDS training para compartir clases.\n3) Spring: lazy initialization selectivo, excluir autoconfigs de arranque, iniciar listeners tras ready (readiness).\n4) Min instances = 1 para rutas críticas.\n5) Medir: container startup time en métricas de Run — objetivo <2s con boost.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Fundamentos y organización",
   "q": "Migración de cuentas y organización enterprise: Landing Zone",
   "a": "Landing zone: la base lista antes de crear proyectos — Organization, carpetas, org policies base (no public IPs, no SA keys), jerarquía de billing, Shared VPC host, logging central, Terraform bootstrap (seed project + state bucket + CI).\nBlueprints: module terraform-google-project-factory.\nSin landing zone, cada equipo inventa su seguridad — deuda permanente.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Fundamentos y organización",
   "q": "Resource hierarchy anti-patrones",
   "a": "Un solo proyecto gigante para todo (cuotas, blast radius, permisos groseros).\nUn proyecto por VM/servicio mínimo (operación imposible).\nCarpetas por TIPO de recurso en vez de por equipo/producto (IAM no escala).\nEntornos mezclados en el mismo proyecto (dev junto a prod = desastre).\nRegla: cambiar algo de dev NO debe poder tocar jamás a prod.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "DevOps y CI/CD",
   "q": "Monorepo vs multirepo para microservicios + CI",
   "a": "Monorepo: atomicidad de cambios cruzados, refactors globales; CI con filtros por carpeta (solo build lo tocado); governance única.\nMultirepo: ownership y releases independientes, permisos simples; versiones y sync manual entre repos.\nGCP: Cloud Build triggers con included files para monorepo; un trigger por servicio en multirepo.\nAmbos válidos; el equipo manda.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "DevOps y CI/CD",
   "q": "Migraciones de schema seguras en CI/CD (expand-contract)",
   "a": "Deploy N: migración ADDITIVA (añadir columna nullable + backfill) — compatible con versión vieja.\nDeploy código N (usa ambas). Deploy código N+1 (solo nueva). Deploy N+2: migración contractiva (drop viejo).\nRegla: cada migración debe correr contra el código de la versión PREVIA — nunca renombrar/dropear en el mismo release.\nFlyway/Liquibase versionados por servicio.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "gcloud y herramientas",
   "q": "Console: atajos y funcionalidades que la gente no conoce",
   "a": "Search global (barra superior) encuentra recursos por nombre/ID.\nActive Assist: recommendations centralizadas.\nNetwork Analyzer / Connectivity Tests.\nCloud Console mobile app para alertas/uptime on-call.\nKeyboard shortcuts (?) y filtros guardados en tablas.\nRecent projects: cambiar rápido entre entornos.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Patrón claim check: payloads grandes por mensajería",
   "a": "Problema: mensajes >10MB (imágenes, PDFs) no van bien en Pub/Sub.\nSolución: guardar payload en GCS → publicar mensaje solo con la REFERENCIA (bucket, objeto, metadata) → consumidor descarga y procesa.\nBeneficios: mensajería liviana y rápida, retry barato, lifecycle del payload separado del mensaje.\nNombre clásico: Claim Check (Enterprise Integration Patterns).",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Patrones de arquitectura",
   "q": "Compensación y reconciliación diaria: la red de seguridad",
   "a": "Aun con outbox/idempotencia, los sistemas divergen (bugs, mensajes perdidos).\nJob de reconciliación: compara conteos/sumas entre sistemas (pedidos vs pagos del día), reporta diferencias, genera work-queue de reparación.\nMétrica: % de records divergentes por día — tendiente a 0.\nEs humilde pero es lo que mantiene la confianza en event-driven.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Vector databases en GCP: opciones actuales",
   "a": "1) Vertex AI Vector Search (Managed Index, ANN a escala — el más potente).\n2) AlloyDB con extensiones pgvector + fast path — Postgres friendly.\n3) Cloud SQL pgvector para escala moderada.\n4) Firestore vector search para apps móviles.\nPatrón RAG: documentos → embeddings (Vertex) → índice → query embedding → top-k → LLM con contexto.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Escenarios de entrevista",
   "q": "«Justifica tu arquitectura ante un CFO» — lenguaje de costo",
   "a": "Traduce a dinero: 'Cloud Run escala a 0 → pagamos uso real vs $X/mes de VMs siempre encendidas; ahorro estimado Y%'.\nTCA: infraestructura + operación (horas de DevOps ahorradas por managed) + riesgo (SLA/fallas evitadas).\nCosto por unidad de negocio: $ por pedido procesado/por usuario activo — la métrica que entiende todos.\nCUDs y compromisos = descuento contra estabilidad de demanda.",
   "nivel": "avanzado",
   "clave": false
  }
 ]
}