Google PCA: DevOps, Ingeniería de Entrega e Infraestructura como Código — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

DevOps, la ingeniería de entrega (Delivery Engineering) y la infraestructura como código (IaC) en Google Cloud se centran en entregar cambios fiables de forma continua con una sólida trazabilidad, automatización y seguridad. Las arquitecturas deben optimizarse para ciclos de retroalimentación cortos, despliegues repetibles, infraestructura inmutable y barreras de protección que escalen con la organización. En Google Cloud, esto normalmente combina las mejores prácticas de control de código fuente; CI con Cloud Build; gestión de artefactos con Artifact Registry; CD con Cloud Deploy; Kubernetes con GKE usando manifiestos, Helm o Kustomize; GitOps para el control de la deriva de configuración; e IaC con Terraform o las plantillas de despliegue de Google Cloud. La excelencia operativa requiere una entrega progresiva (azul-verde, canary, división de tráfico y feature flags), controles de la cadena de suministro de software (escaneo, procedencia, firma), puertas de prueba y despliegue, y una gobernanza que equilibre la velocidad, la seguridad, la auditabilidad y la propiedad.

CI/CD, control de código fuente y orquestación de lanzamientos

Principios de CI/CD
- Mantén la rama master/main en un estado desplegable; practica el desarrollo basado en el tronco (trunk-based development) con ramas de funcionalidad de corta duración.
- Automatiza la compilación, las pruebas, el escaneo y el empaquetado en cada cambio; exige la revisión de código con aprobaciones obligatorias y comprobaciones de estado.
- Mantén una trazabilidad completa desde el commit → compilación → digest del artefacto → lanzamiento en el entorno; incrusta los SHA de los commits y los metadatos de la compilación en las imágenes y las anotaciones del despliegue.
- Modos de fallo: las ramas de larga duración, las transferencias manuales, las pruebas inestables (flaky tests), las compilaciones no reproducibles y la falta de inmutabilidad de los artefactos provocan sorpresas tardías y reversiones (rollbacks).
Control de código fuente, ramificaciones, pull requests, revisión de código y trazabilidad
- Usa ramas protegidas, revisiones obligatorias y firma de commits. Etiqueta los lanzamientos y mantén un changelog generado a partir de los merge commits.
- Aplica CODEOWNERS y metadatos de propiedad del servicio para reforzar la custodia del dominio.
- Conecta los commits con las incidencias y los despliegues; exporta los registros y metadatos de CI/CD a Cloud Logging y BigQuery para auditorías y métricas DORA.
Cloud Build
- Disparadores (Triggers): se activan por eventos de Git (rama, etiqueta, PR), invocaciones manuales o Pub/Sub. Parametriza con sustituciones para la versión, el entorno y las feature flags para mantener los pipelines DRY.
- Pasos de compilación (Build steps): ejecuta builders oficiales o contenedores que tú definas; usa pasos en paralelo cuando sean independientes para reducir la latencia; utiliza cachés para las dependencias del lenguaje para acelerar las compilaciones.
- Artefactos: sube imágenes a Artifact Registry con etiquetas e identificadores únicos (digests) inmutables; almacena los SBOM y los registros de compilación; publica los informes de pruebas como artefactos de compilación.
- Identidades de compilación seguras: ejecuta Cloud Build con una cuenta de servicio dedicada con el mínimo privilegio y, cuando sea posible, con Workload Identity Federation por repositorio. Para redes privadas o para evitar el tráfico de egreso, utiliza Private Pools. Limita las claves de cuentas de servicio; prefiere los tokens de corta duración.
- Ejemplo (abreviado):
  - cloudbuild.yaml:
    - steps:
      - name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
      - name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
    - substitutions:
      - _ENV=staging
Cloud Deploy
- Lanzamientos (Releases) y destinos (targets): modela un canal de entrega con promoción entre destinos (p. ej., dev → staging → prod). Un lanzamiento (release) captura una referencia a un artefacto inmutable y su configuración de despliegue.
- Aprobaciones y promoción: exige aprobaciones manuales o automatizadas con control basado en roles. La promoción debe ser una acción rápida y de bajo riesgo, ya que el artefacto y los manifiestos no cambian.
- Despliegue canary y reversión (rollback): define estrategias para la exposición progresiva, las comprobaciones de estado (health checks) y la reversión automática en caso de errores de SLO. Registra cada promoción, aprobador y resultado de verificación para fines de auditoría.
- Modos de fallo: los artefactos mutables entre entornos, el uso manual de kubectl en producción o la omisión de la verificación previa al despliegue causan deriva (drift) e interrupciones no rastreables.

Infraestructura como código y gestión de la configuración

Terraform
- Módulos: capturan patrones reutilizables (p. ej., VPCs, clústeres de GKE, cuentas de servicio, vinculaciones de IAM). Versiona y fija las versiones de los módulos; publica registros de módulos internos.
- Estado remoto: almacénalo en Cloud Storage con control de versiones, política de retención y CMEK; habilita el bloqueo; restringe el acceso mediante IAM y el acceso uniforme a nivel de bucket; respalda el estado.
- Planes y verificaciones de políticas: ejecuta

undefined

en CI; requiere una revisión humana del plan; impón políticas como código (OPA/Conftest, Sentinel o Policy Controller) para bloquear infracciones (p. ej., buckets públicos, vinculaciones de IAM amplias).

Promoción de entornos: usa workspaces separados o estados/backends separados por entorno; promueve los cambios a través de las mismas versiones de módulos y variables; nunca edites manualmente los recursos en la nube. Las entradas sensibles deben provenir de Secret Manager o de la automatización, nunca estar codificadas.
Modos de fallo: filtración de secretos en el estado, cambios concurrentes sin bloqueo, deriva (drift) por ediciones fuera de banda y dependencias implícitas que rompen las operaciones de destrucción/reemplazo.
Plantillas de despliegue de Google Cloud y configuración declarativa
- Usa herramientas declarativas (Terraform, Google Cloud Deployment Manager o Kubernetes Configuration as Code) para definir el estado deseado en lugar de scripts con pasos imperativos.
- Prefiere la infraestructura inmutable: reemplaza las plantillas de instancia y despliega los MIGs; despliega nuevos Deployments de GKE en lugar de parchear los pods existentes. Los patrones inmutables simplifican el rollback y la auditoría.
- Deployment Manager admite plantillas Jinja/Python para recursos de Google Cloud, pero se limita a Google Cloud; Terraform ofrece un ecosistema más amplio y herramientas de políticas. Selecciona en función de la estandarización y las habilidades de la organización.
Manifiestos de Kubernetes, Helm, Kustomize y GitOps
- Manifiestos: mantén plantillas base con superposiciones (overlays) de entorno; parametriza solo lo que debe variar por entorno (p. ej., réplicas, límites, endpoints).
- Helm: empaqueta, crea plantillas y versiona servicios con charts; bloquea las dependencias; fija los digests de las imágenes. Modo de fallo: el exceso de plantillas (over-templating) oculta la intención y complica la revisión.
- Kustomize: gestiona superposiciones (base + parches de entorno); más simple que Helm cuando Kubernetes puro es suficiente.
- GitOps: un controlador (p. ej., Config Sync, Argo CD, Flux) reconcilia continuamente los clústeres con el estado deseado en Git; cada cambio es un PR con revisión y un registro de auditoría. Detecta y corrige la deriva (drift) automáticamente.

Entrega progresiva, cadena de suministro, pruebas y verificación

Feature flags y gestión del tráfico
- Los feature flags desacoplan el despliegue del lanzamiento; úsalos para una exposición gradual, pruebas A/B e interruptores de emergencia (kill switches). Asegúrate de que los estados de los flags estén versionados y sean auditables; retira los flags obsoletos.
- División del tráfico: en Cloud Run, usa el enrutamiento basado en porcentajes entre revisiones; en GKE, usa un service mesh o controladores de ingress que admitan el enrutamiento ponderado. Para las API bajo un único nombre de host/TLS, mantén servicios de backend separados por ruta detrás del HTTP(S) Load Balancer; el enrutamiento por ruta aísla limpiamente las versiones antiguas y nuevas mientras se conserva una única URL y certificado.
- Azul-verde (Blue-green): ejecuta dos stacks listos para producción; cambia el tráfico de forma atómica a través del balanceador de carga, selectores de servicio o el tráfico de revisión de Cloud Run. Permite un rollback instantáneo, pero duplica el costo en estado estable.
- Canary y despliegue progresivo: aumenta gradualmente el tráfico desde una pequeña porción mientras mides las señales doradas (golden signals) y los KPI de negocio; automatiza el rollback en caso de regresión.
Controles de la cadena de suministro de software
- Análisis de imágenes: habilita el análisis de vulnerabilidades de Artifact Analysis; falla las compilaciones por vulnerabilidades críticas o imágenes base con problemas conocidos; mantén una cadencia de parches.
- Procedencia y firma: genera procedencia de compilación compatible con SLSA en Cloud Build; firma los artefactos con Cosign; impón políticas de Binary Authorization que requieran atestaciones antes del despliegue.
- Gestión de dependencias: fija versiones y digests, mantén SBOMs, almacena localmente (vendor) las dependencias críticas y verifica las sumas de comprobación (checksums). Los modos de fallo incluyen la deriva de dependencias transitivas y los registros comprometidos.
Pirámide de pruebas, puertas de despliegue y verificación posterior al despliegue
- Pirámide: enfatiza las pruebas unitarias rápidas; añade pruebas de integración y de contrato; ejecuta pruebas de extremo a extremo (end-to-end) específicas. Mantén los datos de prueba realistas y desidentificados (usa Cloud DLP para eliminar PII).
- Puertas de despliegue: impón umbrales para la tasa de aprobación de pruebas, el estado de vulnerabilidad, el cumplimiento de políticas y la revisión de código antes de la promoción; requiere aprobación manual para producción cuando el riesgo es elevado.
- Verificación posterior al despliegue: ejecuta pruebas de humo (smoke tests), verificaciones sintéticas y análisis canary usando Cloud Monitoring, Error Reporting y Trace. Si los KPI se degradan, activa un rollback automatizado y abre un incidente con el contexto capturado.
- Diagnósticos operativos: despliega el agente de Cloud Logging donde sea necesario e instrumenta los servicios para Trace y Debugger. Mantén runbooks para una remediación segura (p. ej., redimensionar un disco persistente en línea y ejecutar

undefined

con un tiempo de inactividad mínimo).

Gobernanza, seguridad, auditabilidad y propiedad

Velocidad con seguridad
- El desarrollo basado en el troncal (trunk-based development) con PR de corta duración y revisión obligatoria mantiene el flujo sin sacrificar la calidad.
- Las canalizaciones de autoservicio con plantillas para pilas comunes (GKE + Helm, Cloud Run, Dataflow) aceleran a los equipos y reducen el riesgo de soluciones a medida.
Acceso, identidad y aprobaciones
- Usar cuentas de servicio dedicadas por cada etapa de la canalización con el privilegio mínimo y Workload Identity Federation; evitar claves estáticas.
- Separar responsabilidades: los desarrolladores construyen; los responsables de lanzamiento (release managers) aprueban la promoción a producción; los operadores de tiempo de ejecución son dueños de la configuración y los presupuestos del entorno de ejecución.
Auditabilidad y cumplimiento
- Exportar los registros de Cloud Build, Cloud Deploy y Cloud Audit Logs a BigQuery. Usar vistas de conjuntos de datos (dataset views) e IAM para compartir datos de auditoría con alcance definido con los auditores. Retener métricas a largo plazo exportándolas a Cloud Storage o BigQuery según la política.
- Registrar los resúmenes (digests) de los artefactos en los metadatos del despliegue. Mantener un SBOM y una procedencia de extremo a extremo para cada lanzamiento.
Propiedad y SLO
- Cada servicio tiene un propietario, una rotación de guardia, SLO y presupuestos de error que condicionan los lanzamientos. Vincular las políticas de despliegue al cumplimiento de los SLO para evitar impulsar cambios cuando el presupuesto está agotado.
Compromisos y escollos comunes
- Costo de azul-verde vs. velocidad de reversión; confianza del canario vs. tiempo hasta el lanzamiento completo.
- Consistencia de GitOps vs. flexibilidad operativa; permitir “romper el cristal” (break-glass) de forma controlada con registro y PR de seguimiento.
- El exceso de plantillas reduce la legibilidad; mantener la configuración explícita y mínima.
- La política centralizada previene la configuración incorrecta, pero debe desplegarse de forma iterativa para evitar bloquear a los equipos innecesariamente.

Escenario de Problema Práctico

Empresa: Borealis Fintech

Desafío: Borealis está lanzando una nueva API de pagos en GKE mientras mantiene las versiones v1 y v2 bajo el mismo nombre de host y TLS. Necesitan trazabilidad de extremo a extremo, entrega progresiva con canario y feature flags, controles estrictos de la cadena de suministro y promociones auditadas entre los entornos de desarrollo (dev), preproducción (staging) y producción (prod). También quieren usar GitOps para la configuración del clúster y Terraform para los recursos de la plataforma.

Enfoque:

Establecer control de código fuente y estrategia de ramas
- Crear un monorepo con directorios de servicios y un repositorio de infraestructura separado. Forzar la protección de la rama main, revisiones de PR obligatorias, CODEOWNERS y commits firmados. Justificación: flujo basado en el troncal con propiedad clara e historial listo para auditoría.
Construir artefactos con Cloud Build y Artifact Registry
- Definir un cloudbuild.yaml para construir y subir imágenes etiquetadas con $COMMIT_SHA y anotadas con SBOM y procedencia. Usar una cuenta de servicio de Cloud Build dedicada con privilegio mínimo y un Private Pool. Justificación: compilaciones reproducibles y aisladas con resúmenes rastreables.
- Ejemplo:
  - gcloud artifacts repositories create app –repository-format=docker –location=us
Implementar controles de la cadena de suministro de software
- Habilitar el análisis de vulnerabilidades en Artifact Registry. Generar procedencia y firmar imágenes con Cosign en los pasos posteriores a la compilación en Cloud Build. Configurar Binary Authorization para requerir firmas y la aprobación del análisis antes de desplegar en GKE. Justificación: bloquear artefactos no confiables o vulnerables en el momento de la aplicación de la política.
Modelar la entrega con Cloud Deploy
- Definir una canalización de entrega con destinos dev, staging, prod y una estrategia de canario para prod. Requerir aprobación manual para prod con aprobadores basados en roles. Justificación: promoción inmutable y aprobaciones auditables.
- clouddeploy.yaml (extracto):
  - strategy:
    - canary:
      - canaryDeployment:
        percentages: [5, 25, 50, 100]
Enrutar las API v1 y v2 bajo el mismo nombre de host
- Configurar un Balanceador de Carga HTTP(S) externo con servicios de backend separados para las rutas /v1 y /v2, cada uno apuntando al NEG de GKE correspondiente. Justificación: aislamiento limpio basado en rutas, mismo certificado y DNS, y capacidad de despliegue independiente.
- Ejemplo (extracto):
  - gcloud compute url-maps add-path-matcher api-map –path-matcher-name api-pm –default-service v1-bes –path-rules="/v1/=v1-bes,/v2/=v2-bes"
Gestionar la infraestructura con Terraform
- Crear módulos para VPC, GKE, Artifact Registry, cuentas de servicio e IAM. Almacenar el estado remoto en un bucket de Cloud Storage protegido con CMEK con versionado y retención. Aplicar políticas de OPA en CI para prevenir cambios riesgosos. Justificación: aprovisionamiento de plataforma reutilizable, revisable y gobernado.
- backend “gcs” { bucket = “borealis-tf-state” prefix = “prod” }
Configurar Kubernetes con Helm/Kustomize y GitOps
- Mantener manifiestos base para la API y superposiciones (overlays) por entorno usando Kustomize. Usar Config Sync o Argo CD para reconciliar los clústeres con el estado de Git. Justificación: operaciones declarativas, auditables y resistentes a la deriva (drift).
Entrega progresiva con canario y feature flags
- Usar el canario de Cloud Deploy para prod y un SDK de feature flags (OpenFeature) para controlar la nueva lógica. Comenzar con el 5% del tráfico, promover automáticamente si los SLO son saludables; revertir automáticamente en caso de degradación y usar el flag como un interruptor de emergencia (kill switch). Justificación: reducir el radio de impacto y desacoplar el despliegue del lanzamiento.
Controles de calidad y verificación
- Etapas de la canalización: pruebas unitarias → pruebas de integración contra un entorno efímero → escaneo de contenedores → verificaciones de políticas → pruebas de extremo a extremo en staging → canario en prod con verificación automatizada basada en SLO (Cloud Monitoring, Error Reporting, Trace). Justificación: retroalimentación rápida y temprana, seguridad robusta antes de prod y verificaciones de estado objetivas después del despliegue.
Operaciones, registro y auditoría
- Instalar agentes de Cloud Logging/Monitoring para las VM de soporte y habilitar los registros/métricas de las cargas de trabajo de GKE. Exportar los registros de CI/CD y de auditoría a BigQuery con vistas de alcance definido para los auditores. Mantener runbooks (incluyendo procedimientos de reversión segura y de cambio de emergencia de DNS o LB). Justificación: observabilidad para una remediación rápida y evidencia lista para el cumplimiento.

Este diseño preserva la velocidad con un flujo basado en el troncal y canalizaciones automatizadas; la seguridad con canario, feature flags y Binary Authorization; la auditabilidad con artefactos inmutables, aprobaciones y registros centralizados; y una propiedad clara a través de CODEOWNERS y entornos controlados por GitOps.

← Operaciones · Todos los dominios · Costo →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →