AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable VM Insights on all VMs and use the Performance view to detect failed logons.

  Why it's wrong here

  VM Insights Performance view is designed to display host metrics like CPU, memory, disk, and network utilization, not security audit events. Failed logon records are Windows Security log events (Event ID 4625), which are not collected by VM Insights' performance counters. Consequently, this approach would not surface the required data, and even if VM Insights were enabled, it would need a separate data collection rule for security event logs.

• ✗

  Stream events to Azure Event Hubs and use a function to filter and send to Log Analytics.

  Why it's wrong here

  Streaming via Event Hubs with a function introduces an unnecessary intermediary processing layer that adds latency and operational overhead, whereas the scenario requires a direct, scalable ingestion path that Azure Monitor’s Data Collection Rules (DCRs) provide natively for security event collection. This option is tempting because Event Hubs excels at high-throughput, real-time event ingestion for downstream analytics or alerting, and would be correct if the requirement were to route logs to multiple destinations or perform complex transformations before storage.

• ✗

  Install the Log Analytics agent on each VM and configure Windows Event log collection in the workspace.

  Why it's wrong here

  The legacy Log Analytics agent (Microsoft Monitoring Agent) is deprecated and cannot filter security events at the source; workspace settings force it to forward entire event logs unless you later filter in Log Analytics queries. Manually installing this agent on every VM in a fleet of five is operationally heavy and inconsistent, whereas Azure Policy enables automated, uniform deployment. Given its retirement timeline, this approach is not a durable architecture for collecting failed logon events.

• ✓

  Deploy the Azure Monitor agent via Azure Policy and create a data collection rule to collect Event ID 4625.

  Why this is correct

  This is the correct, future-ready approach because Azure Monitor agent (AMA) is designed to collect Windows Security events and supports fine-grained XPath filtering in Data Collection Rules (DCRs) to ingest only Event ID 4625. Using Azure Policy ensures the agent is automatically deployed to every VM with consistent configuration, and the DCR can be applied at scale across subscriptions. This avoids manual installation and reduces data costs by filtering noise before it reaches the workspace, while still providing centralized control over the data collection pipeline.

Go deeper

Related to this question