11.2-GCP-ACE

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.