AZ-500 Manage security operations: 137 practice questions

12 of the 137 Manage security operations questions in the Certsqill AZ-500 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-500? Take the free 5-min readiness check →

1. Scheduled analytics rule with a KQL query that uses: Which analytics rule type should the analyst use?

1. Scheduled analytics rule with a KQL query that uses the 'project', 'summarize', and 'join' operators to correlate failure and success events within the defined time windows ✓

   Scheduled analytics rules run KQL queries on a defined schedule against Sentinel data. Multi-event correlation (failures then success within time windows) requires KQL join/union operations that cross-correlate events — this is the correct rule type for complex multi-step detection logic.
2. Near-real-time (NRT) analytics rule that thresholds the SigninLogs failure count, relying on its one-minute cadence to catch the repeated failures and then join the later successful sign-in event

   NRT rules run every minute on a 1-minute lookback window. A brute force success pattern requires correlating events across a 10-minute window and joining two event types (failures and success). NRT rules have limited KQL complexity support and a short time window, so scheduled rules are more appropriate for this correlation.
3. Fusion analytics rule that correlates signals from multiple Defender products, letting its built-in engine assemble the failure-then-success brute force sequence for the account automatically

   Fusion rules are pre-built multi-stage attack detection rules that correlate signals from Microsoft security products using Microsoft's proprietary correlation engine. They are not user-configurable for the custom threshold or time-window logic that the described brute force pattern requires.
4. Anomaly analytics rule trained on historical sign-in baselines that learns the account's normal failure rate and raises an alert when a burst of failures deviates from it

   Anomaly analytics rules use built-in ML models to detect deviations from baseline behavior. They are not configurable for specific event count thresholds (10 failures in 5 minutes) or temporal correlation patterns. Scheduled KQL rules are required for deterministic threshold-based logic.

Scheduled analytics rules with KQL correlation queries are the correct type for custom multi-event, time-windowed detection logic like brute force success patterns.

2. Create an automation rule in Sentinel that triggers: Which Sentinel feature enables this?

1. Configure a Scheduled analytics rule whose built-in automated response action directly calls a Key Vault secret update API to reset the user's password within seconds of the High-severity Account incident being created

   Analytics rules detect threats and create incidents — they do not perform remediation actions directly. Automated response is performed by playbooks (Logic Apps) triggered through automation rules. Also, resetting a password is not equivalent to disabling an account.
2. Create an automation rule in Sentinel that triggers on incident creation with condition 'Severity = High', then runs a playbook (Logic App) that calls the Microsoft Graph API to disable the user account in Entra ID ✓

   Automation rules evaluate incident conditions (severity, entity type, tactic) immediately when incidents are created and can trigger playbooks (Logic Apps) automatically. The playbook calls Microsoft Graph API to disable the account. This is a near-real-time automated response without analyst intervention.
3. Create a watchlist of compromised accounts in Sentinel and configure an analytics rule to tag matching users in incidents, then let Sentinel disable each tagged account whenever the incident severity is High

   Watchlists are reference data used to enrich KQL queries (for example, filtering against a list of known IPs). They do not tag users automatically or perform account actions. Automated response requires playbooks triggered by automation rules.
4. Enable the Sentinel SOAR feature and configure an Azure Automation runbook to poll for newly created High-severity incidents every minute and disable the affected Entra ID user accounts that it discovers

   Azure Automation runbooks with polling introduce latency and do not meet the 'within seconds' requirement. Sentinel automation rules with playbooks are event-driven (incident trigger) and execute within seconds of incident creation, so polling is both unnecessary and slower.

Sentinel automation rules trigger playbooks (Logic Apps) immediately on incident creation — the playbook calls Microsoft Graph API to disable the Entra ID user account in near real time.

3. Create a suppression rule in Defender for Cloud scoped: Which configuration achieves this?

1. Disable Microsoft Defender for Cloud on the subscription during each weekly pen test window and re-enable it immediately afterward so the authorized scanner activity never reaches the SOC alert queue

   Disabling Defender for Cloud removes all threat detection coverage during the window — any real attacker activity during that time would be missed entirely. Suppression rules maintain coverage while filtering known false positives from a specific source.
2. Configure an alert severity filter in the SOC team's alert view to hide the Low and Medium severity alerts for the duration of each scheduled penetration test so the queue stays quiet

   Severity filters are display preferences that do not change underlying alert generation, and real attacker alerts of the same severity would also be hidden. Suppression rules are the correct mechanism to filter by source condition rather than by severity.
3. Create a suppression rule in Defender for Cloud scoped to the pen test IP range — alerts matching the rule criteria are automatically dismissed without appearing in the active alert queue ✓

   Defender for Cloud suppression rules filter alerts based on conditions such as source IP, entity, or alert type before they reach the SOC queue. Alerts matching the rule are automatically dismissed (still stored in alert history) rather than shown as active. Rules can be scoped to specific subscriptions, resources, and conditions.
4. Add the pen test IP range to a Defender for Cloud allowed IP list so that its scans are excluded from threat intelligence matching and no alerts are ever raised for that particular source

   Defender for Cloud does not have a global 'allowed IP list' that suppresses all alerts for a source. Suppression rules are the purpose-built feature for filtering alerts by source IP and other conditions while keeping detection active for every other source.

Defender for Cloud suppression rules automatically dismiss alerts matching defined conditions (such as source IP) before they appear in the SOC queue, while maintaining coverage for other sources.

4. In the Entra ID Diagnostic Settings: What additional configuration is required?

1. Enable Microsoft Defender for Identity to collect every identity-related interactive and non-interactive sign-in from the directory and forward the consolidated stream to the same Log Analytics workspace for retention

   Microsoft Defender for Identity (MDI) monitors on-premises AD DS environments for suspicious activity. It does not collect Entra ID cloud sign-in categories, and it does not replace Entra ID Diagnostic Settings for service principal sign-in log collection.
2. Configure the Log Analytics agent on each Azure VM to collect the Entra ID service principal sign-in events that are written to the Windows Security event log and forward those records to the workspace

   Entra ID sign-in logs are cloud-side logs generated by the Entra ID service, not Windows event logs on VMs. They are collected via Entra ID Diagnostic Settings, so a VM-based log agent cannot capture service principal sign-in events.
3. Enable 'All Logs' in the subscription-level Azure Monitor Diagnostic Settings so that every Entra ID interactive and non-interactive sign-in event is captured to the workspace automatically

   Azure Monitor subscription-level diagnostic settings capture Azure Activity Logs (control plane operations), not Entra ID sign-in/audit logs. Entra ID logs have their own Diagnostic Settings configured in the Entra ID portal section, separate from subscription-level diagnostics.
4. In the Entra ID Diagnostic Settings, enable the 'ServicePrincipalSignInLogs' and 'ManagedIdentitySignInLogs' log categories in addition to 'SignInLogs', all routed to the same Log Analytics workspace ✓

   Entra ID has multiple distinct log categories in Diagnostic Settings. 'SignInLogs' covers interactive user sign-ins. Non-interactive service principal sign-ins require 'ServicePrincipalSignInLogs' and 'ManagedIdentitySignInLogs' as separate categories. All must be explicitly enabled and routed to Log Analytics.

Entra ID Diagnostic Settings has separate categories for each sign-in type — 'ServicePrincipalSignInLogs' and 'ManagedIdentitySignInLogs' must be explicitly enabled alongside 'SignInLogs'.

5. The compliance officer is correct: Who is correct and why?

1. The compliance officer is correct — a single Sentinel workspace stores all ingested data in its region (West Europe). US subscription logs forwarded to West Europe would physically leave the US, violating data residency requirements. A multi-workspace architecture or workspace federation is required ✓

   Microsoft Sentinel stores all ingested log data in the Log Analytics workspace's Azure region. Data forwarded from US subscriptions to a West Europe workspace traverses to and resides in the EU region. For true US data residency, a separate US-region workspace is required. Sentinel workspace federation or cross-workspace queries can provide unified SOC visibility without co-locating data.
2. The architect is correct — Microsoft Sentinel automatically geo-distributes ingested data back to each log's source region to satisfy regional data residency, so US subscription logs continue to reside in the US even though the single workspace is provisioned in West Europe for unified global SOC visibility

   Sentinel does not automatically geo-distribute data based on source region. All data ingested to a single workspace is stored in that workspace's region. Achieving per-region residency requires separate workspaces provisioned in each region.
3. Both are wrong — Microsoft Sentinel routes every ingested log record through Azure Cognitive Services to anonymize and tokenize personal identifiers before the data is written to storage, so regional data residency and privacy obligations no longer attach to anything retained in the West Europe workspace

   This is completely false. Sentinel stores actual log data in the Log Analytics workspace without anonymization, and it does not route records through Azure Cognitive Services. Data residency and privacy obligations apply fully to all Sentinel-ingested data.
4. The compliance officer is correct — West Europe is not recognized as an EU-jurisdiction region, so forwarding protected EU subscription data into that workspace would relocate it beyond the permitted residency boundary and breach the company's data protection commitments

   West Europe (Netherlands) IS within the EU jurisdiction and meets EU data residency requirements. The actual problem is the opposite: US data being stored in the EU, not EU data leaving the EU, so this reasoning misidentifies the residency violation.

Sentinel stores all data in the workspace region — forwarding US logs to a West Europe workspace violates US data residency. Multi-workspace architecture with cross-workspace queries solves this.

6. Defender XDR automatically correlates all three alerts: How does Microsoft Defender XDR handle these alerts?

1. Defender XDR creates one incident per alert severity, so the high-severity endpoint alert forms its own incident that cannot be merged with the medium-severity phishing or impossible travel alerts raised for the same user

   Incident grouping in Defender XDR is based on shared entities and attack timeline correlation, not alert severity. Related alerts of different severities from different products are correlated into a single incident.
2. Defender XDR automatically correlates all three alerts into a single incident using its AI engine, grouping them by shared entities (user account, device) and attack timeline — analysts work one incident, not three separate alerts ✓

   Defender XDR's automated attack disruption and incident correlation engine uses shared entities (user, device, IP, mailbox) and timing to group related alerts from all Defender products into a unified incident. This reduces alert fatigue and provides the full attack chain context in one view.
3. Microsoft Sentinel must be connected to Defender XDR before any cross-product incident correlation can occur, so the three alerts remain unlinked until the SIEM connector merges them into one incident

   Defender XDR performs its own cross-product correlation natively within the Microsoft Defender portal. While Sentinel integration adds SIEM capabilities and custom analytics, cross-product incident correlation is a built-in Defender XDR capability that works without Sentinel.
4. Each Defender product creates its own separate incident that the analyst must manually link together in the Microsoft Defender portal, because Defender XDR does not automatically correlate alerts across products from different security workloads

   Defender XDR is specifically designed to auto-correlate alerts from Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, and Defender for Identity into unified incidents. Manual correlation is the legacy approach that Defender XDR replaces.

Defender XDR automatically correlates related alerts from all Defender products into a single incident using shared entities and attack timeline analysis.

7. Microsoft Defender for Cloud → Regulatory compliance: Where in the Azure portal is this information most direc

1. Microsoft Purview Compliance Manager, where MCSB is listed as an assessment template that scores each Azure security control and reports which ones are currently failing

   Microsoft Purview Compliance Manager focuses on regulatory frameworks (GDPR, ISO 27001, SOC 2) for Microsoft 365 and cloud services from a data governance perspective. MCSB security control compliance for Azure infrastructure is covered by Defender for Cloud's regulatory compliance dashboard.
2. The Azure Policy Compliance dashboard under built-in initiatives, where MCSB is surfaced as an Azure Policy initiative that reports pass/fail compliance for each mapped security control

   While Azure Policy is the underlying engine for MCSB compliance checks, the Azure Policy compliance dashboard shows policy assignment compliance, not the security control mapping with MCSB control identifiers. Defender for Cloud's regulatory compliance dashboard provides the MCSB-framed view with security context.
3. Microsoft Defender for Cloud → Regulatory compliance dashboard — MCSB is assigned as the default compliance standard and shows pass/fail status for each control across all subscriptions ✓

   Defender for Cloud's regulatory compliance dashboard displays compliance status against assigned standards including MCSB (which is assigned by default). It shows which controls pass, fail, or are exempt, with drill-down to specific failing resources and remediation guidance.
4. The Azure Security Center Secure Score blade, where the overall Secure Score percentage shown for the tenant is presented as the direct MCSB compliance level aggregated across all of the subscriptions

   Secure Score (in Defender for Cloud) represents the hardening status of resources against security recommendations, not MCSB compliance, which is shown in the regulatory compliance dashboard. Azure Security Center has also been rebranded to Microsoft Defender for Cloud.

Defender for Cloud's regulatory compliance dashboard shows MCSB compliance status by default, with pass/fail breakdown per control and resource-level drill-down.

8. Open the incident's entity page for the User Account: Which Sentinel features provide the fastest enrichment w

1. Assign the incident to a senior analyst and set the status to 'In Progress', since enrichment of a Global Administrator sign-in from an anonymous IP is judged to require expert manual review by an experienced responder rather than automated enrichment tooling

   Assigning to a senior analyst without performing initial triage using available tools is inefficient and does not leverage Sentinel's built-in enrichment capabilities. Entity pages and UEBA are designed precisely for rapid initial triage by any analyst.
2. Run a custom KQL query in Sentinel Logs against SignInLogs to tally the account's recent sign-in failures over the last 24 hours and then manually judge whether this anonymous IP sign-in looks anomalous enough to escalate

   Writing and running a KQL query provides relevant data but takes longer than using the built-in entity page. The entity page automatically surfaces the same information with additional cross-source context, enabling faster triage than manual KQL queries.
3. Pivot out to the Entra ID portal, open the Azure AD sign-in logs, and filter by the affected user to review the recent sign-in activity and the geographic origin associated with the anonymous IP address event

   Pivoting to another portal takes more than 2 minutes and requires additional portal access. Sentinel entity pages provide the same Entra ID sign-in data enriched with cross-source context directly in the incident view, so the pivot is unnecessary.
4. Open the incident's entity page for the User Account entity — the entity timeline shows all recent activities for the account, and the UEBA (User Entity Behavior Analytics) panel shows the account's risk score and behavioral anomalies ✓

   Sentinel Entity pages aggregate all relevant activity for a given entity (user, IP, host) from all connected data sources. The UEBA panel shows anomaly scores and behavioral deviations. This gives the analyst a complete picture of the user's recent history and risk posture in seconds without pivoting to other tools.

Sentinel entity pages with UEBA risk scores and entity timelines provide instant enrichment within the incident view — no pivoting to other tools required for initial triage.

9. Use the Sentinel Hunting queries library to build a KQL: Which Sentinel capability is designed for this invest

1. Use the Sentinel Hunting queries library to build a KQL query against AuditLogs and AzureActivity tables, join on ServicePrincipalId, filter for IPs with no history in the prior 90 days, and save results as Hunting Bookmarks for further investigation ✓

   Sentinel Hunting is designed for proactive, analyst-led investigation. Hunting queries are KQL queries stored in the hunting library. Results of interest can be saved as Bookmarks — annotated evidence nodes that can be added to an investigation graph or promoted to incidents. This workflow matches the described investigative scenario.
2. Enable Sentinel UEBA and wait for the system to automatically flag the service principal as anomalous once it observes the new source IP addresses that deviate from the principal's established behavioral baseline over recent activity

   UEBA detects behavioral anomalies automatically but may not surface this specific pattern with the custom 90-day lookback window the hunter wants. Proactive hunting with a custom KQL query gives the hunter precise control over the detection logic and time window.
3. Use Log Analytics ad-hoc query mode directly against the SecurityEvent table to hunt for the suspicious PowerShell reconnaissance activity that the stolen service principal credential would have generated across the affected hosts during the window

   Log Analytics ad-hoc queries provide KQL access but lack hunting-specific features such as bookmark creation, the hunting query library, and investigation graph integration. SecurityEvent is also Windows event log data, whereas service principal activity is in AuditLogs and AzureActivity.
4. Create a new Scheduled analytics rule containing the KQL query so that it runs every hour and automatically generates a Sentinel incident whenever a service principal signs in from a source IP that was not previously seen

   Scheduled analytics rules are for ongoing automated detection that creates incidents. Threat hunting is a human-led, exploratory process where the hunter iterates on the query, examines results interactively, and saves findings, so the hunting workspace, not analytics rules, is the designed environment.

Sentinel Hunting queries with Bookmarks support proactive, exploratory KQL-based investigation — hunters can save notable findings as bookmarks for escalation or incident creation.

10. The analyst did not submit a JIT access request: What is the most likely cause?

1. The Defender for Cloud JIT feature only permits RDP over an established VPN tunnel, so a request originating from a public internet IP such as 203.0.113.50 is always blocked no matter what duration is approved

   JIT VM access does allow internet source IPs — the analyst specifies their public IP in the JIT request, and Defender for Cloud then temporarily opens the NSG rule for that specific source IP. No VPN tunnel is required for JIT-approved access.
2. The analyst did not submit a JIT access request for their specific source IP — JIT blocks all management port traffic by default until an access request is approved for a specific source IP and duration ✓

   JIT VM access adds an NSG deny rule for management ports (3389, 22, etc.) when not in use. To gain access, the analyst must submit an access request specifying their source IP and desired duration. Until approved, JIT blocks all traffic on the port. The connection timeout indicates no approved JIT request exists for 203.0.113.50.
3. Every JIT access request must be explicitly approved by a Global Administrator in Entra ID before Defender for Cloud will open the temporary NSG allow rule, and that approval had not yet been granted for this session

   JIT access requests can optionally require approval from subscription owners or specific reviewers, but this is not mandatory and does not involve Global Administrator approval in Entra ID. The default configuration lets users with the right Defender for Cloud permissions self-approve their own requests.
4. The NSG associated with the VM subnet contains a higher-priority deny rule for TCP 3389 that overrides the temporary allow rule JIT injects, so the approved request never actually opens the management port

   This could theoretically block traffic, but the most likely cause in the described scenario is that no JIT request was submitted at all. JIT creates its temporary allow rule at a higher priority, so an overriding manual deny would be a configuration error rather than the normal operational flow.

JIT VM access blocks management ports by default. The analyst must submit a JIT access request specifying their source IP — until then, all traffic on port 3389 is denied.

11. Microsoft Sentinel → Threat Management → MITRE ATT&CK: Where in Sentinel is this information available without

1. Review the Azure Activity Log in Log Analytics and filter for the entries that are tagged with MITRE ATT&CK technique IDs, then compare that list against the tactics that your active Sentinel analytics rules are supposed to be covering

   Azure Activity Log captures control plane operations and does not contain MITRE ATT&CK tagging of detection rules. MITRE coverage analysis relies on the Sentinel analytics rule metadata, which is surfaced in the built-in coverage view rather than the Activity Log.
2. Download the MITRE Navigator JSON layer from attack.mitre.org and manually cross-reference each technique against the descriptions of your configured Sentinel analytics rules to find the gaps in coverage

   While this would eventually yield results, it is a manual and error-prone process. Sentinel has a built-in MITRE ATT&CK coverage view that maps configured rules to the framework automatically, eliminating the need for manual cross-referencing against a Navigator layer.
3. Microsoft Sentinel → Threat Management → MITRE ATT&CK — this view shows a heatmap of ATT&CK tactics and techniques with color-coding indicating which have active detection rules, simulated detections, or no coverage ✓

   Sentinel includes a built-in MITRE ATT&CK coverage view that maps all configured analytics rules (scheduled, NRT, Fusion, etc.) against the MITRE framework. Techniques with no rules appear uncovered. This allows the team to visually identify gaps and prioritize new detection rule creation.
4. Microsoft Defender for Cloud → Regulatory compliance → MITRE ATT&CK, where Defender for Cloud maps its security controls to ATT&CK techniques and highlights the tactics that currently have no detection coverage

   Defender for Cloud's regulatory compliance dashboard covers frameworks such as NIST, PCI-DSS, and ISO 27001, not MITRE ATT&CK detection-rule coverage. Mapping analytics rules to the ATT&CK matrix is a Sentinel-specific feature under Threat Management.

Sentinel's built-in MITRE ATT&CK view (Threat Management section) shows a heatmap of detection coverage — uncovered techniques are visually highlighted for gap analysis.

12. Configure a Workflow Automation in Defender for Cloud: Which Defender for Cloud feature implements this?

1. Create an Azure Automation runbook that queries the Defender for Cloud alerts API every five minutes and opens a ServiceNow ticket for each new high-severity alert it finds, including the resource and remediation details

   Polling via Azure Automation introduces up to five minutes of latency and requires ongoing infrastructure to maintain. Workflow Automation is event-driven and near real-time and is purpose-built for this integration, making it both simpler and more reliable.
2. Configure a Defender for Cloud email notification that sends high-severity alerts to the SOC distribution list, and have the SOC team open the matching ServiceNow ticket manually

   Email notifications support human notification but not automated ticket creation, and the requirement is for tickets to be created automatically without manual intervention. Workflow Automation with a Logic App provides that hands-off ServiceNow integration.
3. Enable Microsoft Sentinel and configure its ServiceNow connector to automatically raise tickets for every Defender for Cloud alert that is synchronized into Sentinel incidents through the Defender for Cloud data connector

   While a Sentinel plus ServiceNow architecture is valid, it requires deploying and configuring Sentinel in addition to Defender for Cloud. The question asks for a native Defender for Cloud feature, and Workflow Automation achieves the requirement without introducing Sentinel.
4. Configure a Workflow Automation in Defender for Cloud with trigger 'Security alert' filtered to severity = High, and link it to a Logic App that creates the ServiceNow ticket with alert details ✓

   Defender for Cloud Workflow Automation supports alert-triggered and recommendation-triggered automations. A Logic App with a ServiceNow connector handles ticket creation. Alert properties (name, resource, description with remediation steps) are passed to the Logic App as payload.

Defender for Cloud Workflow Automation triggers a Logic App on High-severity alerts — the Logic App creates ServiceNow tickets with the alert details automatically.

Other AZ-500 domains

• Secure compute, storage, and databases — 132 questions →
• Manage identity and access — 126 questions →
• Secure networking — 105 questions →
• All 500 AZ-500 questions →