Examkin

All practice questions

1252 questions

All types1,252Multiple choice644Multiple select429True / False47Matching52Ordering80
Question 861Question →

You are deploying an Azure Application Gateway to publish a secure web application. You need to configure a new listener to accept incoming HTTPS traffic. Which two settings must be defined directly within the listener configuration? (Select two.)

Select all that apply

Show answer & explanation

Answer: The frontend IP address configuration (public or private); The SSL/TLS certificate

Answer

To configure a listener for HTTPS traffic on an Azure Application Gateway, you must define the frontend IP address configuration and the SSL/TLS certificate directly on the listener.
An Application Gateway listener is the logical entity that checks for incoming connection requests. For HTTPS, it must know which frontend IP address to monitor and require an SSL/TLS certificate to secure the session and decrypt the traffic.

Step-by-Step Solution

1
Identify listener requirements for HTTPS protocol.
An HTTPS listener requires a port (typically 443), an associated frontend IP (public or private), and an SSL/TLS certificate to decrypt traffic.
This establishes the entry point and decryption mechanism for the incoming traffic.
2
Determine where the backend pool is associated.
The backend pool is configured separately and linked to the listener via routing rules.
This decouples the routing logic and backend targets from the listener itself.
3
Determine where NSG rules are applied.
NSG rules are associated with the subnet where the Application Gateway is deployed, not within the Application Gateway configuration resource.
Subnet-level security governs all traffic entering or leaving the subnet.

Key Concept

Azure Application Gateway Listener Configuration
Question 862Question →

You configure the Log Analytics agent to collect performance counters from several Azure virtual machines. You need to write a query to identify all records where the processor utilization exceeds 90 percent. Which Kusto Query Language (KQL) query should you run?

Show answer & explanation

Answer: Perf
| where CounterName == "% Processor Time"
| where CounterValue > 90

Answer

The query that starts with the Perf table and uses the where operator with the double equals (==) comparison operator.
The correct query references the Perf table and uses the where operator with the double equals (==) comparison operator to filter performance counter records.

Step-by-Step Solution

1
Determine the correct log table for virtual machine performance metrics.
The target table is Perf.
Azure Log Analytics stores performance counter data in the Perf table.
2
Filter the rows to match the specific counter and value threshold.
Use 'where CounterName == "% Processor Time"' and 'where CounterValue > 90'.
The where operator filters records, and the double equals (==) operator performs equality comparison in KQL.

Key Concept

Querying VM performance logs using basic KQL operators and the Perf table
Estimated Time:45s
Question 863Question →

An administrator is deploying an Azure Application Gateway v2 to load balance traffic for two secure web applications, `app1.contoso.com` and `app2.contoso.com`, which are hosted on virtual machines in a separate peered virtual network named `VNet-Backend`.

You must meet the following requirements:
- Incoming traffic to `https://app1.contoso.com/images/*` must be routed to a backend pool named `ImagePool`.
- All other traffic to `https://app1.contoso.com/*` must be routed to a backend pool named `App1Pool`.
- Incoming traffic to `https://app2.contoso.com/*` must be routed to a backend pool named `App2Pool`.
- HTTPS connections must be decrypted at the Application Gateway (SSL termination).
- The Application Gateway must be able to communicate with the Azure infrastructure and route traffic to the peered backend VMs.

Which configuration should you implement to satisfy these requirements?

Show answer & explanation

Answer: Configure two multi-site HTTPS listeners on port 443 (one for `app1.contoso.com` and one for `app2.contoso.com`), each with its own SSL certificate. Associate a path-based routing rule with the listener for `app1.contoso.com` to map `/images/*` to `ImagePool` and the default path to `App1Pool`. Associate a basic routing rule with the listener for `app2.contoso.com` to route traffic to `App2Pool`. Ensure the gateway subnet Network Security Group (NSG) allows inbound traffic on ports 65200-65535 from the `GatewayManager` service tag, and verify no User-Defined Route (UDR) redirects internet-bound traffic (0.0.0.0/00.0.0.0/0) to a virtual appliance.

Answer

Configure two multi-site HTTPS listeners on port 443, one path-based routing rule for the domain requiring path routing, one basic routing rule for the domain with a single backend pool, and ensure the gateway subnet NSG and UDR are configured to allow Azure infrastructure management communication.
The correct configuration uses multi-site HTTPS listeners on port 443 to distinguish between incoming requests for the distinct domain names. It maps `app1.contoso.com` to a path-based routing rule to handle path-based redirection, and `app2.contoso.com` to a basic routing rule. It also respects the subnet constraints of Application Gateway v2 by allowing inbound `GatewayManager` traffic on ports 65200-65535 and avoiding forced tunneling of outbound traffic via UDRs.

Step-by-Step Solution

1
Determine the listener type.
Two multi-site listeners are required.
Since the gateway must route traffic for two distinct host headers (`app1.contoso.com` and `app2.contoso.com`) over the same port (443), basic listeners cannot be used; multi-site listeners must be configured to process host headers.
2
Configure the routing rules.
One path-based routing rule and one basic routing rule are configured.
Traffic to `app1.contoso.com` requires routing based on the URL path `/images/*` (path-based routing rule), while traffic to `app2.contoso.com` is sent entirely to `App2Pool` regardless of the path (basic routing rule).
3
Configure the gateway subnet NSG rules.
Allow inbound traffic on ports 65200-65535 from the `GatewayManager` service tag.
Application Gateway v2 requires these ports to be open for backend health monitoring and management by the Azure infrastructure. Blocking this traffic prevents the gateway from operating.
4
Configure gateway subnet routing rules.
Do not redirect default route (0.0.0.0/00.0.0.0/0) to a virtual appliance.
Direct internet connectivity is mandatory for the management and control plane of Application Gateway v2. Forcing internet traffic to a virtual appliance (forced tunneling) is not supported and will break gateway management.

Key Concept

Azure Application Gateway Listener Types, Routing Rules, and Subnet Requirements
Question 864Question →

An administrator is configuring a container group in Azure Container Instances (ACI) to execute a scheduled database maintenance script. The script runs for approximately 10 minutes and then terminates. If the script exits with a non-zero code, it must attempt to run again. If it exits with code 0, the container group must release its compute resources. Which setting should the administrator configure to achieve this behavior?

Show answer & explanation

Answer: Restart policy set to OnFailure

Answer

Restart policy set to OnFailure
The correct configuration is setting the restart policy to OnFailure. In Azure Container Instances (ACI), the OnFailure policy ensures that the containers in the container group are restarted only when the application process fails (returns a non-zero exit code). If the process succeeds (returns exit code 0), the containers stop and transition to a Terminated state, ensuring that billing stops and compute resources are released.

Step-by-Step Solution

1
Analyze the execution requirements for the container group.
The script runs to completion (10 minutes), requires a retry upon failure (non-zero exit code), and must release compute resources upon success (exit code 0).
This establishes the behavioral criteria needed to evaluate and select the correct configuration.
2
Evaluate the supported restart policies in Azure Container Instances.
ACI supports three restart policies: Always (restarts container on any exit), Never (never restarts container), and OnFailure (restarts container only on non-zero exit).
This identifies valid configuration options and eliminates invalid settings.
3
Select the policy that matches the required restart behavior.
The OnFailure policy satisfies the requirements by retrying only when failures occur and stopping the container to save costs upon successful completion.
Choosing this policy directly aligns with the defined operational and cost-efficiency needs.

Key Concept

Azure Container Instances (ACI) Restart Policies
Question 865Question →

Your company has an Azure environment with a hub-and-spoke virtual network topology. The hub virtual network (VNet-Hub) contains an Azure Firewall deployed in the AzureFirewallSubnet with a private IP address of 10.0.1.4. A spoke virtual network (VNet-Spoke1) is peered with VNet-Hub and contains a subnet named Subnet-Web (10.1.1.0/24) housing web servers.

You need to meet the following requirements:
1. Route all outbound internet traffic from Subnet-Web through the Azure Firewall.
2. Allow the web servers in Subnet-Web to access the FQDN *.github.com over HTTPS.

Which two configurations should you perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: In a route table associated with Subnet-Web, add a route for destination 0.0.0.0/0 with the next hop type set to Virtual appliance and the next hop address set to 10.0.1.4.; In the Azure Firewall policy, create an application rule with the protocol set to HTTPS, the target FQDN set to *.github.com, and the source set to 10.1.1.0/24.

Answer

In a route table associated with Subnet-Web, add a route for destination 0.0.0.0/0 with the next hop type set to Virtual appliance and the next hop address set to 10.0.1.4; and in the Azure Firewall policy, create an application rule with the protocol set to HTTPS, the target FQDN set to *.github.com, and the source set to 10.1.1.0/24.
To route outbound traffic from a spoke subnet through a hub Azure Firewall, you must configure a user-defined route (UDR) for 0.0.0.0/0 pointing to the firewall's private IP address. The next hop type must be set to Virtual appliance. To allow the web servers to access wildcard domain names such as *.github.com over HTTPS, you must configure an application rule in the firewall policy. This rule specifies the source IP range, the protocol and port (HTTPS:443), and the target FQDN.

Step-by-Step Solution

1
Configure the routing for Subnet-Web by creating a route table.
A route table is created and associated with Subnet-Web.
This allows custom routing rules to override the default system routes for the web servers.
2
Add a user-defined route to the route table directing all internet-bound traffic to the firewall.
A route for 0.0.0.0/0 is created with a next hop type of Virtual appliance and next hop address of 10.0.1.4.
Azure Firewall acts as a virtual appliance. Directing 0.0.0.0/0 traffic to its private IP ensures all outbound internet traffic from the spoke is forwarded to the firewall for inspection.
3
Configure the Azure Firewall policy to permit HTTPS traffic to *.github.com.
An application rule is added with target FQDN *.github.com, protocol HTTPS, and source 10.1.1.0/24.
Azure Firewall blocks all traffic by default. An application rule is required to inspect and allow HTTPS traffic to specific wildcard domains.

Key Concept

Routing spoke traffic through a hub firewall and performing outbound FQDN filtering using application rules.
Question 866Question →

You are designing the subnet configuration for an Azure virtual network named `vnet-prod` that has an address space of 172.16.0.0/22172.16.0.0/22. The virtual network currently contains a single subnet named `snet-web` with an address range of 172.16.0.0/24172.16.0.0/24. You need to add two new subnets to `vnet-prod` to support the following requirements:
1. Deploy an Azure Bastion host to secure management access to virtual machines.
2. Deploy a Virtual Network Gateway to establish a hybrid connection with an on-premises datacenter.
You want to allocate the minimum recommended address space for both subnets while ensuring they are fully functional and compliant with Microsoft best practices. Which of the following configurations should you implement?

Show answer & explanation

Answer: Create AzureBastionSubnet with the range 172.16.1.0/26172.16.1.0/26 and GatewaySubnet with the range 172.16.1.64/27172.16.1.64/27.

Answer

Create AzureBastionSubnet with the range 172.16.1.0/26172.16.1.0/26 and GatewaySubnet with the range 172.16.1.64/27172.16.1.64/27.
The correct configuration uses the range 172.16.1.0/26172.16.1.0/26 for a subnet named exactly AzureBastionSubnet and the range 172.16.1.64/27172.16.1.64/27 for a subnet named exactly GatewaySubnet. This fulfills the naming requirements, respects the minimum subnet size requirement of /26 for Azure Bastion, and adheres to Microsoft's recommended /27 or larger subnet size for the GatewaySubnet.

Step-by-Step Solution

1
Determine the available remaining IP address space in the virtual network.
The virtual network has an address space of 172.16.0.0/22172.16.0.0/22 (which spans 172.16.0.0172.16.0.0 to 172.16.3.255172.16.3.255). The existing subnet snet-web uses 172.16.0.0/24172.16.0.0/24 (172.16.0.0172.16.0.0 to 172.16.0.255172.16.0.255). The remaining unallocated space is 172.16.1.0172.16.1.0 to 172.16.3.255172.16.3.255.
This identifies where the new subnets can be positioned without overlapping with existing resources.
2
Identify the minimum requirements for the Azure Bastion subnet.
The subnet must be named exactly AzureBastionSubnet and have a prefix of /26 or larger. A /26 subnet provides 64 total IP addresses, leaving 59 usable addresses after Azure reserves the first 4 and the last 1 address.
Azure Bastion will fail to deploy if the subnet name is incorrect or if the prefix size is smaller than /26 (such as /27).
3
Identify the recommended requirements for the Virtual Network Gateway subnet.
The subnet must be named exactly GatewaySubnet. While a /29 subnet is the absolute minimum size supported, Microsoft strongly recommends a prefix of /27 or larger to support future growth and routing capabilities.
Using the recommended size prevents IP exhaustion when adding new gateway types or configuring coexistence scenarios.
4
Align the ranges sequentially inside the unallocated space.
Assign 172.16.1.0/26172.16.1.0/26 (occupies 172.16.1.0172.16.1.0 to 172.16.1.63172.16.1.63) to AzureBastionSubnet. The next contiguous block starting at 172.16.1.64172.16.1.64 with a /27 prefix (occupies 172.16.1.64172.16.1.64 to 172.16.1.95172.16.1.95) is assigned to GatewaySubnet.
This allocates the minimum recommended ranges sequentially, leaving 172.16.1.96172.16.1.96 to 172.16.3.255172.16.3.255 free for future workloads.

Key Concept

Azure virtual network planning requires meeting strict name and prefix constraints for specialized service subnets, specifically a minimum of /26 for AzureBastionSubnet and a recommended minimum of /27 for GatewaySubnet.
Question 867Question →

An organization manages its Azure resources using the following hierarchy:
- Management Group: `MG-Finance`
- Subscription: `Sub-Accounting`
- Resource Group: `RG-Audit`
- Storage Account: `saaudittemplates` (configured to use Microsoft Entra ID authorization for data plane access)

A user named Auditor1 is assigned the Reader role at the `Sub-Accounting` subscription level. Auditor1 is also assigned the Contributor role at the `RG-Audit` resource group level.

Auditor1 attempts to upload a spreadsheet to a blob container named `templates` in `saaudittemplates` using their Microsoft Entra ID credentials but receives an authorization error.

Which action should you perform to allow Auditor1 to upload the file to the container while adhering to the principle of least privilege?

Show answer & explanation

Answer: Assign the Storage Blob Data Contributor role to Auditor1 at the scope of the `saaudittemplates` storage account.

Answer

Assign the Storage Blob Data Contributor role to Auditor1 at the scope of the `saaudittemplates` storage account.
To perform data operations such as uploading files to a blob container using Microsoft Entra ID authentication, the user requires data-plane permissions. Standard roles like Contributor only grant control-plane permissions. The built-in Storage Blob Data Contributor role provides the required read, write, and delete permissions for blob data. Assigning this role at the scope of the specific storage account ensures the user can upload the spreadsheet while adhering to the principle of least privilege.

Step-by-Step Solution

1
Determine the type of operation being performed.
Uploading a file to a blob container is a data-plane operation.
Azure RBAC separates control-plane (management) operations from data-plane (data access) operations for storage services.
2
Assess the user's existing permissions.
The Reader role at the subscription level and Contributor role at the resource group level only grant control-plane permissions.
Standard control-plane roles like Owner, Contributor, and Reader do not grant implicit data-plane access when Microsoft Entra ID authorization is enforced.
3
Select the correct role and scope matching the principle of least privilege.
Identify Storage Blob Data Contributor as the correct role and apply it at the storage account level.
The Storage Blob Data Contributor role grants the write permissions necessary to upload blobs, and restricting it to the storage account scope avoids over-provisioning access.

Key Concept

Separation of control plane and data plane RBAC roles for Azure Storage resources
Question 868Question →

Your organization manages an Azure Storage account named stdeployments that contains a blob container named software-builds. A developer named Dev1 is currently assigned the Reader role for the resource group that contains stdeployments. Dev1 needs to download software builds from the software-builds container using Microsoft Entra ID credentials. When Dev1 attempts to access the container in the Azure portal, they receive an authorization error. You need to resolve the authorization error. The solution must follow the principle of least privilege. Which action should you perform?

Show answer & explanation

Answer: Assign the built-in Storage Blob Data Reader role to Dev1 at the scope of the software-builds container

Answer

Assign the built-in Storage Blob Data Reader role to Dev1 at the scope of the software-builds container
The correct answer is to assign the built-in Storage Blob Data Reader role to Dev1 at the container scope. This provides Dev1 with the necessary data-plane permissions to read and download blobs in the container using Microsoft Entra ID. Scoping the assignment to the specific container ensures compliance with the principle of least privilege. The user's existing Reader role at the resource group level provides the necessary control-plane access to navigate to the storage account in the Azure portal, but it must be supplemented with a data-plane role for actual content access.

Step-by-Step Solution

1
Analyze the error and the existing permissions.
Dev1 has the Reader role at the resource group level, which allows listing resources but does not grant permissions to read blob data.
Azure Storage separates control-plane operations (e.g., Reader, Contributor) from data-plane operations (e.g., Storage Blob Data Reader).
2
Select the appropriate data-plane role to read blob content.
The Storage Blob Data Reader role is the least-privileged built-in role required to read and download blobs.
Other data-plane roles like Storage Blob Data Contributor or Storage Blob Data Owner grant write or delete permissions, which are not required.
3
Determine the optimal scope for the role assignment.
Assign the role at the container scope ('software-builds') rather than the storage account or resource group scope.
This complies with the principle of least privilege by restricting access to only the specific container required.

Key Concept

Azure Storage data-plane authorization requires data-plane RBAC roles (such as Storage Blob Data Reader) which are distinct from control-plane roles (such as Reader or Contributor).
Question 869Question →

You have three virtual machines named VM1, VM2, and VM3 in a virtual network named VNet1. VM1 and VM2 are deployed in Availability Set AS1, while VM3 is deployed as a standalone virtual machine. You have an existing Basic SKU public IP address named PublicIP1.

You need to configure a public load balancer to distribute inbound internet traffic to VM1, VM2, and VM3.

Which action should you perform?

Show answer & explanation

Answer: Deploy a Standard SKU load balancer, upgrade PublicIP1 to the Standard SKU, and add VM1, VM2, and VM3 to the backend pool.

Answer

Deploy a Standard SKU load balancer, upgrade PublicIP1 to the Standard SKU, and add VM1, VM2, and VM3 to the backend pool.
The correct action is to deploy a Standard SKU load balancer, upgrade the public IP address to the Standard SKU, and add all three virtual machines to the backend pool. A Standard SKU load balancer is necessary because it supports a backend pool consisting of any virtual machines in a single virtual network, including a mix of standalone VMs and availability sets. Additionally, Standard SKU load balancers require Standard SKU public IP addresses, meaning the existing Basic SKU public IP must be upgraded.

Step-by-Step Solution

1
Analyze backend pool requirements.
The target backend pool contains a mix of virtual machines in an availability set (VM1 and VM2) and a standalone virtual machine (VM3).
This determines the required load balancer SKU, as only the Standard SKU supports mixing standalone VMs and availability sets in a single backend pool.
2
Determine the required Load Balancer SKU.
Standard SKU load balancer is required.
Basic SKU load balancers can only target VMs in a single availability set or scale set.
3
Determine public IP address SKU compatibility.
The frontend public IP address must be upgraded from Basic SKU to Standard SKU.
Standard SKU load balancers do not support Basic SKU public IP addresses; frontend IP SKUs must match the load balancer SKU.

Key Concept

Azure Load Balancer SKU features and IP address compatibility rules.
Question 870Question →

You manage an Azure subscription that contains a virtual network named `VNet-Corp` (172.16.0.0/12172.16.0.0/12). `VNet-Corp` contains three subnets:
- `Subnet-Web` (172.16.1.0/24172.16.1.0/24)
- `Subnet-DB` (172.16.2.0/24172.16.2.0/24)
- `Subnet-Sec` (172.16.100.0/24172.16.100.0/24) containing a Network Virtual Appliance (NVA) at IP address 172.16.100.10172.16.100.10.

A route table named `RT-Web` is associated with `Subnet-Web`. `RT-Web` contains the following user-defined routes (UDRs):
- A route for destination 172.16.0.0/16172.16.0.0/16 with a next hop type of Virtual Network Gateway.
- A route for destination 172.16.2.0/24172.16.2.0/24 with a next hop type of Virtual appliance and a next hop IP address of 172.16.100.10172.16.100.10.

IP forwarding is enabled on the network interface of the NVA. The default system route for the virtual network is 172.16.0.0/12172.16.0.0/12 with a next hop type of Virtual network.

A virtual machine in `Subnet-Web` attempts to send traffic to a database server at IP address 172.16.2.100172.16.2.100 in `Subnet-DB`.

Which next hop will Azure select for this traffic?

Show answer & explanation

Answer: The Network Virtual Appliance (NVA) at 172.16.100.10172.16.100.10 because the user-defined route for 172.16.2.0/24172.16.2.0/24 is the longest prefix match.

Answer

The Network Virtual Appliance (NVA) at 172.16.100.10172.16.100.10 because the user-defined route for 172.16.2.0/24172.16.2.0/24 is the longest prefix match.
When Azure routes traffic, it selects a route based on the Longest Prefix Match (LPM) algorithm among all matching routes (system routes and user-defined routes). The destination IP address 172.16.2.100172.16.2.100 matches three routes: the system route (172.16.0.0/12172.16.0.0/12), the UDR to the gateway (172.16.0.0/16172.16.0.0/16), and the UDR to the NVA (172.16.2.0/24172.16.2.0/24). Since 172.16.2.0/24172.16.2.0/24 has the longest prefix (24 bits), Azure selects this route. Because this route is a user-defined route (UDR) and has a next hop type of Virtual appliance pointing to 172.16.100.10172.16.100.10, the traffic is forwarded to the NVA.

Step-by-Step Solution

1
Identify all matching prefixes for the destination IP 172.16.2.100172.16.2.100.
The matching routes are: the default system route 172.16.0.0/12172.16.0.0/12, the UDR 172.16.0.0/16172.16.0.0/16, and the UDR 172.16.2.0/24172.16.2.0/24.
Before forwarding traffic, Azure evaluates all active routes in the subnet's effective route table to find matching destinations.
2
Compare the prefix lengths of the matching routes.
The prefix lengths are /12 (system route), /16 (gateway UDR), and /24 (NVA UDR).
Azure uses the Longest Prefix Match (LPM) algorithm to determine route precedence.
3
Select the route with the longest prefix and verify its next hop configuration.
The route 172.16.2.0/24172.16.2.0/24 is selected, which directs traffic to the Virtual Appliance at 172.16.100.10172.16.100.10.
Since /24 is the longest and most specific prefix, it takes precedence over the /16 and /12 prefixes, overriding both the default system route and the gateway route.

Key Concept

Azure route selection precedence based on Longest Prefix Match (LPM) and User-Defined Route (UDR) overrides.
Estimated Time:1m 15s
Question 871Question →

You have an Azure subscription that contains a Log Analytics workspace named Workspace1. Workspace1 is configured with the 'Require workspace permissions' access control mode. The subscription contains an Azure Key Vault named KeyVault1 and a virtual machine named VM1, both of which send their diagnostics to Workspace1. A user named User1 needs to run KQL queries to monitor KeyVault1 and VM1. User1 has the Reader role on both KeyVault1 and VM1, but currently has no access to Workspace1. When User1 attempts to query logs, no data is returned. You need to ensure User1 can query the diagnostics logs. Which two actions should you perform?

Select all that apply

Show answer & explanation

Answer: Configure Workspace1 to use resource or workspace permissions.; Assign the Log Analytics Reader role on Workspace1 to User1.

Answer

Configure the Log Analytics workspace to use resource or workspace permissions, and assign the Log Analytics Reader role on the workspace to the user.
Configuring the workspace to use resource or workspace permissions enables resource-context access, which allows the user to query logs for the specific resources they have permissions for (KeyVault1 and VM1). Alternatively, assigning the Log Analytics Reader role directly on the workspace grants workspace-context access, allowing the user to query all data in the workspace regardless of resource-level settings.

Step-by-Step Solution

1
Analyze the current permissions of the user and the configuration of the Log Analytics workspace.
The user has Reader access to the target resources but no permissions on the workspace. The workspace requires workspace permissions, preventing resource-context access.
To identify why the user cannot see the logs and determine the path to resolve it.
2
Evaluate the option to grant workspace-context access.
Assigning the Log Analytics Reader role to the user on the workspace allows them to run KQL queries on all data in the workspace.
To provide direct workspace access permissions to the user.
3
Evaluate the option to enable resource-context access.
Configuring the workspace to 'Use resource or workspace permissions' allows users with access to the source resources to query their logs without needing workspace-level permissions.
To leverage the user's existing resource-level Reader permissions.

Key Concept

Log Analytics Workspace access control modes govern how users are authorized to read log data. Workspace-context access requires permissions on the workspace itself (e.g., Log Analytics Reader). Resource-context access allows users to view logs for resources they have access to, provided the workspace is configured to use resource or workspace permissions.
Estimated Time:1m 30s
Question 872Question →

An administrator needs to deploy Azure Bastion (Standard SKU) to secure access to virtual machines in an existing virtual network named VNet1. The organization's security policy requires that a Network Security Group (NSG) be associated with the Bastion subnet, and that the subnet is secured from the very beginning of the Bastion host deployment.

Which sequence of steps must you perform to successfully configure and deploy Azure Bastion while adhering to the security policy and avoiding validation errors?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create the AzureBastionSubnet subnet first, then create and configure the Network Security Group with mandatory rules, associate the NSG with the AzureBastionSubnet, create a Standard SKU Public IP address, and finally provision the Azure Bastion host resource referencing the subnet and Public IP.
The correct sequence ensures that all prerequisites are created and configured in an order that satisfies Azure's validation checks. The subnet AzureBastionSubnet must be created with a prefix of /26 or larger. Next, the NSG must be created and populated with all required inbound (Internet, GatewayManager, AzureLoadBalancer) and outbound (VirtualNetwork, AzureCloud, Internet) rules. Once the NSG is fully configured, it is associated with the AzureBastionSubnet. If the NSG is associated before rules are configured, Azure resource validation will block the association. Next, a Standard SKU Public IP must be created because Azure Bastion does not support Basic SKU Public IPs. Finally, the Azure Bastion host resource is provisioned, referencing the configured subnet and Public IP.

Step-by-Step Solution

1
Create the AzureBastionSubnet
A subnet named exactly 'AzureBastionSubnet' is created in VNet1 with a /26 prefix.
Azure Bastion requires a dedicated subnet with this exact name and a prefix of /26 or larger (/25, /24, etc.) to accommodate scaling and host instances.
2
Create the NSG and add mandatory rules
An NSG is created with rules allowing inbound traffic from the Internet (port 443), GatewayManager (port 443), and AzureLoadBalancer (port 443), and allowing outbound traffic to the VirtualNetwork (ports 22 and 3389), AzureCloud (port 443), and Internet (ports 80 and 443).
Azure validates the NSG rules upon association to the AzureBastionSubnet. If the rules are missing or incorrect, the association or deployment fails.
3
Associate the NSG with the AzureBastionSubnet
The NSG is associated with the AzureBastionSubnet.
This satisfies the security requirement that the subnet must be secured from the moment of deployment.
4
Create a Standard SKU Public IP address
A Standard SKU, Static Public IP is created.
Azure Bastion requires a Standard SKU Public IP address, and it must be created before deploying the Bastion resource.
5
Provision the Azure Bastion host
The Azure Bastion host is deployed.
The Bastion host creation requires selecting the AzureBastionSubnet (which now has the correct NSG associated) and the Standard Public IP.

Key Concept

Azure Bastion deployment requires strict prerequisite configuration including a dedicated subnet named AzureBastionSubnet of at least /26 size, a Standard SKU Public IP, and a fully configured NSG with specific inbound and outbound rules that must be defined before subnet association.
Question 873Question →

An administrator deploys a Basic SKU public Azure Load Balancer to distribute traffic to two virtual machines named VM1 and VM2. VM1 is located in Availability Zone 1, and VM2 is located in Availability Zone 2. Both virtual machines are configured with Standard SKU public IP addresses. When attempting to add the network interfaces of VM1 and VM2 to the load balancer's backend pool, the virtual machines are not available for selection. Which change should the administrator implement to resolve this issue?

Show answer & explanation

Answer: Deploy a Standard SKU public Load Balancer to replace the Basic SKU public Load Balancer.

Answer

Deploy a Standard SKU public Load Balancer to replace the Basic SKU public Load Balancer.
Deploying a Standard SKU Load Balancer resolves both constraint violations. The Standard SKU Load Balancer supports backend pool members located in different Availability Zones and is fully compatible with Standard SKU public IP addresses configured on the virtual machines' network interfaces.

Step-by-Step Solution

1
Identify the restrictions of the Basic SKU public Load Balancer regarding availability zones and backend pool members.
Basic SKU Load Balancers do not support backend pools containing virtual machines distributed across different Availability Zones.
To understand why VM1 and VM2 are not available for selection in the backend pool configuration.
2
Identify the SKU compatibility requirements between the Load Balancer and the public IP addresses of the backend virtual machines.
Backend virtual machines with Standard SKU public IP addresses require a Standard SKU Load Balancer.
Basic SKU Load Balancers cannot be mixed with Standard SKU public IP addresses on the backend network interfaces.
3
Determine the correct component SKU needed to support both Availability Zones and Standard SKU public IPs.
A Standard SKU Load Balancer supports both Availability Zones and Standard SKU public IPs.
To resolve the configuration limitation and successfully associate the virtual machines with the backend pool.

Key Concept

Azure Load Balancer SKU feature support and compatibility rules regarding Availability Zones and public IP SKUs.
Question 874Question →

An administrator needs to identify unauthorized access attempts to an Azure Key Vault named KV-Prod. You are tasked with writing a Kusto Query Language (KQL) query in Log Analytics to retrieve all secret retrieval operations (SecretGet) that failed due to unauthorized access (HTTP status codes 401 or 403) within the last 24 hours. The query must only output the columns for TimeGenerated, Resource, CallerIPAddress, and ResultSignature. Which KQL query should you use?

Show answer & explanation

Answer: AzureDiagnostics
| where TimeGenerated > ago(24h)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName == "SecretGet"
| where ResultSignature in ("401", "403")
| project TimeGenerated, Resource, CallerIPAddress, ResultSignature

Answer

The query that starts with the AzureDiagnostics table, filters for records from the last 24 hours, restricts the resource provider to Microsoft Key Vault, filters for SecretGet operations and status codes 401 or 403, and then projects the required columns.
The correct query correctly follows the tabular operator syntax of KQL. It first filters the AzureDiagnostics table by TimeGenerated, ResourceProvider, OperationName, and ResultSignature, and then uses the project operator to output only the requested columns.

Step-by-Step Solution

1
Filter by time range first to optimize query performance.
The query begins with `AzureDiagnostics | where TimeGenerated > ago(24h)`.
Filtering by time first minimizes the dataset scanned by subsequent operators.
2
Filter by Key Vault resource provider and SecretGet operation.
Add `| where ResourceProvider == "MICROSOFT.KEYVAULT"` and `| where OperationName == "SecretGet"`.
This isolates diagnostic logs originating from Azure Key Vault specifically for secret retrieval actions.
3
Filter for unauthorized or forbidden HTTP status codes.
Add `| where ResultSignature in ("401", "403")`.
This captures diagnostic logs where the request was rejected due to authentication or authorization failures.
4
Project the specific columns requested in the output.
Add `| project TimeGenerated, Resource, CallerIPAddress, ResultSignature`.
This limits the returned columns to only those requested, completing the query.

Key Concept

Writing KQL queries using valid syntax and operator sequencing to analyze Azure diagnostics data.
Estimated Time:2m 0s
Question 875Question →

An administrator needs to write a Kusto Query Language (KQL) query in a Log Analytics workspace. The query must retrieve all heartbeat records for a virtual machine named VM1 that were generated in the last 24 hours.

Which two KQL queries meet these requirements? Select two.

Select all that apply

Show answer & explanation

Answer: `Heartbeat | where Computer == "VM1" and TimeGenerated > ago(24h)`; `Heartbeat | where TimeGenerated >= ago(24h) | where Computer == "VM1"`

Answer

The correct queries are the ones starting with 'Heartbeat | where Computer == "VM1" and TimeGenerated > ago(24h)' and 'Heartbeat | where TimeGenerated >= ago(24h) | where Computer == "VM1"'.
The queries that retrieve the correct records are the query utilizing the 'and' operator within a single filter and the query chaining two separate 'where' clauses. Both configurations correctly filter the Heartbeat logs by the specified computer name and within the past 24 hours using the 'ago()' function.

Step-by-Step Solution

1
Identify the target table and filter criteria.
The target table is `Heartbeat`. The query must filter where `Computer` equals 'VM1' and `TimeGenerated` is in the last 24 hours.
This establishes the database schema components and properties that need to be evaluated.
2
Verify correct KQL syntax for operators and functions.
String comparison requires `==`. Relative time filters require the `ago()` function to generate a datetime value.
Using `=` is invalid for comparison in a KQL `where` clause, and comparing a datetime to a timespan literal without `ago()` is invalid.
3
Evaluate how multiple query filters can be combined.
Filters can be combined within a single `where` clause using the logical `and` operator, or chained sequentially using multiple pipe (`|`) symbols.
Both methods are syntactically valid in KQL and produce the same output.

Key Concept

Writing basic queries in Log Analytics using KQL table operators, where clauses, comparison operators, and time functions.
Question 876Question →

An administrator creates an Azure resource group named `rg-hr-prod` and applies a tag named `Environment: Production` and a `ReadOnly` resource lock to the resource group. The administrator then deploys an Azure Storage account named `storeprod` to `rg-hr-prod`. The administrator attempts to view the tags applied to `storeprod` and retrieve the access keys for `storeprod`. What are the results of these actions?

Show answer & explanation

Answer: The storage account has no tags applied, and the retrieval of the access keys is blocked.

Answer

The storage account has no tags applied, and the retrieval of the access keys is blocked.
The correct answer is that the storage account has no tags applied and the retrieval of the access keys is blocked. This is because tags on resource groups do not propagate to the resources inside them. Furthermore, the ReadOnly lock applies to all resources in the group by inheritance. Listing storage access keys is treated as a POST action by the Azure Resource Manager API, which is blocked by the ReadOnly lock.

Step-by-Step Solution

1
Determine the tag inheritance status of the storage account.
The storage account does not inherit the Environment: Production tag from the resource group.
In Azure, tags applied at the resource group level are not inherited by resources within that resource group. To apply tags from a resource group to its resources, you must use Azure Policy or configure them manually.
2
Determine the effect of the ReadOnly lock on the storage account.
The retrieval of the access keys for the storage account is blocked.
Resource locks are inherited by child resources. A ReadOnly lock applied to a resource group applies to the storage account. Listing or retrieving storage account access keys is a control plane operation that uses a POST request. ReadOnly locks block all write and POST operations (including listKeys), thereby preventing key retrieval.

Key Concept

Resource locks of type ReadOnly block operations that modify resources or invoke POST actions (like listing keys), and tags applied to resource groups do not automatically propagate to child resources.
Estimated Time:1m 30s
Question 877Question →

Your company has an Azure subscription containing a virtual network named `VNet1`. `VNet1` has two subnets: `Subnet-Web` (10.10.1.0/2410.10.1.0/24) and `Subnet-DB` (10.10.2.0/2410.10.2.0/24).

The web servers are deployed in `Subnet-Web` and associated with an Application Security Group (ASG) named `ASG-Web`. The database servers are deployed in `Subnet-DB` and associated with an ASG named `ASG-DB`.

A Network Security Group (NSG) named `NSG-Web` is associated with `Subnet-Web`. An NSG named `NSG-DB` is associated with `Subnet-DB`. `NSG-DB` contains the following custom inbound security rule:
- Priority: 150150
- Source: `VirtualNetwork`
- Destination: `Any`
- Port: `*`
- Protocol: `Any`
- Action: `Deny`

You need to configure the NSGs to meet the following requirements:
1. Allow HTTPS traffic (TCP port 443443) from the Internet to the web servers.
2. Allow SQL Server traffic (TCP port 14331433) from the web servers to the database servers.
3. Adhere to the principle of least privilege.

Which two inbound security rules should you configure? (Select two.)

Select all that apply

Show answer & explanation

Answer: In `NSG-Web`, create a rule with Priority: 100100, Source: `Internet`, Port: 443443, Destination: `ASG-Web`, Action: `Allow`.; In `NSG-DB`, create a rule with Priority: 120120, Source: `ASG-Web`, Port: 14331433, Destination: `ASG-DB`, Action: `Allow`.

Answer

The correct configurations are: in `NSG-Web`, create an inbound rule with Priority: 100100, Source: `Internet`, Port: 443443, Destination: `ASG-Web`, Action: `Allow`; and in `NSG-DB`, create an inbound rule with Priority: 120120, Source: `ASG-Web`, Port: 14331433, Destination: `ASG-DB`, Action: `Allow`.
To allow inbound HTTPS traffic from the Internet to only the web servers while adhering to the principle of least privilege, the rule must be created in the web subnet's NSG (`NSG-Web`) with `ASG-Web` as the destination. To allow SQL Server traffic from the web servers to the database servers, the rule must be created in `NSG-DB`. Since there is an existing custom deny rule at priority 150150 in `NSG-DB`, the new allow rule must have a lower priority number (higher precedence), such as 120120, to be evaluated first.

Step-by-Step Solution

1
Analyze the requirement for HTTPS traffic.
Inbound HTTPS (port 443443) from the Internet must reach the web servers in `Subnet-Web`. The NSG associated with the subnet (`NSG-Web`) must have an inbound rule to allow this.
By default, inbound traffic from the Internet is blocked by the default DenyAllInbound rule.
2
Apply the principle of least privilege to the HTTPS rule.
Specify the destination as `ASG-Web` instead of `Any`.
This limits the allowed traffic strictly to the virtual machines associated with the web application security group, rather than the entire subnet.
3
Analyze the requirement for SQL Server traffic and the existing rule in `NSG-DB`.
SQL Server traffic (port 14331433) from `ASG-Web` to `ASG-DB` must pass through `NSG-DB`. `NSG-DB` has a custom rule at priority 150150 that denies all inbound virtual network traffic.
NSG rules are processed in priority order (lower numbers evaluated first). Any allow rule must have a priority lower than 150150 to take precedence over the deny rule.
4
Select the correct priority and scopes for the database rule.
Create a rule in `NSG-DB` with priority 120120, source `ASG-Web`, and destination `ASG-DB`.
Priority 120120 is processed before 150150, allowing the traffic to bypass the deny rule, while using ASGs targets only the relevant servers.

Key Concept

Azure Network Security Group (NSG) rule evaluation order (where lower priority numbers have higher precedence) and Application Security Group (ASG) integration to group VMs for granular security policies.
Question 878Question →

An administrator is planning the deployment of a new virtual machine named VM1 to host a business-critical application in the East US region. The application must be protected against datacenter-wide failures. Additionally, VM1 must be configured for daily backups. Which configuration should the administrator implement?

Show answer & explanation

Answer: Deploy VM1 to Availability Zone 1 in East US, and configure backups using a Recovery Services Vault located in East US.

Answer

Deploy VM1 to Availability Zone 1 in East US, and configure backups using a Recovery Services Vault located in East US.
Deploying the virtual machine to an Availability Zone ensures that it is placed in a physically isolated datacenter facility with independent power, cooling, and networking, protecting the application from datacenter-wide failures. Additionally, the Recovery Services Vault must be created in the same region as the virtual machine to configure daily backups.

Step-by-Step Solution

1
Analyze high availability requirements to protect against datacenter-wide outages.
Determine that Availability Zones must be used because Availability Sets only protect against localized hardware failures within a single datacenter.
Availability Zones locate resources in physically separate datacenters within an Azure region, providing power, cooling, and network isolation.
2
Determine region alignment requirements for virtual machine backup configuration.
Confirm that the Recovery Services Vault must reside in the same region as the source virtual machine.
Azure Backup does not support registering a virtual machine to a Recovery Services Vault located in a different geographical region.
3
Identify the target resource type.
Ensure the solution deploys an Infrastructure as a Service (IaaS) virtual machine rather than a Platform as a Service (PaaS) resource.
The requirement specifically calls for deploying a virtual machine named VM1.

Key Concept

Azure Virtual Machine High Availability and Backup Region Alignment
Question 879Question →

Your company implements a split-horizon DNS infrastructure in Azure. You configure the following resources:
- A public Azure DNS zone named contoso.com that contains an A record for www.contoso.com pointing to a public IP address.
- An Azure Private DNS zone named contoso.com that is linked to a virtual network named VNet1. The private zone contains an A record for db.contoso.com pointing to an internal IP address.
- A virtual machine named VM1 deployed in VNet1 that uses default Azure-provided DNS.

VM1 can successfully resolve db.contoso.com. However, when attempting to resolve www.contoso.com, VM1 receives a name resolution error (NXDOMAIN).

What should you do to ensure that VM1 can successfully resolve www.contoso.com?

Show answer & explanation

Answer: Add an A record for www.contoso.com pointing to the public IP address in the private DNS zone.

Answer

Add an A record for www.contoso.com pointing to the public IP address in the private DNS zone.
The correct answer is to manually add the A record for the public endpoint in the private DNS zone. In a split-horizon setup, when a virtual network is linked to an Azure Private DNS zone, Azure DNS acts as the authoritative resolver for the entire zone namespace. If a record is queried and not found in the private zone, Azure DNS returns NXDOMAIN rather than forwarding the query to public DNS servers. Therefore, to resolve the public endpoint internally, its record must be replicated in the private DNS zone.

Step-by-Step Solution

1
Analyze how Azure DNS resolves queries in linked virtual networks.
Azure DNS treats a linked private zone as authoritative for the entire domain namespace (e.g., contoso.com) within that VNet.
This determines the scope and authority of the DNS resolution engine.
2
Identify the cause of the NXDOMAIN error for the public record.
Because the private zone is authoritative and does not contain a record for www.contoso.com, Azure DNS returns NXDOMAIN instead of falling back to public DNS query resolution.
This explains why VM1 fails to resolve the public record despite it existing in the public DNS zone.
3
Select the appropriate split-horizon configuration modification.
Manually create the missing record (www.contoso.com) in the private DNS zone and point it to the public IP address.
This allows internal clients in VNet1 to resolve the external web app via the authoritative private zone.

Key Concept

Azure Private DNS Zone Authority and Split-Horizon DNS Resolution
Estimated Time:2m 0s
Question 880Question →

An administrator is designing a hub-and-spoke network topology in Azure using the following virtual networks in the East US region:
* VNet-Hub (10.100.0.0/1610.100.0.0/16): Contains a virtual network gateway in a subnet named GatewaySubnet, and a Network Virtual Appliance (NVA) in a subnet named DMZSubnet.
* VNet-SpokeA (10.101.0.0/1610.101.0.0/16): Contains a virtual machine named VM-App in a subnet named AppSubnet.
* VNet-SpokeB (10.102.0.0/1610.102.0.0/16): Contains a virtual machine named VM-DB in a subnet named DBSubnet.

The administrator establishes the following virtual network peering connections:
* Peering-Hub-SpokeA from VNet-Hub to VNet-SpokeA
* Peering-SpokeA-Hub from VNet-SpokeA to VNet-Hub
* Peering-Hub-SpokeB from VNet-Hub to VNet-SpokeB
* Peering-SpokeB-Hub from VNet-SpokeB to VNet-Hub

The administrator has configured user-defined routes (UDRs) on AppSubnet and DBSubnet to route traffic between the spokes through the NVA in VNet-Hub.

The administrator must meet the following requirements:
1. VM-App must be able to access on-premises networks via the virtual network gateway in VNet-Hub.
2. VM-App and VM-DB must be able to communicate with each other through the NVA in VNet-Hub.
3. VM-DB must be prevented from using the virtual network gateway in VNet-Hub.

Which configuration settings should the administrator apply to the peering connections to meet these requirements?

Show answer & explanation

Answer: Enable Allow gateway transit on Peering-Hub-SpokeA; enable Use remote gateways and Allow forwarded traffic on Peering-SpokeA-Hub; and enable Allow forwarded traffic and disable Use remote gateways on Peering-SpokeB-Hub.

Answer

The correct configuration requires enabling Allow gateway transit on the Hub-to-SpokeA peering, enabling Use remote gateways and Allow forwarded traffic on the SpokeA-to-Hub peering, and enabling Allow forwarded traffic while disabling Use remote gateways on the SpokeB-to-Hub peering.
To satisfy the requirements, the peering connection from the hub to VNet-SpokeA must permit gateway sharing (Allow gateway transit) and the spoke-to-hub peering must accept it (Use remote gateways). For spoke-to-spoke communication via the Network Virtual Appliance (NVA) in the hub, both VNet-SpokeA and VNet-SpokeB peering connections to VNet-Hub must allow forwarded traffic, as packets routed between them will originate from outside the hub's address space. Finally, to prevent VNet-SpokeB from using the gateway, Use remote gateways must be disabled on the VNet-SpokeB to VNet-Hub peering.

Step-by-Step Solution

1
Configure the peering connection to support gateway transit for the application virtual network (VNet-SpokeA).
Enable 'Allow gateway transit' on Peering-Hub-SpokeA and 'Use remote gateways' on Peering-SpokeA-Hub.
This allows virtual machines in VNet-SpokeA to route outbound traffic through the virtual network gateway in VNet-Hub.
2
Configure the peering connection to prevent gateway transit for the database virtual network (VNet-SpokeB).
Disable 'Use remote gateways' on Peering-SpokeB-Hub.
This prevents virtual machines in VNet-SpokeB from using the virtual network gateway in VNet-Hub.
3
Configure peering settings to support transit routing via the Network Virtual Appliance (NVA) in VNet-Hub.
Enable 'Allow forwarded traffic' on both Peering-SpokeA-Hub and Peering-SpokeB-Hub.
When traffic between VNet-SpokeA and VNet-SpokeB is routed through the NVA in VNet-Hub, the source IP addresses of the packets do not belong to VNet-Hub. Therefore, the spoke virtual networks must be configured to accept forwarded traffic from VNet-Hub.

Key Concept

Virtual Network Peering configuration settings including Gateway Transit, Remote Gateways, and Forwarded Traffic for transit routing architectures.
PreviousPage 44 / 63Next
All practice questions — Microsoft Azure Administrator (AZ-104) | Examkin