Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel →mediumMultiple Choice

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Your company uses Microsoft Sentinel to monitor security events. You need to detect brute-force attacks against Azure VMs that are not yet onboarded to Sentinel. What should you do?

⚠ Common exam trap

Candidates often confuse the Azure Activity connector (which logs control-plane operations) with VM-level sign-in logs, mistakenly thinking it captures authentication events, when it only records resource management activities like VM start/stop.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use the Windows Security Events connector via Azure Monitor Agent.

The Windows Security Events connector via Azure Monitor Agent can collect security event logs from Azure VMs, including failed logon attempts that indicate brute-force attacks. Since the VMs are not yet onboarded to Sentinel, this connector allows you to ingest their existing Windows Event Logs (specifically Event ID 4625 for failed logons) directly into Sentinel for detection and alerting.

Answer analysis

Option-by-option breakdown

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

✗
Use the Office 365 connector to collect sign-in logs.
Why it's wrong here
The Office 365 connector ingests audit and sign-in logs from Microsoft 365 services via the Office 365 Management Activity API, covering Microsoft Entra ID sign-ins for cloud applications like Exchange Online and Teams. It does not collect Windows Event Log data from individual VMs, so interactive or RDP logon events (for example, Security Event ID 4624) generated by the operating system are completely outside its scope. Therefore it cannot satisfy the requirement for VM sign-in event monitoring in Sentinel.
✓
Use the Windows Security Events connector via Azure Monitor Agent.
Why this is correct
The Windows Security Events connector using the Azure Monitor Agent (AMA) is the correct choice because it collects Windows Event Log entries, including security events such as successful and failed logon attempts (Event IDs 4624, 4625) from Azure VMs. AMA is configured with a data collection rule (DCR) that specifies which event IDs to send to the Log Analytics workspace where Microsoft Sentinel can analyze them. This is exactly the native, supported path for OS-level sign-in monitoring on Windows virtual machines.
✗
Use the Common Event Format connector to forward syslog.
Why it's wrong here
The Common Event Format (CEF) connector is designed for syslog-based security appliances, such as firewalls and intrusion detection systems, that emit structured CEF messages over syslog. Windows virtual machines do not natively generate CEF-formatted logs, and the connector cannot directly read local Windows Security Event log entries without an intermediary like a syslog agent or forwarder (e.g., Syslog-NG or rsyslog) re-formatting the events. Since that is not a native Azure Sentinel connector for collecting OS sign-in events, this option is incorrect.
✗
Use the Azure Activity connector to collect sign-in logs.
Why it's wrong here
The Azure Activity connector ingests the subscription-level activity log, which records control-plane operations such as resource creation, configuration changes, and administrative actions. It does not capture guest OS or application-level events, including user sign-in events on a virtual machine, because those are data-plane events that occur inside the VM. Therefore, while the Activity log is useful for auditing who modified resources, it cannot provide the OS sign-in event data required for VM logon monitoring.

Go deeper

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Why each option matters

Option-by-option breakdown

Related to this question