11.1-GCP-ACE

Un equipo quiere medir la experiencia real de un servicio. ¿Qué cuatro señales debería priorizar como punto de partida?. Latencia, tráfico, errores y saturación. Número de proyectos, usuarios, carpetas y etiquetas. Coste, región, zona y sistema operativo. DNS, IAM, cuotas y claves.

Quieres visualizar CPU, memoria y solicitudes de varios proyectos desde una consola central sin mover los recursos. ¿Qué debes configurar?. Shared VPC. Un metrics scope multiproyecto en un proyecto de alcance. Una cuenta de servicio por métrica. Una zona DNS compartida.

Una VM ejecuta NGINX y una aplicación personalizada. Necesitas sus métricas y logs además de las métricas básicas del hipervisor. ¿Qué debes instalar?. Cloud SQL Auth Proxy. Terraform. Ops Agent con receptores adecuados. Cloud NAT.

Quieres una vista operativa que combine latencia, tasa de errores y utilización de backends. ¿Qué debes crear?. Una política IAM. Una imagen de máquina. Una ruta estática. Un dashboard de Cloud Monitoring con gráficos de esas métricas.

Debes recibir una notificación si la CPU media supera el 80 % durante cinco minutos. ¿Qué debes configurar?. Una política de alertas basada en métrica con umbral, duración y canal de notificación. Un sink de logs a Cloud Storage. Una etiqueta de recurso. Una instantánea de disco.

Una alerta se activa por picos de segundos que no afectan a usuarios. ¿Qué ajuste reduce el ruido sin ocultar fallos sostenidos?. Eliminar todas las alertas. Aumentar la duración de retest o ventana exigida antes de abrir el incidente. Conceder Owner al equipo. Cambiar la región de los recursos.

El equipo necesita comprobar de forma activa que una URL HTTPS responde desde ubicaciones externas. ¿Qué debe crear?. Una métrica de facturación. Un log sink. Un uptime check. Una política de retención.

Una política de alertas debe notificar por correo y PagerDuty e incluir el enlace al runbook. ¿Dónde se configura?. En una regla de firewall. En Cloud DNS. En la imagen de la VM. En los canales de notificación y la documentación de la política.

Una métrica tiene valores separados por zona y quieres una sola línea con el total. ¿Qué debes aplicar en el gráfico?. Alineación temporal y reducción entre series con la agregación apropiada. Una ACL de bucket. Una clave de cuenta de servicio. Una ruta BGP.

Quieres alertar cuando aparezca una entrada exacta de seguridad, aunque ocurra una sola vez. ¿Qué opción es la más directa?. Un dashboard sin alertas. Una política de alertas basada en logs con el filtro correspondiente. Una cuota de CPU. Cloud CDN.

Necesitas contar errores de una aplicación y representar su tasa a lo largo del tiempo. ¿Qué debes crear?. Una IP estática. Un bucket multirregional. Una métrica basada en logs y un gráfico o alerta sobre ella. Una organización nueva.

Los logs de todos los proyectos de una carpeta deben centralizarse para análisis de seguridad. ¿Qué debes configurar?. Un sink por VM creado manualmente. Un uptime check por proyecto. Una única cuenta Owner. Un aggregated sink en la carpeta con destino central y permisos del writer identity.

Los analistas necesitan consultas SQL sobre logs operativos y conservarlos en un almacén analítico. ¿Qué destino clásico de sink debes elegir?. BigQuery. Cloud DNS. Secret Manager. Artifact Registry.

Un SOC externo consume eventos en tiempo real desde su propia plataforma. ¿A qué destino debes enrutar los logs?. Un disco persistente. Pub/Sub, desde donde el consumidor los procesa o exporta. Una imagen de VM. Cloud CDN.

Debes archivar logs durante años al menor coste y las consultas serán excepcionales. ¿Qué destino resulta apropiado?. Memorystore. Local SSD. Cloud Storage con clase y retención adecuadas. Cloud Run.

Un sink existe, pero no aparecen datos en el destino. ¿Qué debes comprobar primero?. El color del dashboard. El presupuesto mensual. El tipo de máquina del usuario. El filtro del sink y que su writer identity tenga permisos en el destino.