Google PCD: Entrega continua, configuración y automatización de infraestructura — Guía de estudio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Developer — 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

La entrega continua en Google Cloud integra la automatización de compilaciones, la gestión de artefactos, la orquestación de despliegues, la infraestructura como código y una gobernanza sólida para entregar cambios de forma repetida y segura. Las canalizaciones robustas combinan artefactos inmutables y configuración declarativa con políticas y auditabilidad. Esta sección explica las opciones de diseño, las prácticas operativas y los modos de fallo comunes al implementar Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, indicadores de funciones (‘feature flags’) y controles de gobernanza de extremo a extremo.

Orquestación de compilación y despliegue

Cloud Build

• Activadores: Conecte las compilaciones a eventos de origen (envíos a ramas, etiquetas, PRs) o a programaciones. Prefiera expresiones regulares para ramas o etiquetas para asegurar que solo las referencias deseadas se activen. Los activadores pueden ejecutarse con una cuenta de servicio específica para aplicar el mínimo privilegio; no confíe en la predeterminada si las compilaciones necesitan un amplio acceso a la API.
• Pasos de compilación: Cada paso se ejecuta en un contenedor. Use compiladores específicos (docker, gcloud) o compiladores personalizados cuando la cadena de herramientas predeterminada sea insuficiente. Separe los pasos para compilar, pruebas unitarias, pruebas de integración, ’linting’, análisis de seguridad y empaquetado de artefactos para que los fallos sean atribuibles y se almacenen en caché de forma eficaz.
• Sustituciones: Use variables integradas (PROJECT_ID, SHORT_SHA) y sustituciones personalizadas (con el prefijo $_) para compilaciones parametrizadas. Mantenga los valores específicos del entorno fuera de la lógica de compilación; páselos como sustituciones o resuélvalos más tarde durante el despliegue.
• Cuentas de servicio: La cuenta de servicio de Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) requiere roles explícitos (por ejemplo, escritura en Artifact Registry, administrador de lanzamientos de Cloud Deploy). Asigne roles y alcance mínimos por proyecto. Para recursos privados, use Private Pools con conectividad VPC.
• Artefactos: Publique imágenes inmutables en Artifact Registry y, opcionalmente, suba artefactos que no sean contenedores a Cloud Storage a través de la sección de artefactos. Etiquete las imágenes tanto con una versión semántica como con el ‘digest’ del commit; use los ‘digests’ de las imágenes en los despliegues para evitar la deriva de etiquetas (’tag drift’).

Ejemplo de configuración de Cloud Build:

• cloudbuild.yaml: steps:

  • name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
  • name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
  • name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

• Ejemplo de activador: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

• Las canalizaciones de entrega (‘delivery pipelines’) definen etapas y destinos ordenados. Los destinos hacen referencia a clústeres de GKE, servicios de Cloud Run u otros ‘runtimes’ compatibles. Marque las etapas de producción con ‘requireApproval’ para controlar la promoción.
• Los despliegues progresivos (‘rollouts’) mapean un lanzamiento (‘release’) a un destino; la promoción avanza un lanzamiento a través de los destinos. Use entrega progresiva (canary, azul/verde) y ‘hooks’ para verificaciones previas y posteriores al despliegue.
• Modos de fallo: El uso de etiquetas mutables causa actualizaciones no deseadas; fije siempre los ‘digests’. La falta de IAM para la cuenta de despliegue bloquea los ‘rollouts’. Manifiestos no renderizables o deriva en la configuración específica del entorno provocan fallos en la promoción; valide los manifiestos durante la compilación.

Ejemplos de definiciones de Cloud Deploy:

• delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:

  • targetId: dev
  • targetId: prod strategy: standard: verify: true requireApproval: true

• targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER

  Definición del destino de producción

  apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER

• Lanzamiento y promoción: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefactos e integridad de la cadena de suministro

Artifact Registry

• Repositorios: Cree repositorios separados por equipo o entorno para acotar el IAM y la limpieza. Use repositorios regionales cerca de los compiladores y ‘runtimes’ para reducir el egreso y la latencia. Los formatos de paquete incluyen imágenes de Docker y paquetes de lenguajes (Maven, npm, PyPI).
• Retención: Defina políticas de limpieza para eliminar etiquetas antiguas o no referenciadas, manteniendo una ventana de seguridad para el ‘rollback’. Evite una retención agresiva que elimine la última versión funcional conocida.
• Procedencia y SBOM: Habilite la procedencia de la compilación para que las imágenes lleven atestaciones compatibles con SLSA. Genere SBOMs durante la compilación y almacénelos como atestaciones, mejorando la clasificación de vulnerabilidades.
• Análisis de vulnerabilidades: Habilite el análisis de contenedores e interrumpa la compilación o bloquee la promoción cuando se detecten CVE de alta gravedad sin correcciones disponibles o excepciones de política.
• Ventajas y desventajas: Centralizar todos los artefactos en un único proyecto simplifica la gobernanza, pero puede crear un radio de impacto (‘blast radius’); los repositorios por entorno o por aplicación reducen el riesgo, pero añaden sobrecarga de gestión.

Aplicación de la cadena de suministro

• Binary Authorization en GKE puede requerir atestaciones (por ejemplo, “compilado por Cloud Build en el proyecto X”, “sin CVEs críticos”). Intégrelo con las puertas (‘gates’) de Cloud Deploy para detener lanzamientos no conformes.
• Modos de fallo: Confiar en etiquetas mutables, análisis deshabilitados o ‘pulls’ no autenticados puede llevar a que software no verificado llegue a producción. Fije los ‘digests’ y requiera atestaciones.

Infraestructura como Código y GitOps

Terraform

• Configuración y módulos: Factoriza módulos reutilizables con entradas/salidas claras y versiones semánticas. Publica los módulos en un repositorio o registro compartido; fija las versiones para evitar cambios inesperados.
• Estado: Usa el backend de GCS para el estado remoto con IAM a nivel de bucket, versionado de objetos y CMEK. Protege el estado de ediciones manuales y asegura su cifrado. Evita secretos en el estado leyéndolos desde Secret Manager en el momento de la aplicación (apply) y usando data sources con moderación.

undefined

• Planes y aplicaciones (Plans and applies): Ejecuta terraform plan con -out y haz que una persona o una puerta de enlace automatizada revise la diferencia; aplica únicamente el plan previamente aprobado. Usa -refresh-only o -detailed-exitcode en los trabajos de detección de deriva (drift).
• Separación de entornos: Usa proyectos, buckets de estado y cuentas de servicio separados por cada entorno. Prefiere un directorio por entorno con archivos de variables en lugar de workspaces para organizaciones complejas. Nunca compartas el estado entre entornos.
• Modos de fallo: Las aplicaciones concurrentes corrompen el estado; impón la serialización con CI/CD y bloqueos (GCS usa precondiciones de objeto). Los cambios manuales en la consola causan deriva (drift); restringe las mutaciones directas y ejecuta trabajos de plan periódicos.

Configuración declarativa de Kubernetes

• Manifiestos: Mantén los objetos de Kubernetes de forma declarativa; evita los imperativos de kubectl en los flujos de producción. Fija los digests de las imágenes y las solicitudes/límites de recursos (requests/limits).
• Kustomize: Usa una base + overlays (superposiciones) para manejar parches específicos del entorno sin bifurcar (forking) los charts.

undefined

• Helm: Usa values files por cada entorno; documenta la precedencia (los valores de la línea de comandos sobreescriben los values files, que a su vez sobreescriben los valores por defecto del chart). Genera plantillas (template) y renderiza en CI (skaffold render o helm template) para que las configuraciones en tiempo de despliegue sean inmutables.
• GitOps: Almacena el estado deseado en Git. Usa Cloud Deploy o Config Sync para reconciliar los clústeres con Git. Los PRs (Pull Requests) se convierten en la superficie de control de cambios, con pistas de auditoría y verificaciones de políticas. Evita modificaciones con kubectl exec que no queden registradas en Git.

Seguridad en los lanzamientos, configuración y gobernanza

Feature flags y configuración en tiempo de ejecución

• Las feature flags (indicadores de funcionalidad) disocian el despliegue del lanzamiento; permiten enviar código inactivo y habilitarlo por cohorte, porcentaje o región. Almacena las definiciones de los indicadores en un sistema de alta disponibilidad (HA) y baja latencia (Firestore, Memorystore) y usa una caché con TTL cortos. Registra las evaluaciones para la trazabilidad.
• Despliegue gradual: Combina la división de tráfico (Cloud Run) o los subconjuntos canary (GKE) con feature flags para minimizar el radio de impacto. Utiliza métricas de salud y disparadores de rollback automatizados basados en SLO.
• Rollback seguro: Prefiere las desactivaciones rápidas mediante feature flags. Para un rollback de binario, promociona la última versión que se sabe que es correcta o vuelve a aplicar el digest del manifiesto anterior.

Variables de entorno, precedencia, secretos

• La precedencia comúnmente sigue este orden: indicadores de tiempo de ejecución > variables de entorno > archivos de configuración > valores predeterminados en el código. Documenta y estandariza esto en todos los servicios.
• Inyecta la configuración con ConfigMaps y variables de entorno; utiliza Secret Manager o Kubernetes Secrets para valores sensibles. Rota los secretos regularmente y evita incrustarlos en las imágenes.
• Ejemplos de inyección de secretos:
  • Variable de entorno en Cloud Run:

undefined

• CSI de Secret Manager en GKE:

undefined

Controles de calidad (quality gates) en CI/CD

• Las pruebas unitarias se ejecutan en cada commit; la retroalimentación rápida es primordial.
• Las pruebas de integración se ejecutan en entornos efímeros o sandboxes con datos pre-cargados.
• Comprobaciones de seguridad: SAST, escaneo de dependencias, escaneo de vulnerabilidades de contenedores, comprobaciones de políticas de IaC (Conftest, Policy Controller). Bloquea las fusiones (merges) o promociones ante hallazgos críticos.
• Comprobaciones de despliegue: Las acciones predeploy y postdeploy de Cloud Deploy validan la preparación, la seguridad de las migraciones de base de datos y las pruebas de humo (smoke tests).

Ramificación, revisión de código, versionado, trazabilidad

• Prefiere el desarrollo basado en el tronco (trunk-based development) con ramas de funcionalidad de corta duración y revisiones de PR obligatorias. Exige comprobaciones requeridas y un historial lineal para la auditabilidad.
• Versionado: Etiquetas de versión semántica para los lanzamientos; digests de imagen y SHAs de commit para la inmutabilidad. Evita etiquetas móviles como latest en los despliegues de producción.
• Trazabilidad: Anota las compilaciones y los lanzamientos con los ID de commit, PR y ticket. Emite eventos de despliegue a Logging; adjunta etiquetas a los recursos para el control de costos y propiedad.

Deriva de infraestructura (drift), políticas, auditoría, control de cambios

• Detección de drift: Ejecución programada de terraform plan -detailed-exitcode; alerta sobre códigos de salida distintos de cero. Para clústeres, Config Sync asegura la convergencia eventual con Git.
• Aplicación de políticas: Utiliza Organization Policy para barreras de protección (guardrails) (por ejemplo, restringir IPs externas), Policy Controller para restricciones KRM y Binary Authorization para políticas de imágenes.
• Registros de auditoría: Habilita los registros de Actividad del Administrador y de Acceso a los Datos; enrútalos a proyectos centralizados con sinks y una retención alineada con el cumplimiento normativo. Cloud Asset Inventory alimenta el historial de cambios y el análisis de acceso.
• Control de cambios: Aprobaciones manuales en las promociones a producción, con justificaciones capturadas como anotaciones. Las ventanas de congelación (freeze windows) se pueden codificar como comprobaciones de políticas en CI/CD. Asegúrate de que las rutas de rollback de emergencia estén documentadas y se pongan en práctica.

Escenario de un problema práctico

Acme Retail necesita desplegar un nuevo order-service en GKE en los entornos de desarrollo y producción con despliegues canary seguros, aplicación estricta de políticas y trazabilidad completa del lanzamiento. El equipo debe estandarizar la infraestructura gestionada con Terraform, la configuración declarativa de Kubernetes con Kustomize y un CI/CD auditable usando Cloud Build y Cloud Deploy.

Enfoque:

1. Establecer repositorios de artefactos e identidades

• Crear repositorios regionales de Artifact Registry order-docker-dev y order-docker-prod. Otorgar a la cuenta de servicio de Cloud Build en el proyecto de la aplicación los roles roles/artifactregistry.writer y a los nodos de ejecución de GKE el rol roles/artifactregistry.reader para el repositorio apropiado.
• Justificación: Los repositorios segregados reducen el radio de impacto y simplifican las políticas de ciclo de vida. El uso de IAM explícito evita los permisos por defecto excesivamente privilegiados.

2. Definir Terraform para la infraestructura con separación de entornos

• Crear los directorios terraform/envs/dev y terraform/envs/prod. Cada configuración incluye un backend de GCS con buckets de estado separados, un módulo de clúster de GKE y asignaciones de IAM para la cuenta de servicio de Cloud Deploy. Ejecutar terraform init, plan -out=plan.bin y apply plan.bin en un trabajo de CI con compuertas (gated) por cada entorno.
• Justificación: El estado y los proyectos por entorno previenen el impacto accidental entre entornos; los archivos de plan (plan files) facilitan la revisión y un control de cambios auditable.

3. Crear la base declarativa de Kubernetes y las superposiciones (overlays) de Kustomize

• Colocar los manifiestos de Kubernetes en k8s/base para Deployment, Service y HPA con imágenes fijadas (pinned) por su digest. Crear k8s/overlays/dev y k8s/overlays/prod con parches para réplicas, solicitudes de recursos y configuración. Usar una clase de CSI de Secret Manager para las credenciales de la base de datos.
• Justificación: Una única fuente de verdad con overlays elimina la deriva (drift) y mantiene las configuraciones DRY, a la vez que permite diferencias seguras y específicas para cada entorno.

4. Implementar Cloud Build con pasos de prueba y empaquetado distintos

• El archivo cloudbuild.yaml incluye los siguientes pasos: linting y pruebas unitarias, pruebas de integración contra un namespace de desarrollo desechable, compilación y envío del contenedor al repositorio del entorno, escaneo de SBOM y vulnerabilidades, y generación de procedencia. El trigger se ejecuta en los PR a main para las pruebas y en las fusiones (merges) para el empaquetado. Las compilaciones se ejecutan con una cuenta de servicio cb-deployer con privilegios mínimos.
• Justificación: Los fallos tempranos son baratos; separar las responsabilidades mejora la observabilidad y permite reintentos específicos. El principio de privilegios mínimos reduce el riesgo de la cadena de suministro.

5. Configurar el pipeline de entrega de Cloud Deploy con aprobación manual para producción y estrategia canary

• Definir un DeliveryPipeline con destinos (targets) de dev y prod. La etapa de prod requiere aprobación y utiliza una estrategia canary (por ejemplo, 10% y luego 100%). Usar hooks de predeploy para comprobaciones de compatibilidad de esquemas y pruebas de humo (smoke tests); los hooks de postdeploy verifican los SLO.
• Justificación: La entrega progresiva limita el radio de impacto e introduce controles de calidad automatizados, mientras que la aprobación manual impone la intervención humana (human-in-the-loop) para producción.

6. Conectar GitOps y la aplicación de políticas

• Proteger la rama main con revisiones obligatorias y comprobaciones superadas. Usar restricciones de Policy Controller para bloquear pods privilegiados y no permitir etiquetas mutables. Habilitar Binary Authorization para requerir procedencia de Cloud Build y atestaciones de «sin CVEs altos» antes de la admisión.
• Justificación: La política como código (Policy-as-code) previene que configuraciones arriesgadas lleguen al clúster y proporciona una aplicación consistente.

7. Gestionar la configuración y las feature flags para una entrega segura

• Almacenar la configuración de tiempo de ejecución no secreta en ConfigMaps; los secretos se proporcionan a través del CSI de Secret Manager. Introducir una feature flag order_new_flow leída desde Firestore con un despliegue inicial del 1% en producción; las flags se almacenan en caché con un TTL corto y se registran.
• Justificación: Las flags disocian el lanzamiento del despliegue, permitiendo una desactivación instantánea si surgen problemas sin necesidad de revertir (rollback) el binario.

8. Garantizar la observabilidad, la detección de drift y la trazabilidad

• Anotar las compilaciones y los lanzamientos con el SHA del commit, el número de PR y el ticket de cambio. Enrutar los eventos de Cloud Deploy y los registros de auditoría de GKE a un proyecto central de Logging. Trabajos nocturnos de terraform plan alertan sobre el drift; Config Sync supervisa la divergencia de KRM, reconciliando con Git.
• Justificación: La procedencia completa y las pistas de auditoría aceleran la respuesta a incidentes; la detección continua de drift mantiene la integridad de la infraestructura.

9. Operar rollbacks y control de cambios

• Para incidentes, primero desactivar order_new_flow a través de la feature flag. Si es necesario, promocionar la entrega exitosa anterior en Cloud Deploy a dev y prod. Todas las promociones a producción requieren una referencia de ticket en las anotaciones del lanzamiento y una aprobación del SRE de guardia.
• Justificación: Las flags proporcionan una mitigación instantánea; las entregas inmutables permiten un rollback predecible. Las aprobaciones y anotaciones satisfacen la gobernanza operativa y el cumplimiento normativo.

← Identidad · Todos los dominios · Observabilidad →

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

Explorar Google →