11-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.

Necesitas responder “quién cambió una regla de firewall y cuándo”. ¿Qué logs debes consultar?. Cloud Audit Logs de Admin Activity. Solo logs de acceso HTTP. Métricas de CPU. Cloud Trace.

Los auditores quieren conocer lecturas de datos sensibles, pero esas entradas no aparecen por defecto para el servicio. ¿Qué debes revisar?. El TTL de DNS. La habilitación y configuración de Data Access audit logs. El tamaño del disco de arranque. La clase de Cloud Storage del código.

¿Qué dos tipos de auditoría se almacenan siempre en el bucket _Required? Selecciona dos respuestas. Admin Activity. System Event. Todos los Data Access de cualquier servicio. Todos los logs de aplicación.

Un usuario puede ver logs generales, pero no entradas privadas de Data Access. ¿Qué explica mejor el comportamiento?. Cloud Logging no admite IAM. Todos los logs son públicos. Los logs privados requieren permisos IAM adicionales, como Private Logs Viewer. Debe cambiarse la IP de la VM.

Una aplicación distribuida es lenta y necesitas identificar en qué servicio y span se consume tiempo. ¿Qué herramienta debes usar?. Billing Reports. Cloud DNS. Object Lifecycle Management. Cloud Trace.

La CPU de una aplicación es alta y necesitas saber qué funciones del código consumen más recursos con muestreo continuo. ¿Qué debes usar?. Error Reporting. Cloud Profiler. Cloud Armor. Cloud VPN.

Quieres agrupar excepciones similares procedentes de aplicaciones y recibir una vista de tendencias. ¿Qué servicio debes usar?. Cloud Router. Cloud Billing. Error Reporting. Cloud Interconnect.

Un SLO exige que el 99,9 % de solicitudes correctas tenga latencia aceptable. ¿Qué debes definir para medirlo?. Una etiqueta de coste únicamente. Una cuenta de servicio Owner. Un snapshot diario. Indicadores de nivel de servicio que midan éxito y latencia, y el objetivo asociado.

El equipo quiere alertar antes de agotar rápidamente el error budget, no solo cuando ya se incumple el SLO. ¿Qué enfoque debe usar?. Alertas de burn rate en ventanas adecuadas. Una alerta fija de coste. Una regla de firewall. Cambiar la zona de las VM.

Un incidente ya no cumple la condición de una alerta basada en métricas. ¿Qué hace normalmente Cloud Monitoring?. Elimina todos los datos históricos. Cierra el incidente automáticamente y puede notificar la recuperación. Apaga el proyecto. Cambia la política IAM.

Se realizará un mantenimiento conocido y no quieres notificaciones durante dos horas, pero sí conservar la política. ¿Qué debes crear?. Una exclusión permanente de logs. Un nuevo proyecto. Un snooze temporal para las políticas afectadas. Una clave de servicio.

Quieres reducir costes de Logging descartando logs de depuración de gran volumen que no son necesarios. ¿Qué debes configurar con cautela?. Un health check. Una métrica de CPU. Una URL firmada. Un filtro de exclusión en el sink apropiado.

Los logs deben permanecer en una región concreta por cumplimiento. ¿Qué recurso debes configurar?. Un log bucket definido por el usuario con ubicación y retención apropiadas. Un disco local por VM. Un balanceador global. Una clave SSH.

Una consulta de Logs Explorer devuelve demasiado ruido. ¿Qué práctica mejora la precisión?. Usar solo texto libre sin restricciones. Filtrar por campos indexados como resource.type, logName, severity y etiquetas relevantes. Exportar todos los logs manualmente. Aumentar la cuota de CPU.

Una métrica personalizada deja de llegar. ¿Qué dos aspectos debes revisar? Selecciona dos respuestas. Que el escritor use el tipo de métrica y monitored resource correctos. Que la identidad tenga permisos para escribir series temporales. Que exista un bucket Archive. Que Cloud CDN esté habilitado.

Una alerta de latencia usa el promedio y no detecta que una minoría de usuarios sufre respuestas muy lentas. ¿Qué cambio ayuda más?. Eliminar las etiquetas de la métrica. Usar únicamente el coste diario. Alertar sobre un percentil alto, como p95 o p99, de la distribución de latencia. Desactivar los logs.