{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "IAM y seguridad",
   "q": "Defensa en profundidad en GCP: las 6 capas",
   "a": "1) Identidad: IAM mínimo, MFA, Federation.\n2) Perímetro: VPC-SC, org policies, Armor.\n3) Red: private IPs, firewall deny-by-default, NAT controlado.\n4) Datos: cifrado (CMEK), DLP, retention.\n5) Aplicación: secretos, image scanning, Binary Authorization.\n6) Operación: SCC, audit logs, alertas.\nNinguna capa sola basta; el ataque se detiene en el anillo que no esperaba.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "IAM y seguridad",
   "q": "Rotación de secretos sin downtime: patrón completo",
   "a": "1) Secret Manager guarda versión N; app cachea con TTL.\n2) Rotación: crear versión N+1 (doble válido en BD si es password) → esperar TTL de cache → invalidar N.\n3) Automatizar: Secret Manager rotation schedule + Cloud Function/Run que cambia la BD y publica evento.\nConexiones vivas viejas: drain con max lifetime de pool < período de rotación.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "IAM y seguridad",
   "q": "Cloud Armor rate limiting y bot management",
   "a": "Reglas rate-based: throttle por IP (N req/min), ban temporal al exceder; por cookie/header con Expression language.\nBot management (Enterprise): reCAPTCHA Enterprise integrado — score por request, desafíos.\nGeo + ASN blocking para mercados definidos.\nMétricas de la policy → detectar ataques en curso antes del SLO burn.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "GKE networking: VPC-native (alias IPs) y por qué importa",
   "a": "VPC-native: pods reciben IPs DE LA SUBRED (secondary range) → visibles/ruteables en la VPC, firewall por pod, mejor para service mesh y politiques.\nRoutes-based (legado): NAT de IP de nodo — rompe firewalls por pod.\nRequisito para Shared VPC, Cloud NAT por pod, Network Policies con Dataplane V2.\nPools nuevos ya son VPC-native por default.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Dataplane V2 y Network Policies: rendimiento + seguridad",
   "a": "Dataplane V2 (eBPF, Cilium): NetworkPolicies más eficientes, logging/observabilidad de flujos (kube API, flow export) — habilitarlo en la creación del cluster.\nSin DPv2: Calico alternativo.\nPolicy audit mode: loguea sin bloquear para calibrar antes de enforce.\nReglas ejemplo: frontend→backend:8080 only, backend→db:5432 only.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "StatefulSet, PVs y discos en GKE",
   "a": "StatefulSet: identidad estable (nombre ordinal), PVCs por réplica (volumeClaimTemplates) — para BDs autoalojadas.\nPD CSI driver: persistent disks/zonal, Filestore para NFS, Cloud SQL proxy en vez de correr DB en k8s (recomendado).\nBackup: Velero a GCS.\nRegla de oro: en GKE el state EXTERNO (managed DBs), el clúster Stateless.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Node auto-provisioning y bin packing: optimizar costo de clúster",
   "a": "NAP: crea node pools automáticamente según los pods pendientes (por tipo de máquina/GPU) — no precises pools.\nCombinar con: cluster autoscaler scale-down (vaciar nodos), pod anti-affinity razonable (no desperdiciar nodos), requests REALES de recursos (over-request = dinero tirado).\nVer nodos zombis: kubectl get nodes + utilization dashboard.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Release channels y upgrades de GKE sin sustos",
   "a": "Channels: rapid/regular/stable — Google patchea nodos y control plane automáticamente.\nEstrategia: clúster de stage en rapid para ver el futuro; prod en regular.\nMaintenance windows y exclusions para no parchear en picos.\nPodDisruptionBudgets + surge upgrades: la app sobrevive al drenaje de nodos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Cloud SQL como servicio en GKE: proxy sidecar vs connector",
   "a": "Sidecar del Auth Proxy (contenedor junto a tu app): conexiones locales por socket unix, IAM auth, cifrado — el patrón estándar.\nEn Autopilot: workload identity + proxy con recursos asignados.\nDirect private IP + gcp cloud-sql-proxy como DaemonSet para muchas apps.\nPool sizing: cada instancia de app abre sus conexiones — cuenta el total vs max_connections de la BD.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "BigQuery ML: modelos sin salir del almacén",
   "a": "CREATE MODEL ... OPTIONS(model_type='logistic_reg') AS SELECT ... — entrena en SQL.\nPredicción: ML.PREDICT(MODEL m, TABLE t); evaluación ML.EVALUATE.\nTipos: regresión, clasificación, clustering (kmeans), time series (ARIMA), matrices.\nCasos: churn simple, forecasting de demanda — sin mover datos a otra plataforma.\nPara ML serio: Vertex AI, pero BQML cubre el 80% analítico.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Analítica de datos",
   "q": "Vertex AI: qué ofrece end-to-end",
   "a": "Datasets + entrenamiento (AutoML / custom containers), Feature Store, Model Registry, endpoints de serving (online/batch), Pipelines (Kubeflow) para MLOps, model monitoring de drift.\nGenerative: Vertex AI Studio, Gemini API, grounding con tus datos (RAG), embeddings + Vector Search.\nCosto: cómputo por hora de entrenamiento + serving por nodo-hora.\nEs el 'AWS SageMaker' de GCP.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Pub/Sub Lite vs Pub/Sub: el caso especial",
   "a": "Lite: particiones/zonas fijas, costo por capacidad reservada MUCHO menor para streaming continuo masivo (telemetría), modelo Kafka-like (offsets).\nPub/Sub: global, dinámico, features ricas (schemas, filters, push).\nLite recomendado para volúmenes predecibles enormes con presupuesto apretado; Pub/Sub para todo lo demás.\n(Nota: está en sunset gradual hacia managed Kafka — evaluar BigQuery subscription/direct Kafka).",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Mensajería y eventos",
   "q": "Ordering + exactly-once: recipe final con Pub/Sub",
   "a": "Ordering key por entidad + enable_message_ordering en subscription + endpoint regional (mismo región del topic).\nExactly-once delivery (regiones soportadas): no duplicados con retry del mismo mensaje.\nAun así: consumidor idempotente (dedup table) — la defensa final.\nMonitorear 'oldest unacked message' por ordering key para bloqueos.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Almacenamiento",
   "q": "Diseño de buckets multi-entorno sin filtros de datos cruzados",
   "a": "Separación por proyecto (dev/stage/prod) — cada entorno su bucket, su IAM.\nDentro: prefijos por dominio y fecha (invoices/2025/09/). Evitar bucket único 'todo' con ACLs finas.\nPermisos por prefijo solo si IAM uniforme está OFF (anti-patrón) — mejor buckets separados.\nNombre del bucket = identidad global: usar sufijo random/hashed para evitar colisiones.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Redes",
   "q": "Troubleshooting de conectividad GCP: el árbol de decisión",
   "a": "1) ¿La VM/pod tiene IP esperada y rutas? (gcloud compute routes list)\n2) Firewall: regla allow aplicando al target correcto (tags/SA) y source correcto.\n3) Para servicios gestionados: Private Google Access / PSC / connector configurado?\n4) DNS: zona privada resolviendo el FQDN interno?\n5) Flow logs + firewall rules logging = evidencia del paquete denegado.\nConnectivity Tests (Network Intelligence) simula el path y dice dónde se corta.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Redes",
   "q": "TLS interno entre servicios: mTLS con service mesh en GCP",
   "a": "Istio (Anthos Service Mesh) en GKE: sidecars/ambient manejan mTLS automático entre workloads con identidades SPIFFE — sin tocar código.\nAutorización L7: AuthorizationPolicy (frontend puede llamar pedidos:GET, nada más).\nCloud Run/GKE sin mesh: TLS termina en LB; interno confía en red privada (menos fuerte).\nZero trust interno: mesh es la respuesta estándar.",
   "nivel": "avanzado",
   "clave": false
  }
 ]
}