Google PCA: Operaciones, Observabilidad y Automatización de Plataformas — 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

Las Operaciones, Observabilidad y Automatización de Plataformas en Google Cloud aseguran que los servicios sean diagnosticables, mantenibles y mejorados continuamente, al tiempo que se controla la seguridad y el costo. Un diseño cohesivo abarca el registro (logging), las métricas, el trazado (tracing), la auditabilidad, los runbooks, la respuesta a incidentes, la gobernanza de cuotas y capacidad, y la automatización. El objetivo es obtener señales procesables y de bajo ruido vinculadas a los objetivos de nivel de servicio (SLO), junto con una automatización determinista que reduce el trabajo repetitivo y la deriva de configuración.

Registro y Auditabilidad

Cloud Logging centraliza los registros de los servicios de Google Cloud, GKE y las VM. Prefiera los registros estructurados (JSON) con claves consistentes para request_id, user_id, service, version, latency_ms y severity; los datos estructurados permiten consultas precisas, métricas basadas en registros y evaluación de políticas. En las VM y los nodos de GKE, instale el Ops Agent (preferido) o el agente de logging heredado para recopilar registros del sistema y de las aplicaciones; asegúrese de que los analizadores (parsers) emitan JSON para sus frameworks.

• Buckets de registros y retención: Utilice buckets de registros ubicados regionalmente para la residencia de datos y CMEK. Los buckets predeterminados incluyen _Default y _Required; este último almacena los registros de auditoría de Actividad del Administrador (Admin Activity), Eventos del Sistema (System Event) y Políticas Denegadas (Policy Denied) con una retención fija a largo plazo. Cree buckets dedicados por clase de datos (p. ej., aplicación, seguridad, análisis) con retención y CMEK personalizados. Una mayor retención mejora el análisis forense pero aumenta el costo; exporte para archivado a largo plazo cuando no se requiera la retención en Logging.

• Receptores de registros (sinks) y exportaciones: Enrute con el Log Router usando receptores hacia BigQuery (análisis), Pub/Sub (SIEM o pipelines) y Cloud Storage (archivado). Utilice tablas particionadas en BigQuery para gestionar el volumen y el costo. Otorgue siempre a la cuenta de servicio del receptor acceso de escritura con privilegios mínimos al destino para evitar fallos silenciosos. Evite los bucles de enrutamiento no reingiriendo los registros exportados de nuevo en Logging.

• Consultas y métricas basadas en registros: Use el Logs Explorer con filtros en los campos logName, resource.type, severity, labels y jsonPayload. Derive métricas basadas en registros (contador o distribución) para SLI de tasa de errores e histogramas de latencia, que sirvan de base para las alertas. Controle la cardinalidad normalizando los campos de alta varianza.

• Cloud Audit Logs: Los registros de Actividad del Administrador (Admin Activity, escrituras en el plano de control), Acceso a Datos (Data Access, lecturas/escrituras de datos de usuario), Eventos del Sistema (System Event) y Políticas Denegadas (Policy Denied) proporcionan observabilidad administrativa. Los registros de Acceso a Datos son de alto volumen y están deshabilitados por defecto para muchos servicios; habilítelos solo donde sea necesario y enrútelos a un bucket con la retención y CMEK adecuadas. Los registros de Políticas Denegadas ayudan a detectar tempranamente violaciones de permisos y de políticas de la organización. Asegure la segregación de custodia: los equipos de seguridad suelen ser los propietarios y tener acceso a los registros de auditoría, con vistas restringidas para otros equipos.

• Modos de fallo y contrapartidas:

  • Los receptores (sinks) demasiado amplios disparan los costos en BigQuery; filtre con precisión y configure la expiración de las particiones.
  • Los campos JSON de alta cardinalidad (p. ej., URL completas) degradan las consultas; sanitice y extraiga etiquetas normalizadas.
  • Una retención insuficiente dificulta las investigaciones; las exportaciones a GCS o BigQuery mitigan este riesgo.
  • La ausencia de un agente o configuraciones incorrectas del analizador (parser) causan pérdida silenciosa de registros; alerte sobre el latido (heartbeat) del agente y los errores de ingesta.

Ejemplo: crear un bucket de registros regional con retención personalizada y exportar un receptor (sink) de auditoría filtrado.

• gcloud logging buckets create app-logs –location=us-central1 –retention-days=30
• gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT/datasets/audit –log-filter=“logName:cloudaudit.googleapis.com AND protoPayload.serviceName:*” –use-partitioned-tables

Monitoreo, Trazado y Diagnóstico de Aplicaciones

Cloud Monitoring recopila métricas del sistema y de las aplicaciones, y ofrece soporte para dashboards, alertas, verificaciones de tiempo de actividad (uptime checks), canales de notificación y objetivos de nivel de servicio (SLO).

• Métricas y dashboards: Utilice las métricas integradas para los servicios de Google y cree métricas personalizadas a través de la API de Cloud Monitoring u OpenTelemetry. Ponga énfasis en las cuatro señales doradas: latencia, tráfico, errores y saturación. Aplique etiquetas con criterio; evite valores de etiqueta no acotados. Use Metrics Scope para agregar vistas de múltiples proyectos. Utilice MQL para consultas expresivas cuando sea necesario.

• Alertas y canales de notificación: Implemente alertas de múltiples ventanas y múltiples tasas de consumo (multi-burn-rate) para los SLO con el fin de equilibrar la detección rápida y la reducción de ruido. Defina canales de notificación (correo electrónico, SMS, Pub/Sub, webhooks, herramientas de incidentes de terceros) e incluya enlaces a runbooks y contexto en la documentación de las alertas. Use límites de frecuencia de notificación y el cierre automático de incidentes para prevenir tormentas de alertas.

• Verificaciones de tiempo de actividad (uptime checks): Sondee los puntos de conexión (endpoints) críticos desde múltiples regiones con verificación de TLS, DNS y coincidencia de contenido. Vincule las verificaciones de tiempo de actividad a las alertas y a los SLO del servicio. Recuerde que las verificaciones de tiempo de actividad no validan las dependencias internas; compleméntelas con transacciones sintéticas y verificaciones de estado internas.

• SLO y SLI: Defina SLI para disponibilidad, latencia y corrección. Configure los SLO en el Service Monitoring de Cloud Monitoring y haga un seguimiento de los presupuestos de error. Alerte sobre el consumo del presupuesto (budget burn), no sobre los errores brutos, para alinearse con el impacto en el cliente. Utilice puertas de lanzamiento (release gates) o entrega progresiva para respetar el presupuesto de error restante.

• Cloud Trace, Error Reporting, Profiler: Utilice el trazado distribuido entre servicios con OpenTelemetry para anotar los spans con metadatos de la solicitud y de las dependencias. Ajuste el muestreo dinámicamente por servicio y por ruta para asegurar la cobertura de los flujos críticos mientras se controla el costo. Error Reporting autoagrega las excepciones de los registros, las deduplica por traza de la pila (stack trace) y activa notificaciones. Profiler proporciona perfiles continuos de CPU, memoria heap y tiempo de reloj (wall-time) en producción con una sobrecarga baja; úselo para eliminar rutas críticas (hot paths) y reducir costos.

• Modos de fallo y contrapartidas:

  • El exceso de cardinalidad en las métricas aumenta el costo y ralentiza las consultas; agregue antes de emitir.
  • Un muestreo de trazas bajo oculta problemas de latencia de cola (tail latency); muestree con una tasa más alta para las rutas lentas.
  • Los SLO desalineados (p. ej., demasiado estrictos) generan fatiga por alertas; itere con datos de tráfico real.
  • Las verificaciones de tiempo de actividad pueden tener éxito mientras las dependencias internas fallan; utilice SLO que consideren las dependencias.

Operaciones de Plataforma, Runbooks y Gestión de Incidentes

El rigor operativo reduce el tiempo medio de detección, mitigación y aprendizaje.

• Runbooks y escalamiento: Cada alerta debe enlazar a un runbook determinista con precondiciones, pasos de diagnóstico, rollback y plantillas de comunicación. Defina rotaciones de guardia y políticas de escalamiento claras. Almacene los runbooks en un control de versiones y pruébelos.

• Gestión de incidentes y postmortems: Utilice severidades estandarizadas, roles (comandante del incidente, comunicaciones, operaciones, SME) y canales. Prefiera ChatOps y páginas de estado para la difusión. Redacte postmortems sin culpa que capturen la cronología, los factores contribuyentes, las brechas de detección, el impacto en el cliente y acciones de seguimiento concretas vinculadas a responsables y fechas.

• Gestión de cuotas y señales de capacidad: Supervise el uso del servicio (Service Usage) y las métricas de cuota en tiempo de ejecución (serviceruntime) con alertas sobre el ratio de uso. Solicite aumentos de cuota de forma proactiva y alinee los límites de autoescalado con las cuotas. Utilice señales de capacidad como CPU, memoria, descriptores de archivos, pools de conexiones y profundidad de la cola. Para GKE, ajuste HPA/VPA y el cluster autoscaler; para GCE MIGs, establezca períodos de enfriamiento (cool-downs) y autoescalado predictivo cuando sea apropiado.

• Salud del servicio y resolución de problemas: Combine el seguimiento en vivo (live tail) de Logs Explorer, las métricas basadas en logs, los dashboards y Trace para reducir el MTTD. Habilite VPC Flow Logs y Firewall Rules Logging para el triaje de red; use la consola serie de la VM para fallos de arranque. Mantenga la captura de paquetes y el trazado del kernel como procedimientos de emergencia (break-glass) en los runbooks.

• Modos de fallo:

  • El agotamiento de cuota se manifiesta como interrupciones; alerte sobre el 80 por ciento de uso y limite la tasa (rate-limit) en los servicios de origen (upstream).
  • El autoescalado sin precalentamiento causa arranques en frío; utilice réplicas mínimas para las rutas críticas.
  • La falta de comprobaciones sintéticas enmascara fallos visibles para el cliente; implemente transacciones canary.

Automatización, inventario de recursos, políticas y deriva

Automatiza tareas repetibles con el principio de privilegio mínimo e idempotencia.

• Herramientas: Usa Cloud Shell para administración segura y efímera con un $HOME persistente; coloca binarios auxiliares en ~/bin para la persistencia del PATH. Automatiza con gcloud, las API REST y las bibliotecas cliente. Usa cuentas de servicio e identidad de carga de trabajo (workload identity) para eliminar claves de larga duración.

• Programadores y orquestadores: Usa Cloud Scheduler para activar trabajos HTTP y de Pub/Sub según programaciones cron. Usa Workflows para orquestar la automatización de múltiples servicios con reintentos, retirada exponencial (backoff), compensación y tiempos de espera. Asegura la idempotencia y añade identificadores de correlación a los registros.

• Ejemplos de automatización rutinaria:

  • Exportación diaria de activos a GCS y BigQuery para informes de inventario y deriva.
  • Cálculo automatizado de la tasa de consumo del SLO (burn-rate) publicándolo en un dashboard.
  • Evaluación periódica de políticas frente a las políticas de la organización y anomalías de IAM.

• Inventario de recursos y evaluación de políticas: Cloud Asset Inventory proporciona feeds de cambios en tiempo real y de un momento específico (point-in-time) de recursos, vinculaciones de IAM y políticas de la organización. Exporta a BigQuery para análisis histórico y detección de deriva; suscríbete a Pub/Sub para la clasificación casi en tiempo real de violaciones de políticas. Usa Policy Analyzer y Recommender para detectar permisos de IAM demasiado amplios y no utilizados. Aplica restricciones con Organization Policy y valida las configuraciones antes del despliegue con política como código (policy-as-code).

• Deriva de configuración: Prevén la deriva con IaC declarativo y validación continua. Al detectarla, reconcilia automáticamente o pon los recursos en cuarentena. Etiqueta los recursos con su procedencia (p. ej., deployment_id) para distinguir los gestionados de los ad hoc.

• Arquitectura de observabilidad para seguridad, fiabilidad y costo:

  • Seguridad: Enruta los registros de auditoría a buckets protegidos con CMEK y de acceso restringido; expórtalos a un proyecto de seguridad dedicado. Integra SIEM a través de Pub/Sub.
  • Fiabilidad: Basa los dashboards y las alertas en SLIs y trazas; ensaya la automatización de incidentes con Workflows.
  • Costo: Controla la cardinalidad de las métricas, ajusta la retención de registros por bucket, particiona las exportaciones de BigQuery y usa Profiler para optimizar las rutas críticas (hot paths).

Ejemplo: programar una exportación diaria de activos y ejecutar un workflow.

• gcloud asset export –content-type=resource –output-path=gs://ORG-SEC-BUCKET/daily/resources-$(date +%F).json
• gcloud scheduler jobs create http run-asset-scan –schedule=“0 3 * * *” –uri=“WORKFLOW_EXECUTIONS_API_ENDPOINT” –http-method=POST –oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com

Escenario de problema práctico

Contoso Commerce está lanzando una plataforma de pago (checkout) multirregional basada en GKE. Requisitos: administración auditable, alertas basadas en SLO con mínimo ruido, trazado de solicitudes de extremo a extremo, inventario de cumplimiento normativo nocturno y automatizado, y fuertes controles de costos.

Enfoque:

1. Establecer las bases de registro y auditoría

• Crear buckets de registros regionales con CMEK para logs de aplicación, seguridad y análisis; establecer 30 días para los de aplicación, más de 400 días para los de seguridad según se requiera. Enrutar los registros de Admin Activity, System Event y Policy Denied al bucket de seguridad; habilitar los registros de Data Access solo para los servicios de pago.
• Justificación: La segregación por sensibilidad reduce el radio de impacto y el costo; CMEK satisface los requisitos de cumplimiento; limitar el alcance de Data Access evita picos de volumen.

2. Implementar el registro y la recolección estructurada de logs de aplicación

• Desplegar el Ops Agent en los nodos de GKE y colectores en modo sidecar/daemonset para enviar los logs de la aplicación como JSON estructurado con identificadores de correlación (trace_id, span_id) y etiquetas de usuario/sesión saneadas para no incluir PII.
• Justificación: Los registros estructurados permiten consultas precisas, métricas basadas en logs y uniones con trazas; los ID de correlación facilitan el diagnóstico distribuido.

3. Desplegar trazado distribuido, agregación de errores y profiling

• Instrumentar los microservicios con los SDK de OpenTelemetry que exportan a Cloud Trace; establecer un muestreo más alto para las rutas de checkout y pago. Habilitar Error Reporting para todos los entornos de ejecución y Profiler para los servicios críticos en CPU/memoria.
• Justificación: Las trazas localizan la latencia por salto de servicio; Error Reporting agrupa los stack traces para acelerar la clasificación; Profiler reduce el costo de cómputo y la latencia de cola.

4. Definir SLI/SLO y configurar alertas y dashboards

• Definir SLI: latencia p90 y p99 del checkout, disponibilidad de la API de checkout y tasa de éxito de los pagos. Establecer SLO (p. ej., 99.9 % de disponibilidad, latencia p99 por debajo de 800 ms). Configurar alertas de tasa de consumo del presupuesto de error (burn-rate) (2 % en 1 hora y 1 % en 6 horas) con enlaces a runbooks y al canal de PagerDuty; construir dashboards que muestren las señales doradas (golden signals) y las tendencias del presupuesto de error (error budget).
• Justificación: Las alertas de presupuesto de error se vinculan al impacto en el cliente y reducen el ruido; los dashboards proporcionan conciencia situacional operativa.

5. Añadir verificaciones de estado (health checks) externas e internas

• Configurar verificaciones de tiempo de actividad (uptime checks) multirregionales para los endpoints de checkout con validación de contenido; añadir verificaciones de transacciones sintéticas para el flujo del carrito al pago. Integrar GCLB y los sondeos de preparación (readiness probes) de GKE.
• Justificación: Las verificaciones de tiempo de actividad validan la disponibilidad de cara al cliente; los flujos sintéticos detectan roturas de dependencias.

6. Automatizar el inventario, la monitorización de políticas y la detección de deriva

• Crear un proyecto de Seguridad para recibir las exportaciones de Cloud Asset Inventory a GCS y BigQuery; habilitar feeds de Pub/Sub en tiempo real para cambios en IAM y políticas de la organización. Ejecutar Workflows nocturnos para comparar los manifiestos del estado deseado con los activos actuales; abrir tickets o reconciliar automáticamente la deriva de bajo riesgo.
• Justificación: El inventario centralizado apoya las auditorías; la evaluación continua de políticas previene el aumento gradual de privilegios; la automatización frena la deriva.

7. Gobernar cuotas y capacidad

• Monitorizar las cuotas de cómputo, balanceadores de carga y API con alertas al 70 y 85 por ciento de uso. Solicitar por adelantado cuotas más altas para la carga objetivo; alinear los límites del autoscaler de clúster de GKE y del HPA con las cuotas. Habilitar el autoescalado predictivo para servicios basados en MIG donde el arranque es lento.
• Justificación: Los límites de cuota pueden parecer interrupciones del servicio; los ajustes proactivos y el autoescalado alineado previenen la limitación de velocidad (throttling) durante los picos de carga.

8. Optimizar el costo en la observabilidad

• Limitar la retención de registros por bucket, excluir los registros de depuración detallados en producción mediante filtros de Log Router y exportar solo los campos necesarios a BigQuery con expiración de partición. Restringir la cardinalidad de las etiquetas de métricas; usar los hallazgos de Profiler para reducir el tamaño de los servicios más activos.
• Justificación: La observabilidad debe ser rentable; la retención y exportación selectivas evitan el gasto descontrolado.

9. Preparar runbooks y práctica de incidentes

• Redactar runbooks versionados para cada política de alerta, incluyendo consultas de diagnóstico, filtros de trazas, comandos de reversión y comunicaciones. Realizar game days para validar la escalada y la automatización.
• Justificación: Las respuestas deterministas y practicadas reducen el MTTR y mejoran la fiabilidad.

10. Validar e iterar

• Revisar continuamente el ruido de las alertas, ajustar los umbrales y refinar los SLO basándose en el tráfico real. Realizar un seguimiento de los elementos de acción post-mortem hasta su finalización con responsables y fechas límite.
• Justificación: La observabilidad y las operaciones mejoran a través de la retroalimentación medida, reduciendo el trabajo repetitivo y manual (toil) y aumentando la calidad del servicio con el tiempo.

← Migración · Todos los dominios · DevOps →

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

Explorar Google →