{
 "subtemas": [],
 "tarjetas": [
  {
   "sub": "Compute y contenedores",
   "q": "Machine types: familias y cuál elegir",
   "a": "E2: costo mínimo (no garantiza hardware fijo) — dev, web ligera.\nN2/N2D: propósito general balanceado (la default de prod).\nC2/C3: compute optimizado (CPU puro). M2/M3: memoria enorme. A2/A3: GPU (ML).\nCustom shapes: vCPU/RAM a la carta en N2.\nRegla: empezar N2D estándar, medir, ajustar; Recommender sugiere.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Disks en Compute Engine: tipos y cuándo",
   "a": "Standard PD: barato, secuencial (backups). Balanced PD: default razonable. SSD PD: IOPS/throughput alto (DBs). Hyperdisk: máx performance desacoplada del tamaño.\nSnapshots: incrementales multi-region — backups programados (snapshot schedule).\nRegional PD: replicación sincrónica entre zonas para BDs auto-alojadas HA.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Managed Instance Groups: autoscaling y autohealing",
   "a": "MIG: grupo de VMs idénticas desde instance template.\nAutoscaling por CPU/utilización o métrica de LB; autohealing con health check (recrea VMs malas); rolling updates (surge/unavailable) y stateful MIGs.\nZonal (una zona) vs Regional (3 zonas — HA por diseño).\nEs 'Kubernetes sin Kubernetes' para apps simples.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Instance template + startup script: boot reproducible",
   "a": "Template: imagen, machine type, network, SA, metadata — inmutable; cambios = template nuevo + MIG rolling.\nStartup script (metadata startup-script): bash al boot — instalar paquetes, tocar configs.\nMejor: imagen dorada pre-baked (Packer/Cloud Build) + startup script mínimo = arranque rápido y determinista.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Spot VMs: patrón de uso correcto",
   "a": "Hasta 91% de descuento; Google puede EVICTAR (preemption notice de 30s).\nIdeal: workers de colas (Pub/Sub redeliver), batch, CI runners, render — todo con checkpoint/retry.\nNO para: API crítica, BDs, estado sin replicar.\nCombina con MIG (mezcla estándar + spot) para absorber picos baratos.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "OS Login y metadata server: acceso y datos de instancia",
   "a": "OS Login: SSH por permisos IAM (roles/compute.osLogin) — sin gestionar keys por VM, 2FA heredado, audit por usuario.\nMetadata server (169.254.169.254): la instancia lee su SA token, zona, custom metadata — así funcionan ADC sin claves.\nBloquear metadata con headers? No aplica (Google usa `Metadata-Flavor`).",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "GKE Autopilot vs Standard: decisión práctica",
   "a": "Autopilot: Google gestiona nodos (pagas por pods) — menos ops, seguridad por default (no root, hardened), SLA de pods; costo ligeramente mayor y menos control (taints, kernel).\nStandard: control total de node pools, DaemonSets, costos más bajos a gran escala — requiere equipo k8s.\nDefault moderno: Autopilot salvo necesidad específica.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Compute y contenedores",
   "q": "Node pools y taints/tolerations: aislar cargas",
   "a": "Node pool por tipo de carga: pool GPU (taint nvidia.com/gpu), pool spot, pool con máquina de memoria.\nTaint en el pool + toleration en el pod = solo ciertos pods aterrizan ahí.\nnodeSelector/affinity para ubicación (zona, tipo).\nAuto-upgrade por release channel (regular/stable) con ventanas de mantenimiento.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Workload Identity en GKE: pods con SA de Google sin claves",
   "a": "1) KA SA de Google + binding roles/iam.workloadIdentityUser al K8s SA.\n2) K8s SA anotada con iam.gke.io/gcp-service-account.\n3) Pod usa el K8s SA → metadata server entrega tokens de la Google SA.\nReemplaza key.json montados — el estándar de acceso a GCP desde GKE.",
   "nivel": "intermedio",
   "clave": true
  },
  {
   "sub": "Compute y contenedores",
   "q": "Ingress vs Gateway API vs Service de tipo LoadBalancer en GKE",
   "a": "Service LoadBalancer: IP externa por servicio (caro, uno por svc).\nIngress (GCE o nginx controller): rutas HTTP/HTTPS por host/path a Services — el clásico.\nGateway API (el sucesor): roles separados (Gateway vs HTTPRoute), portable entre vendors, traffic split nativo.\nNuevo diseño: Gateway API; Ingress sigue soportado.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "HPA y VPA: autoscaling de pods y nodos",
   "a": "HPA: replica PODS por CPU/mem o métricas custom (QPS de Prometeo) — la primera línea.\nVPA: recomienda/ajusta requests-limits por pod (right-sizing; modo recomendación en prod).\nCluster Autoscaler: añade/elimina NODOS cuando no caben pods o sobran.\nKEDA para scale por longitud de cola (event-driven).",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Network Policy en GKE: microsegmentación",
   "a": "K8s NetworkPolicy (Calico/Dataplane V2): default deny entre namespaces y permitir solo lo necesario (frontend→backend:8080, backend→db:5432).\nSin políticas, cualquier pod habla con todo (lateral movement fácil si uno se compromete).\nAplicar por fases: audit con logging primero, luego deny.",
   "nivel": "avanzado",
   "clave": false
  },
  {
   "sub": "Compute y contenedores",
   "q": "Container Registry → Artifact Registry: el switch obligatorio",
   "a": "Container Registry (gcr.io) deprecado; Artifact Registry (REGION-docker.pkg.dev/PROJECT/REPO/IMAGE).\nRepos tipados: docker, npm, maven, python, apt... por región (más cerca = pull más rápido y sin egress).\nRemote repos (proxy a Docker Hub) y vulnerabilidad scanning integrado.\ngcloud auth configure-docker region-docker.pkg.dev.",
   "nivel": "intermedio",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "Cloud Run: revisiones y traffic split (canary fácil)",
   "a": "Cada deploy crea una REVISIÓN inmutable (imagen + env + recursos).\ngcloud run services update-traffic svc --to-revisions svc-00002=10,svc-00001=90 — canary sin Kubernetes.\nTag una revisión (--tag blue) para URL de preview antes de servir tráfico.\nRollback = redirigir 100% a la revisión anterior (instantáneo).",
   "nivel": "basico",
   "clave": true
  },
  {
   "sub": "Serverless",
   "q": "Cloud Run: concurrencia y CPU allocation",
   "a": "Concurrency (default 80, max 1000): requests simultáneos por instancia — Node/async lo usa bien; Java/thread-per-request bajo (4-16) con más instancias.\nCPU allocation: solo-durante-request (barato, latencias frías al volver) vs always-allocated (background threads, gRPC servers, manteniendo cachés calientes).\nAjuste = costo vs latencia.",
   "nivel": "basico",
   "clave": true
  },
  {
   "sub": "Serverless",
   "q": "Min instances y cold starts en Cloud Run",
   "a": "Frío: nueva instancia = pull imagen + arranque JVM (1-3s+).\nMin instances = N instancias siempre calientes (costo fijo pero latencia estable) — 1-2 para APIs críticas.\nReducir frío: imagen distroless pequeña, JVM con CDS/AppCDS, arranque lazy de beans, startup CPU boost activado.",
   "nivel": "basico",
   "clave": true
  },
  {
   "sub": "Serverless",
   "q": "Cloud Run jobs y sidecars: capacidades menos conocidas",
   "a": "Jobs: tareas batch one-shot o programadas (migraciones, ETL) con paralelismo por task index — no atado a HTTP.\nSidecars (gen2): contenedores auxiliares en la misma instancia (proxy de service mesh, collector de logs) con lifecycle compartido.\nAmbos mantienen el modelo serverless sin Kubernetes.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "Cloud Functions 2ª gen: qué hereda de Cloud Run",
   "a": "Gen2 ES Cloud Run por debajo: cualquier runtime con Functions Framework, timeouts hasta 60 min, más memoria/CPU, concurrency, Eventarc triggers nativos (60+ fuentes de eventos), tráfico por revisiones.\nGen1: legado (timeouts 9 min, triggers limitados).\nNuevo código: siempre gen2 o Cloud Run directo.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "Eventarc: el bus de eventos estándar de GCP",
   "a": "Rutea eventos (Cloud Audit Logs, Pub/Sub, GCS, Firebase, custom) a Cloud Run/Functions/GKE con filtros por tipo/atributos.\nEjemplo: 'cuando un objeto se suba a gs://facturas con prefijo xe/', invoca Cloud Run procesar.\nReemplaza triggers ad-hoc de gen1; entrega at-least-once con retry configurable.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "App Engine en 2024+: ¿todavía tiene sentido?",
   "a": "Standard: runtimes gestionados muy simples, scale to zero histórico, pero restricciones de runtime.\nFlexible: VMs gestionadas (menos serverless de verdad).\nNuevos proyectos: Cloud Run cubre el 95% (contenedor portable, concurrencia, revisiones).\nApp Engine sigue operado para apps existentes; no es la recomendación de partida hoy.",
   "nivel": "basico",
   "clave": false
  },
  {
   "sub": "Serverless",
   "q": "Elegir ambiente de ejecución: matriz de decisión rápida",
   "a": "Contenedor HTTP/API → Cloud Run.\nFunción pequeña evento-driven → Cloud Functions gen2.\nTarea batch → Cloud Run Jobs (o Batch service para HPC).\nMuchos microservicios con malla/ecosistema k8s → GKE.\nVM con software legado/licencias → Compute Engine.\nSin servidores y con BD gestionada → App Engine solo si ya vives ahí.",
   "nivel": "basico",
   "clave": true
  }
 ]
}