SC-100 Design security solutions for infrastructure Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Azure Activity Log

  Why it's wrong here

  Azure Activity Log records subscription-level control plane operations such as resource creation, deletion, and configuration changes, not security authentication events. Failed logon attempts to hybrid workloads occur at the operating system or domain controller level and do not generate entries in the Activity Log. Since it lacks Event 4625 or any logon event, it cannot be used to detect brute-force attacks or credential stuffing.

• ✓

  Windows Security Events via Azure Monitor Agent

  Why this is correct

  The Windows Security event log via the Azure Monitor Agent (AMA) is the standard and authoritative source for logon audit events, specifically Event ID 4625, which logs every failed account logon attempt. For hybrid machines, configuring a data collection rule (DCR) to forward Security events to Microsoft Sentinel enables detection of password-spraying and brute-force attempts. AMA is the current agent replacing the Log Analytics agent and preserves the necessary event details, such as source IP and target account, for high-fidelity analytics.

• ✗

  DNS Events

  Why it's wrong here

  DNS events capture domain name resolution queries and responses, which are valuable for detecting command-and-control (C2) traffic or domain generation algorithms, but they are unrelated to user authentication failures. A failed logon attempt on a hybrid server does not generate a DNS query or DNS log entry; the failure occurs in the authentication protocol (like Kerberos or NTLM) and is recorded in the security log. Thus, using DNS events as a data source would miss all logon failures and cannot address a brute-force detection scenario.

• ✗

  Sysmon Events

  Why it's wrong here

  Sysmon, unless explicitly configured with a custom configuration to audit logon events, primarily logs process creation (Event ID 1), network connections (Event ID 3), and file/image loads. While Sysmon can log successful logons (Event ID 4624) with certain configurations, failed logons (Event ID 4625) are not among its default or typical event types. Relying solely on Sysmon events would therefore miss failed logon attempts, whereas the Windows Security log inherently captures 4625 events by default when auditing is enabled.

Go deeper

Related to this question