Microsoft Azure Administrator (AZ-104) — Preguntas de práctica y simulacro de examen

La respuesta correcta es Falso. Implementar una máquina virtual en una sola zona de disponibilidad la fija a esa zona. Si los centros de datos que respaldan esa zona sufren una falla completa, la VM cae con ellos: una VM zonal está protegida ante fallas en *otras* zonas, no ante la falla de la suya. Como indica la documentación oficial: “Muchas regiones de Azure ofrecen zonas de disponibilidad, que son grupos separados de centros de datos dentro de una región. Cada zona de disponibilidad tiene energía, refrigeración y redes independientes”. La protección ante la falla completa de un centro de datos proviene de implementar recursos *en varias* zonas de disponibilidad o de usar servicios con redundancia de zona: cuando una zona cae, las instancias de las zonas restantes siguen funcionando. la opción “Verdadero” (Verdadero) es incorrecta porque describe el beneficio de una implementación en varias zonas, no el de colocar una VM en una sola zona. Para una VM zonal única, la falla completa del centro de datos de su propia zona es justamente el escenario contra el que no está protegida, y por eso Microsoft recomienda distribuir las VM entre zonas de disponibilidad para lograr alta disponibilidad. (Fuente: https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)

Las reglas de alertas de búsqueda de registros son la opción correcta porque evalúan una consulta KQL (Kusto Query Language) contra los datos de un área de trabajo de Log Analytics con una frecuencia definida. Cuando los resultados de la consulta cumplen una condición especificada (por ejemplo, cantidad de errores HTTP 500 > 10), la alerta se dispara. Según la documentación de Microsoft, las alertas de Azure Monitor te permiten 'generar alertas sobre cualquier origen de datos de métricas o de registros de la plataforma de datos de Azure Monitor'. Las alertas de búsqueda de registros funcionan específicamente ejecutando consultas de registros a intervalos regulares contra los datos de Log Analytics o de Application Insights.

Por qué cada opción incorrecta está mal:

• A. Alerta de smart detection: smart detection es una característica de Application Insights que detecta automáticamente anomalías de rendimiento y posibles problemas mediante machine learning. No te permite definir consultas KQL propias con umbrales e intervalos de evaluación específicos: es proactiva y automática, no algo que el usuario configure de esta manera.

• C. Regla de alertas de métricas: las alertas de métricas evalúan datos numéricos de métricas (por ejemplo, porcentaje de CPU, uso de memoria) a intervalos regulares. Si bien pueden trabajar con métricas provenientes de Log Analytics a través de las 'alertas de métricas para registros', el escenario describe explícitamente la evaluación de una consulta KQL contra datos de Log Analytics, que es la característica que define a una regla de alertas de búsqueda de registros y no a una regla de alertas de métricas.

• D. Regla de alertas del registro de actividad: las alertas del registro de actividad se disparan a partir de eventos de administración de recursos de Azure registrados en el registro de actividad, como cuando se desasigna una VM o se crea o elimina un recurso. No evalúan consultas KQL contra telemetría de aplicaciones ni datos de registros personalizados.

(Fuente: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview)