Practice Test #5

Incorrect. Azure Monitor action groups are used to define notification targets for Azure Monitor alerts, such as metric alerts, log alerts, and activity log alerts. The question is specifically about Azure Security Center custom alert notifications, which are configured through Security Center's own policy-based email notification settings. Choosing an action group confuses Azure Monitor alerting with Defender for Cloud alert notification configuration.

Incorrect. The Security Reader role in Azure AD or Azure RBAC determines who can view security-related information, such as alerts and recommendations. It does not control who receives email notifications when a Security Center alert is triggered. Email delivery settings are configured separately in Security Center policy settings.

Incorrect. Modifying the alert rule affects the rule definition itself, such as what condition generates the alert. It does not determine the list of users who receive email notifications for Security Center alerts. Recipient configuration is handled through the subscription's Security policy notification settings, not directly inside the alert rule.

System routes are the default routes Azure automatically provides (VNet local, internet, virtual network gateway, etc.). They determine baseline connectivity but are not typically configurable to force traffic through a specific VM as a next hop. You can view effective routes, but you generally cannot edit system routes to steer traffic through VM1. For traffic inspection scenarios, you override system routes using UDRs.

A network security group (NSG) is a stateful packet filter used to allow or deny inbound/outbound traffic based on source/destination, ports, and protocol. NSGs do not perform routing and cannot force traffic to traverse a particular VM. While NSGs are important for securing VM1 and subnets, they won’t ensure that all traffic is routed through VM1.

Configuring authentication methods for contoso.com is not the first step to ensure User2 can implement PIM. This is a tenant-wide authentication configuration task and does not grant User2 the permissions required to administer PIM. Even if authentication methods are configured, User2 still cannot implement PIM without an appropriate admin role. Therefore, this option addresses authentication readiness rather than administrative authorization.

Configuring the identity secure score for contoso.com does not enable or authorize PIM implementation. Secure Score is an assessment and recommendation tool that helps measure identity security posture, but it does not provide permissions or activate PIM capabilities. User2 would still lack the necessary administrative rights to implement PIM. This makes Secure Score unrelated to the immediate prerequisite in the question.

Enabling multi-factor authentication for User2 is a security best practice and may be required later for activating privileged roles through PIM. However, MFA alone does not give User2 the administrative permissions needed to implement or manage PIM in the tenant. The question asks what should be done first to ensure User2 can implement PIM, and that requires assigning an appropriate admin role before considering activation controls like MFA. Therefore, MFA is important but not the initial prerequisite here.

Incorrect. App Service (WebApp1) does not support enabling Azure WAF by installing an extension. WAF in Azure is enforced by a reverse proxy service (Azure Front Door or Application Gateway WAF) that inspects HTTP/S requests. Extensions may add app functionality or agents, but they do not provide platform WAF request inspection and rule enforcement.

Incorrect. Azure Firewall is a network firewall primarily for L3/L4 filtering and some application-level controls (e.g., FQDN filtering), but it is not a web application firewall that applies OWASP rules, request body inspection, and typical WAF protections. It also doesn’t directly “attach” a WAF policy like WAF1 to protect a web app’s HTTP traffic.

Incorrect. Activating the Security administrator role in Azure AD PIM may grant permissions to manage security settings, but it is not the required first operational step to connect via RDP when JIT is enabled. Even with the right role, you still must request JIT access to open port 3389 temporarily. PIM is only relevant if you currently lack sufficient RBAC permissions.

Incorrect. Activating the Owner role via PIM could provide broad permissions, but it is not inherently required to initiate an RDP session. The key blocker with JIT is that RDP is closed until you request access. Also, PIM role activation depends on how roles are assigned; the question does not state you need elevation, only that JIT is enabled.

Incorrect. The Network Watcher Agent (or related VM extensions) is used for network diagnostics (e.g., packet capture, connection troubleshoot) and is not required for JIT. JIT is implemented through network security rules at the control plane (NSG/Azure Firewall). Installing an agent will not open RDP nor satisfy the JIT access workflow.

Adding an additional public IP address does not solve the JIT prerequisite problem. JIT is intended to reduce exposure of management ports, not create more internet-facing endpoints for the VM. Even with another public IP, Defender for Cloud would still need an NSG or equivalent supported control to enforce temporary access rules. This option increases attack surface and does not address why the VM is marked Unsupported.

Replacing a Basic Load Balancer with a Standard Load Balancer is not the required step to enable JIT in this scenario. The essential dependency for JIT is the presence of an NSG on the VM's NIC or subnet so Defender for Cloud can manage inbound access rules. Although Standard Load Balancer is the newer SKU and often recommended for production workloads, the question asks what must be done so JIT can be enabled, and that is to provide the NSG-based enforcement mechanism. Changing the load balancer alone would not guarantee JIT support if no NSG exists.

Assigning Azure Active Directory Premium Plan 1 to Admin1 is unrelated to whether a VM is supported for JIT VM access. JIT is a Microsoft Defender for Cloud feature that depends on VM networking configuration and Defender for Cloud capabilities, not on Azure AD P1 licensing for the requesting user. Identity licensing may affect other security features such as Conditional Access, but it does not change the VM's Unsupported status in the JIT blade. Therefore this action would not enable JIT for VM1.

Azure Security Center (now Microsoft Defender for Cloud) focuses on security posture management, recommendations, and threat protection alerts from Defender plans. While it can surface security alerts, it is not the general-purpose service you use to create custom alerts directly from arbitrary VM event data in a Log Analytics workspace in the same way as Azure Monitor or Sentinel analytics rules.

Azure Analysis Services is a BI/semantic modeling service used to build tabular models for analytics (similar to SSAS). It does not provide monitoring or alerting capabilities for VM events or Log Analytics workspaces. It is unrelated to security event collection and alert creation in Azure Monitor Logs.

Azure Advisor provides best-practice recommendations for cost, reliability, security, operational excellence, and performance. It does not create alerts based on Log Analytics event data. Advisor recommendations can be exported or acted upon, but it is not an alerting engine for VM event logs.