Practice Test #1

Microsoft Teams logs are collected through Microsoft 365 audit data (Unified Audit Log) and related Microsoft 365 service telemetry. In Microsoft Sentinel, the built-in connector for these SaaS signals is the Office 365 (Microsoft 365) data connector. This is the lowest administrative effort option because it’s a native integration: you enable the connector, grant the required permissions, and Sentinel pulls the relevant audit/activity data without you building custom ingestion. Why others are wrong: - A. Custom: would require creating and maintaining a custom ingestion pipeline (Graph API polling, custom tables, DCRs, etc.), which increases effort. - C. Security Events: targets Windows security event logs, not Teams. - D. Syslog: is for syslog-based devices/hosts (commonly Linux/network devices), not Microsoft 365 SaaS audit logs.

For Linux virtual machines, the standard log source is syslog (e.g., auth, authpriv, daemon, kern). In Microsoft Sentinel, Linux log ingestion is typically configured by enabling Syslog collection via the Log Analytics agent or Azure Monitor Agent (AMA) and sending those syslog events into the Log Analytics workspace connected to Sentinel. This is the most straightforward and lowest-effort connector type among the options because it aligns with native Linux logging and Sentinel’s built-in syslog ingestion patterns. Why others are wrong: - A. Custom: unnecessary unless you have a non-syslog format or specialized ingestion needs; it increases operational overhead. - B. Office 365: applies to Microsoft 365 services, not IaaS Linux VMs. - C. Security Events: is primarily for Windows Event Logs (Security log) and not the typical connector choice for Linux.

Correct: B. Modify the access policy settings for the key vault. An “internal threat” alert for Key Vault typically means a principal that already has access is performing suspicious actions (for example, unusual secret retrieval patterns, access from atypical locations, or excessive permissions being used). The most direct remediation is to reduce or correct permissions by modifying existing access policies (or RBAC role assignments in RBAC-enabled vaults) to enforce least privilege—e.g., remove broad Secret/Get/List permissions, scope to only required operations, and ensure only approved identities have access. Why not A: Resource locks protect against management-plane changes (delete/update) but do not prevent data-plane operations like reading secrets/keys/certificates by an authorized identity. Why not C: Creating a new access policy is typically used to grant access, not remediate an internal misuse scenario. Remediation usually involves tightening/removing existing permissions rather than adding new ones.

Correct: B. Modify the Key Vault firewall settings. An “external threat” alert generally indicates the vault may be exposed to access attempts from the public internet or untrusted IP ranges. Key Vault provides a native firewall (“Networking” settings) where you can restrict access to selected networks, allow only specific public IPs, or require private endpoint access. Tightening these settings directly reduces the attack surface and is the most targeted remediation for external/network-based threats against a PaaS endpoint. Why not A: Azure Firewall can help control outbound/inbound traffic for VNets, but it does not replace Key Vault’s own network controls for the public endpoint and is not the most direct fix for a Key Vault exposure alert. Why not C: NSGs apply to subnets/NICs in VNets. They don’t govern access to Key Vault’s public endpoint and are not the primary control for restricting who can reach the vault.

DeployIfNotExists is the correct Azure Policy effect when you need the policy to automatically deploy a required resource/configuration if it is missing. In this case, the goal is to ensure the components needed for automatic threat remediation (for example, a Defender for Cloud automation configuration and/or a Logic App) are present at the target scope. DeployIfNotExists supports remediation tasks and can create resources via an ARM template when non-compliance is detected. Append is used to add fields to a resource request during creation/update (for example, adding tags). It does not deploy separate resources like workflow automation or Logic Apps. EnforceRegoPolicy is associated with policy-as-code scenarios (OPA/Rego) and is not the standard mechanism for deploying Defender for Cloud workflow automation resources. Therefore, DeployIfNotExists is the only option that matches “create an Azure policy” that results in automatic deployment/remediation capability.

To perform remediation in response to Defender for Cloud threat alerts using workflow automation, the best fit is an Azure Logic Apps workflow with the Defender for Cloud alert trigger: “When an Azure Security Center (Defender for Cloud) Alert is created or triggered.” This trigger is designed specifically for alert-driven automation and is the common exam answer for implementing automated response actions (containment, notification, ticketing, enrichment). An Azure Automation runbook with a webhook can be used for automation, but it is not the primary/native workflow automation pattern referenced for Defender for Cloud alert-based workflow automation in this context, and it typically requires additional wiring (calling the webhook from an action group/Logic App). The option “When a response to an Azure Security Center alert is triggered” is not the standard Logic Apps trigger used for Defender for Cloud alert creation events; the canonical trigger is the alert-created/triggered event. Hence, option B is the most accurate.