{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "Almacenamiento",
   "q": "GCS: estructura (buckets/objetos) y límites clave",
   "a": "Namespace global de buckets; dentro, objetos planos con nombre (no hay 'carpetas' reales — son prefijos).\nObjetos inmutables por versión; hasta 5TB por objeto; metadata + ACLs/IAM.\nOps por HTTP/XML/JSON API, gsutil o client libs con resumable upload para grandes.\nDiseño de nombres: prefijos tipo fecha (logs/2025/09/12/) para listar/particionar.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Almacenamiento",
   "q": "Signed URLs: dar acceso temporal sin credenciales",
   "a": "URL firmada con expiración (V4): permite al cliente SUBIR o DESCARGAR directo del bucket con tu firma — tu app solo genera la URL.\nCasos: uploads de archivos grandes sin atravesar tu API, links de descarga seguros temporales.\nSigned POST policies para restringir tamaño/CONTENT-type en upload.",
   "nivel": "basico",
   "clave": true
  },
  {
   "sub": "Almacenamiento",
   "q": "Lifecycle rules: automatizar costo y retención",
   "a": "Reglas por prefijo/edad/tiempo desde última modificación: cambiar a Nearline (30d), Coldline (90d), Archive (365d), borrar versiones viejas, eliminar objetos temporales.\nEjemplo: logs → 90 días Standard, luego Archive, borrar a 3 años (compliance).\nSe aplican de fondo; verificar con lifecycle log/dry runs.",
   "nivel": "basico",
   "clave": true
  },
  {
   "sub": "Almacenamiento",
   "q": "Versioning, retention y bucket lock: inmutabilidad",
   "a": "Versioning: sobrescribir crea versión antigua accesible (restore/soft-delete accidental).\nRetention policy: objetos no borrables antes de N días (compliance). Bucket Lock con retención LOCKED = WORM inmutable (auditoría legal).\nSoft delete (nuevo): ventana de recuperación de objetos borrados por defecto (7 días).",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Almacenamiento",
   "q": "Public objects y uniform access: seguridad de buckets",
   "a": "Uniform bucket-level access (obligatorio en nuevos): SOLO IAM, sin ACLs por objeto — gobernanza simple.\nallUsers/allAuthenticatedDomains = público: detectar con SCC y bloquear con org policy (publicAccessPrevention).\nCompartir: signed URLs o IAM por grupo, nunca ACLs ad-hoc.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Almacenamiento",
   "q": "Storage Transfer Service: migraciones y sincronización",
   "a": "Transfiere: de S3/Azure/on-prem a GCS, entre buckets, o respaldo recurrente con filtros (prefijo, fecha) y schedules.\nVerificación de integridad (checksums), bandwidth limit, delete objects que no estén en el origen (sync).\nTransfer Appliance: hardware físico para TB/PB sin red suficiente.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Almacenamiento",
   "q": "Sitio estático + CDN en GCS: la arquitectura más barata",
   "a": "Bucket con index.html + LB backend bucket + Cloud CDN → sitio global HTTPS con cert gestionado.\nCache-Control por tipo (html no-cache, assets 1 año immutable con hash en nombre).\nAlternativa serverless: Firebase Hosting (deploy en 1 comando).\nCosto: centavos para tráfico moderado.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Cloud SQL: HA, réplicas y backups de verdad",
   "a": "HA: regional con standby sincrónico en otra zona — failover automático (~60s, misma IP via proxy).\nRead replicas: lecturas escaladas / analítica ligera; cross-region replica para DR (promotable).\nBackups automáticos + PITR con write-ahead logs (restaurar a un minuto concreto).\nMaintenance window configurable (patches).",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Bases de datos",
   "q": "Conectarte a Cloud SQL: proxy vs IP privada",
   "a": "Cloud SQL Auth Proxy: sidecar/proceso local que cifra y autentica por IAM (sin SSL certs manuales ni IP pública) — recomendado para Cloud Run/develop.\nPrivate IP: la BD solo en la VPC (Serverless VPC connector / GKE nativo) — topología segura de prod.\nJamás IP pública + password solo (combinable pero mínima).",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Bases de datos",
   "q": "Cloud SQL vs AlloyDB: cuando Postgres crece",
   "a": "Cloud SQL: Postgres/MySQL gestionado clásico — HA, réplicas, precio contenido.\nAlloyDB: Postgres compatible pero con capa analítica (columnar engine 100x para queries analíticas), ~2x más rápido OLTP, escáner de caché ultra rápido, escala de réplicas de lectura sin lag.\nCandidato cuando Cloud SQL se queda corto en performance y el presupuesto existe.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Firestore: modelo de datos y reglas",
   "a": "Documentos JSON (~1MB) en colecciones; subcolecciones anidadas; documentos con IDs.\nConsultas con índices (compuestos automáticos/manuales); SIN joins ni agregados complejos (count/sum básicos).\nRealtime listeners y offline sync (móvil/web) — su superpoder.\nSecurity Rules: permisos por documento evaluados en el cliente-borde (para apps directas).",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Firestore: límites que definen si te sirve",
   "a": "1MB/doc, 500 writes/seg por documento (hotspot), sin queries OR amplios ni 'NOT IN' complejos, consistencia eventual entre documentos (tx solo sobre doc/grupo).\nDiseño: denormalizar, arrays acotados (array de 10k = antipatrón), distribuir writes con sharded counters.\nAnalítica pesada → exportar a BigQuery.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Spanner: qué lo hace único (TrueTime y global)",
   "a": "SQL relacional DISTRIBUIDO con consistencia EXTERNA (strong) global — TrueTime (relojes atómicos GPS) permite transacciones serializables a escala planetaria.\nEscalas horizontalmente sin sharding manual (interleave/tablas hijas para localidad).\nCosto alto (nodos + storage): para fin-tech, inventario global, SaaS multi-tenant serio.\n99.999% multi-región.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Bigtable: diseño de row key que todo el mundo hace mal",
   "a": "Rendimiento = distribución de filas por row key. MAL: timestamp puro al inicio (todo cae en un nodo — hotspot). BIEN: prefijo reversado/distribuido + timestamp reversado para 'lo más nuevo primero': user#reversed_ts.\nWide-column: miles de versiones por celda, GC policies por edad/versión.\nCasos: series temporales IoT, telemetría, fin personalizado de HBase.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Matriz de decisión de bases de datos GCP (entrevista clásica)",
   "a": "Relacional simple gestionado → Cloud SQL. Postgres a escala/analítica → AlloyDB. Relacional global ultra-consistente → Spanner. Documentos + realtime/offline móvil → Firestore. Series temporales/IoT masivo → Bigtable. Caché/sesiones → Memorystore. Analítica OLAP → BigQuery. Blobs/archivos → Cloud Storage.\nPregunta clave: patrón de acceso + consistencia + escala + presupuesto.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Bases de datos",
   "q": "Database Migration Service: migrar con mínimo downtime",
   "a": "DMS: réplica continua desde MySQL/Postgres/SQL Server (on-prem u otro cloud) a Cloud SQL/AlloyDB con CDC (binlog/WAL).\nCutover: cortar escrituras origen → esperar lag 0 → promover destino → redirigir app.\nHomogeneous principalmente; heterogéneo vía tools adicionales (PgBouncer/assessment).\nPrueba: run pre-migration assessment.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Memorystore para Redis: HA, tamaño y patrones de uso",
   "a": "Tiers: Basic (sin réplica, barato) vs Standard (réplica + failover); cluster mode para >5GB o sharding.\nUso: caché de resultados, sesiones, rate limiting (INCR), leaderboards (sorted sets), locks con SET NX PX.\nEviction policy: allkeys-lru típico de caché; volatile-ttl si mezclas.\nPersistencia (RDB) opcional — Redis como caché no la necesita.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Caching pattern: cache-aside implementado bien",
   "a": "Lectura: 1) buscas en Redis, 2) miss → BD, 3) guardas en Redis con TTL + jitter.\nEscritura: actualiza BD → invalida/actualiza caché (delete, no write-through, para evitar race).\nClaves con namespaces: prod:user:42.\nSerialize DTOs compactos (JSON/protobuf); nunca entidades JPA con lazy.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Bases de datos",
   "q": "Cloud SQL performance: los 6 knobs que mueven la aguja",
   "a": "1) Tamaño de instancia correcto (CPU/RAM p95).\n2) Índices con EXPLAIN ANALYZE (missing index = sec scan).\n3) Connection pooling: Hikari + max_connections coherentes; PgBouncer si apps múltiples.\n4) flags: innodb_buffer_pool_size / shared_buffers ~70% RAM.\n5) read replica para analítica.\n6) SSD PD y maintenance window fuera de picos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Bases de datos",
   "q": "Secrets y datos sensibles en BDs: cifrado y acceso",
   "a": "At-rest: cifrado por defecto; CMEK si compliance exige.\nEn tránsito: SSL obligatorio (force SSL flag) + IAM-auth (Cloud SQL IAM authentication: usuarios = identidades Google).\nPasswords de app: Secret Manager, nunca en properties.\nAuditoría: Cloud SQL audit logs para SELECT/UPDATE de tablas sensibles (PII).",
   "nivel": "intermedio",
   "clave": false
  }
 ]
}