All practice questions

1252 questions

All types1,252 Multiple choice644 Multiple select429 True / False47 Matching52 Ordering80

An administrator manages an Azure subscription that contains a resource group named `rg-dev-sandbox`. The resource group contains a virtual machine named `vm-sandbox` and a storage account named `stdevsandbox`.

The administrator applies a tag named `Dept: Engineering` and a `CanNotDelete` lock to `rg-dev-sandbox`.

Which statement describes the resulting governance state of the resources in `rg-dev-sandbox`?

The virtual machine and the storage account cannot be deleted, and they do not inherit the tag.

The virtual machine and the storage account automatically inherit the tag, but they can be deleted because the lock only prevents deletion of the resource group.

The virtual machine and the storage account automatically inherit both the lock and the tag.

The virtual machine and the storage account can be deleted by a subscription Owner because resource locks do not restrict users who inherit the Owner role from the subscription.

Show answer & explanation

Answer: The virtual machine and the storage account cannot be deleted, and they do not inherit the tag.

Answer

The virtual machine and the storage account cannot be deleted, and they do not inherit the tag.

The correct answer states that the virtual machine and the storage account cannot be deleted, and they do not inherit the tag. This is correct because resource locks applied at the resource group level inherit to all child resources, blocking delete operations. However, tags on resource groups are not inherited by child resources.

Step-by-Step Solution

Evaluate the inheritance behavior of the resource lock.

The CanNotDelete lock applied to the resource group is inherited by all resources inside the resource group.

Azure Resource Manager propagates resource locks from parent scopes (subscriptions, resource groups) to child resources.

Evaluate the inheritance behavior of the tag.

The tag applied to the resource group is not inherited by the child resources.

By default, tags applied to a resource group do not automatically apply to the resources contained within it.

Verify if RBAC roles can bypass the lock.

Even subscription Owners are blocked from deletion by the inherited lock.

Locks are enforced at the control plane level for all users, including those with administrative permissions.

Key Concept

Resource lock inheritance and tag non-inheritance behaviors in Azure Resource Manager.

Estimated Time:1m 30s

Question 802Question →

An administrator deploys three virtual networks in the Azure environment:
* VNet-Hub ( $10.80.0.0/16$ ): Contains a subnet named GatewaySubnet ( $10.80.0.0/24$ ) with an active Virtual Network Gateway connected to an on-premises network ( $172.16.0.0/16$ ), and a subnet named Subnet-Hub ( $10.80.1.0/24$ ) with a virtual machine named VM-Hub.
* VNet-SpokeA ( $10.81.0.0/16$ ): Contains a subnet named Subnet-A ( $10.81.1.0/24$ ) with a virtual machine named VM-A.
* VNet-SpokeB ( $10.82.0.0/16$ ): Contains a subnet named Subnet-B ( $10.82.1.0/24$ ) with a virtual machine named VM-B.

The administrator configures virtual network peering between VNet-Hub and VNet-SpokeA, and between VNet-Hub and VNet-SpokeB with the following settings:
* For both peerings, Allow virtual network access is set to Enabled and Allow forwarded traffic is set to Enabled.
* On the peering connections from VNet-Hub to both spokes, Allow gateway transit is set to Enabled.
* On the peering connections from both spokes to VNet-Hub, Use remote gateways is set to Enabled.

No user-defined routes (UDRs) or network security groups (NSGs) are configured.

Which statement correctly describes the connectivity established by this configuration?

Neither VM-A nor VM-B can communicate with the on-premises network unless a User-Defined Route with a next hop type of Virtual Network Gateway is associated with Subnet-A and Subnet-B.

VM-A and VM-B can communicate with each other, and both can communicate with the on-premises network.

VM-A and VM-B can both communicate with the on-premises network, but VM-A and VM-B cannot communicate with each other.

VM-A and VM-B can communicate with each other, but neither can communicate with the on-premises network unless a User-Defined Route is created in GatewaySubnet.

Show answer & explanation

Answer: VM-A and VM-B can both communicate with the on-premises network, but VM-A and VM-B cannot communicate with each other.

Answer

VM-A and VM-B can both communicate with the on-premises network, but VM-A and VM-B cannot communicate with each other.

The correct answer is correct because virtual network peering is non-transitive. Even though both spoke virtual networks are peered with the hub virtual network and configured to use remote gateways, this configuration only permits spoke-to-hub and spoke-to-on-premises (via the VPN gateway) communication. It does not allow traffic from one spoke to traverse the hub to reach another spoke. To enable spoke-to-spoke communication, a network virtual appliance (NVA) or firewall must be deployed in the hub, or direct peering must be configured between the spokes.

Step-by-Step Solution

Analyze the gateway transit configuration.

Since 'Allow gateway transit' is enabled on the hub peering links and 'Use remote gateways' is enabled on the spoke peering links, both spoke networks (VNet-SpokeA and VNet-SpokeB) can utilize the VPN Gateway in VNet-Hub to reach the on-premises network.

This allows the spoke VNets to access the hybrid connectivity path established in the hub VNet.

Analyze the spoke-to-spoke connectivity.

Although both spokes are connected to the hub, virtual network peering is non-transitive. Traffic from VNet-SpokeA cannot transit VNet-Hub to reach VNet-SpokeB unless a network virtual appliance (NVA) or Azure Firewall is introduced with custom routing.

By default, Azure virtual network peering does not support transit routing between two peered networks via a third peered network.

Synthesize the overall connectivity status.

VM-A and VM-B can successfully communicate with the on-premises network, but they cannot communicate directly with each other.

Gateway transit allows spoke-to-on-premises traffic, but non-transitivity prevents spoke-to-spoke traffic.

Key Concept

Azure Virtual Network Peering is non-transitive, and gateway transit only allows spokes to reach the hub gateway and on-premises resources.

Question 803Question →

An administrator is configuring a public load balancer to distribute traffic to three virtual machines:

* VM1 and VM2, which are in an Availability Set named AS1
* VM3, which is a standalone virtual machine

All virtual machines are located in the same virtual network and subnet.

The administrator has created a Standard SKU public IP address named Pub-IP1 and a Basic SKU load balancer named LB1.

You need to identify the configuration changes required to load balance incoming internet traffic across VM1, VM2, and VM3 using Pub-IP1.

Which two actions should you perform? (Choose two.)

Select all that apply

Deploy a Standard SKU load balancer.

Associate Pub-IP1 with the frontend IP configuration of the Standard SKU load balancer.

Associate Pub-IP1 with the frontend IP configuration of the existing Basic SKU load balancer (LB1).

Configure the backend pool of the existing Basic SKU load balancer (LB1) to include both the virtual machines in AS1 and the standalone virtual machine VM3.

Show answer & explanation

Answer: Deploy a Standard SKU load balancer.; Associate Pub-IP1 with the frontend IP configuration of the Standard SKU load balancer.

Answer

Deploy a Standard SKU load balancer, and associate Pub-IP1 with the frontend IP configuration of the Standard SKU load balancer.

To support load balancing across a mixed pool of standalone virtual machines and virtual machines in an availability set, and to utilize a Standard SKU public IP address, a Standard SKU load balancer is required. The Standard SKU public IP address must then be associated with the frontend IP configuration of this Standard SKU load balancer.

Step-by-Step Solution

Analyze the SKU compatibility of the public IP address and the load balancer.

Identify that the public IP (Pub-IP1) is Standard SKU, while the existing load balancer (LB1) is Basic SKU. These SKUs are incompatible.

Azure requires the Public IP SKU to match the Load Balancer SKU.

Analyze the backend pool requirements for the virtual machines.

Identify that the virtual machines are a mix of an availability set (AS1) and a standalone VM (VM3). A Basic SKU load balancer cannot support this configuration in its backend pool.

Basic SKU load balancers only support virtual machines within a single availability set or virtual machine scale set in their backend pool.

Determine the required load balancer SKU to support both the Standard public IP and the mixed backend pool configuration.

Determine that a Standard SKU load balancer must be deployed.

Standard SKU load balancers support Standard public IPs and allow any virtual machines in a single virtual network to be added to the backend pool.

Determine the frontend IP configuration action.

Associate Pub-IP1 with the frontend IP configuration of the Standard SKU load balancer.

This binds the incoming public traffic destination to the new Standard SKU load balancer.

Key Concept

Azure Load Balancer SKU features and compatibility constraints

Question 804Question →

Your company has an Azure subscription named sub-apexion-prod. You plan to configure customer-managed keys (CMK) to encrypt an Azure Storage account named saapexionpatient. You deploy an Azure Key Vault named kv-apexion-keys. The Key Vault has both soft-delete and purge protection enabled and is configured to use Azure role-based access control (RBAC) for authorization. The storage account is configured with a system-assigned managed identity. You need to grant the storage account the minimum required permissions to the key vault to enable CMK encryption. Which role should you assign to the system-assigned managed identity of the storage account?

Key Vault Contributor

Key Vault Reader

Key Vault Crypto Service User

Key Vault Crypto Officer

Show answer & explanation

Answer: Key Vault Crypto Service User

Answer

Key Vault Crypto Service User

The correct answer is Key Vault Crypto Service User. When Key Vault is configured for Azure RBAC authorization, the system-assigned managed identity of the storage account requires data plane access to perform key encryption operations (specifically wrapping and unwrapping). The Key Vault Crypto Service User role is the built-in role designed for this purpose, providing the least privilege needed.

Step-by-Step Solution

Identify the authentication and authorization mechanism configured on the Key Vault.

The Key Vault is configured to use Azure RBAC for authorization.

This means built-in Azure RBAC roles must be used instead of classic Key Vault access policies.

Determine the cryptographic operations required by the Storage Account managed identity.

The Storage Account managed identity needs permissions to wrap and unwrap keys stored in the Key Vault.

These operations are necessary for Azure Storage to encrypt and decrypt data using the customer-managed key.

Evaluate the roles to find the one that grants the minimum necessary permissions.

Key Vault Crypto Service User grants only the wrap and unwrap actions on keys.

Other roles either grant management-plane-only access (Key Vault Contributor, Key Vault Reader) or excessive data plane permissions (Key Vault Crypto Officer).

Key Concept

To enable customer-managed keys (CMK) for a storage account using Azure RBAC for Key Vault authorization, the storage account's managed identity must be granted the Key Vault Crypto Service User role, which provides the minimum necessary data plane permissions (wrap and unwrap keys).

Question 805Question →

An administrator is configuring an Azure Application Gateway to host two distinct websites: sales.contoso.com and marketing.contoso.com. Both sites must be accessed using the same public IP address of the gateway but must route to different backend pools. Which listener type should be configured on the Application Gateway?

Basic

Multi-site

Path-based

Private

Show answer & explanation

Answer: Multi-site

Answer

Configure a multi-site listener on the Application Gateway.

Configuring a multi-site listener is correct because it allows the Application Gateway to host multiple domain names on a single public IP address and port. The gateway reads the Host header in incoming HTTP requests to route them to the correct backend pool.

Step-by-Step Solution

Determine the requirement for hosting multiple distinct host names (sales.contoso.com and marketing.contoso.com) on a single public IP address.

Identify that a basic listener is insufficient because it only maps to a single host name or IP address.

Basic listeners cannot process multiple domain names on the same port.

Select the appropriate listener type that supports host name-based routing.

Choose the multi-site listener option during Application Gateway listener configuration.

Multi-site listeners read the HTTP Host header of incoming requests to determine which site is being targeted.

Associate the multi-site listener with routing rules to forward traffic to the appropriate backend pools.

Configure distinct routing rules for each website pointing to its respective backend pool.

Routing rules connect the listener to the backend pools.

Key Concept

Azure Application Gateway listeners define how incoming traffic is received. A basic listener handles a single domain, while a multi-site listener allows hosting multiple domains (e.g., sales.contoso.com and marketing.contoso.com) on the same IP address and port by inspecting the HTTP Host header.

Question 806Question →

An organization is configuring access control for its Azure resources. You need to assign the appropriate built-in Azure RBAC roles to meet specific administrative requirements based on the principle of least privilege. Match each administrative requirement to the correct built-in Azure RBAC role.

Click a left item, then click its matching right item

Show answer & explanation

Answer

Each administrative requirement is matched to its corresponding Azure RBAC role based on the principle of least privilege: Virtual Machine Contributor for VM lifecycle management without network/storage permissions; User Access Administrator for role assignments; Contributor for full resource management without access delegation; and Reader for read-only access to resources.

Each assignment represents the minimum permissions required to perform the designated tasks. User Access Administrator allows granting roles without managing the resources. Contributor allows resource management without role delegation. Virtual Machine Contributor allows VM actions without storage/network modification. Reader allows auditing configurations without modification.

Step-by-Step Solution

Analyze the requirement for deploying and managing virtual machines without network or storage access.

Identify that the Virtual Machine Contributor role matches this requirement because it does not grant permissions to manage networks or storage accounts.

Applying the principle of least privilege requires choosing the built-in role that limits scope to VM operations only.

Analyze the requirement to assign roles without resource creation permissions.

Identify that the User Access Administrator role matches this requirement because it grants permissions to manage role assignments but not resource management.

This separates identity access management from resource control.

Analyze the requirement to manage all resources in a resource group without delegating access to others.

Identify that the Contributor role matches this requirement.

The Contributor role has full management capabilities except authorization tasks, which are restricted to Owner and User Access Administrator roles.

Analyze the requirement to view all configurations without modifications.

Identify that the Reader role matches this requirement.

The Reader role provides read-only access to resources, matching the auditing scope.

Key Concept

Azure Role-Based Access Control (RBAC) built-in roles and the principle of least privilege.

Estimated Time:2m 0s

Question 807Question →

Your company is deploying a new Azure Kubernetes Service (AKS) cluster to host a microservices application. The Azure environment includes a virtual network named `VNet1` with the address space $172.20.0.0/16$ . The AKS cluster will be deployed into a subnet named `aks-subnet` ( $172.20.8.0/24$ ). The cluster is required to scale up to $15$ nodes, with each node supporting a maximum of $80$ pods. The pods must be able to communicate with on-premises database servers over an existing ExpressRoute connection. To prevent virtual network IP address exhaustion, the network security team mandates that pod IP addresses must not be allocated from the $172.20.0.0/16$ address space. Additionally, the solution must not require the configuration or management of user-defined routes (UDRs) or route tables for pod routing. Which network configuration should you use for the AKS cluster?

Azure CNI Overlay

Kubenet

Azure CNI with dynamic pod IP allocation

Azure CNI with static IP allocation

Show answer & explanation

Answer: Azure CNI Overlay

Answer

Azure CNI Overlay

Azure CNI Overlay is the correct choice because it assigns pods IP addresses from a private CIDR block that is completely separate from the virtual network (

172.20.0.0/16

), thereby satisfying the security mandate. It supports the required scaling limits because only the nodes receive IP addresses from the

172.20.8.0/24

subnet. Additionally, unlike Kubenet, Azure CNI Overlay does not require the configuration of user-defined routes (UDRs) or route tables for pod routing, and it seamlessly handles outbound traffic to on-premises networks over ExpressRoute by NAT'ing the pod traffic to the node's VNet IP address.

Step-by-Step Solution

Analyze the IP address capacity and constraints.

The target subnet `aks-subnet` (

172.20.8.0/24

) has only 251 usable IP addresses. The cluster requires up to

15

nodes, each supporting

80

pods (totaling

1,200

pods). Standard Azure CNI (static IP allocation) requires an IP address from the subnet for every pod, which would require

1,200

IPs and fail due to IP exhaustion.

Determines that standard Azure CNI cannot be used due to IP capacity limitations.

Evaluate the pod IP address allocation security mandate.

The security team requires that pod IPs must not come from the

172.20.0.0/16

space. Azure CNI with dynamic pod IP allocation still requires provisioning a subnet within the virtual network's address space (

172.20.0.0/16

) for the pods, which violates this security requirement.

Eliminates dynamic pod IP allocation.

Compare Overlay options based on routing and complexity constraints.

Both Kubenet and Azure CNI Overlay use an overlay network where pods get IPs from a private non-VNet CIDR. However, Kubenet requires Azure route tables and user-defined routes (UDRs) to route traffic between nodes. Azure CNI Overlay handles pod-to-pod routing internally via an overlay data path without requiring UDRs or custom route tables, and performs SNAT to the node's IP for outbound traffic (making it routable to on-premises via the ExpressRoute gateway).

Identifies the correct configuration that satisfies all requirements.

Key Concept

Azure Kubernetes Service (AKS) networking models, specifically the differences in IP address allocation, scalability, and routing complexity between Kubenet, Azure CNI, and Azure CNI Overlay.

Question 808Question →

An organization has an Azure subscription containing two subnets named Subnet-Web ( $10.1.1.0/24$ ) and Subnet-App ( $10.1.2.0/24$ ). A virtual machine named VM-Web is deployed in Subnet-Web, and its network interface is associated with an Application Security Group named ASG-Web. A virtual machine named VM-App is deployed in Subnet-App, and its network interface is associated with an Application Security Group named ASG-App.

A network security group named NSG-Subnet is associated with Subnet-App and contains the following inbound security rules:
* Priority $110$ : Source: ASG-Web, Destination: ASG-App, Port: $443$ , Protocol: TCP, Action: Deny
* Priority $120$ : Source: $10.1.1.0/24$ , Destination: Any, Port: $443$ , Protocol: TCP, Action: Allow

A network security group named NSG-NIC is associated with the network interface of VM-App and contains the following inbound security rule:
* Priority $100$ : Source: ASG-Web, Destination: ASG-App, Port: $443$ , Protocol: TCP, Action: Allow

What is the outcome when VM-Web attempts to connect to VM-App on TCP port $443$ ?

The connection is allowed because the rule with priority

100

in NSG-NIC has a higher precedence (lower priority number) than the deny rule in NSG-Subnet.

The connection is blocked because NSG-Subnet is evaluated first for inbound traffic, and its rule with priority

110

matches and denies the traffic.

The connection is allowed because the rule with priority

120

in NSG-Subnet matches the source IP address range of VM-Web and overrides the rule with priority

110

The connection is blocked because NSG-NIC is evaluated first for inbound traffic, and the rule with priority

100

is overridden by the subnet-level rules.

Show answer & explanation

Answer: The connection is blocked because NSG-Subnet is evaluated first for inbound traffic, and its rule with priority $110$ matches and denies the traffic.

Answer

The connection is blocked because NSG-Subnet is evaluated first for inbound traffic, and its rule with priority 110 matches and denies the traffic.

For inbound traffic, Azure processes the network security group (NSG) associated with the subnet first, followed by the NSG associated with the network interface (NIC). Within each NSG, rules are evaluated in order of priority, where lower priority numbers take precedence. In NSG-Subnet, the rule with priority 110 matches the connection request from the Application Security Group (ASG) associated with VM-Web (ASG-Web) to the ASG associated with VM-App (ASG-App) on port 443, resulting in a Deny action. Because the traffic is blocked at the subnet level, evaluation stops, and the NIC-level NSG (NSG-NIC) is not processed.

Step-by-Step Solution

Determine the direction of the network traffic and the NSG evaluation sequence.

The traffic is inbound to VM-App. For inbound traffic, Azure first evaluates the network security group associated with the subnet (NSG-Subnet) and then evaluates the network security group associated with the network interface (NSG-NIC).

Understanding the order of NSG evaluation is critical since inbound traffic must pass both subnet and NIC-level NSGs to be allowed.

Evaluate the rules in the subnet-level NSG (NSG-Subnet) in order of priority.

The rule with priority

110

(Deny from ASG-Web to ASG-App on port

443

) has a lower number than the rule with priority

120

. It is evaluated first. Since the source VM-Web is in ASG-Web and destination VM-App is in ASG-App, the rule matches and the traffic is denied.

Rules within an NSG are processed sequentially starting from the lowest priority number. The first matching rule determines the outcome, and subsequent rules are ignored.

Determine the final outcome of the connection attempt.

Since the traffic is denied at the subnet level, the evaluation stops immediately. The NIC-level NSG (NSG-NIC) is not evaluated, and the connection is blocked.

If traffic is blocked at the subnet level for inbound connections, it is dropped immediately and does not reach the NIC-level NSG.

Key Concept

Azure Network Security Group inbound evaluation order and rule priority processing

Question 809Question →

You have an Azure subscription that contains a virtual network named `VNet1`. `VNet1` contains two subnets:
- `Subnet-Web` ( $10.0.1.0/24$ )
- `Subnet-DB` ( $10.0.2.0/24$ )

The following virtual machines are deployed in `VNet1`:
- `VM-Web1` is in `Subnet-Web` and its network interface is associated with an Application Security Group named `ASG-Web`.
- `VM-DB1` is in `Subnet-DB` and its network interface is associated with an Application Security Group named `ASG-DB`.

The following Network Security Groups (NSGs) are configured and associated:
- `NSG-Subnet` is associated with `Subnet-Web` and contains the following outbound security rule:
- Priority: $150$
- Source: `*`
- Destination: $10.0.2.0/24$
- Port: `*`
- Protocol: `Any`
- Action: `Deny`
- `NSG-NIC-DB` is associated with the network interface of `VM-DB1` and contains the following inbound security rule:
- Priority: $200$
- Source: $10.0.1.0/24$
- Destination: `*`
- Port: `*`
- Protocol: `Any`
- Action: `Deny`

All other NSG settings and rules are at their default values.

You need to allow SSH (TCP port $22$ ) and HTTPS (TCP port $443$ ) connections from `VM-Web1` to `VM-DB1`. The solution must follow the principle of least privilege.

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

Select all that apply

In `NSG-Subnet`, add an outbound security rule with a priority of

120

that allows TCP ports

22

and

443

from `ASG-Web` to `ASG-DB`.

In `NSG-NIC-DB`, add an inbound security rule with a priority of

180

that allows TCP ports

22

and

443

from `ASG-Web` to `ASG-DB`.

In `NSG-Subnet`, add an outbound security rule with a priority of

180

that allows TCP ports

22

and

443

from `ASG-Web` to `ASG-DB`.

In `NSG-NIC-DB`, add an inbound security rule with a priority of

220

that allows TCP ports

22

and

443

from `ASG-Web` to `ASG-DB`.

In `NSG-Subnet`, add an inbound security rule with a priority of

120

that allows TCP ports

22

and

443

from `ASG-Web` to `ASG-DB`.

Show answer & explanation

Answer: In `NSG-Subnet`, add an outbound security rule with a priority of $120$ that allows TCP ports $22$ and $443$ from `ASG-Web` to `ASG-DB`.; In `NSG-NIC-DB`, add an inbound security rule with a priority of $180$ that allows TCP ports $22$ and $443$ from `ASG-Web` to `ASG-DB`.

Answer

To allow SSH and HTTPS connections from VM-Web1 to VM-DB1 while maintaining the principle of least privilege, you must add an outbound security rule in NSG-Subnet with a priority of 120 that allows TCP ports 22 and 443 from ASG-Web to ASG-DB, and add an inbound security rule in NSG-NIC-DB with a priority of 180 that allows TCP ports 22 and 443 from ASG-Web to ASG-DB.

For the traffic to succeed, it must pass both the outbound evaluation at the source subnet level and the inbound evaluation at the destination NIC level. In `NSG-Subnet`, adding an outbound Allow rule with a priority of

120

successfully overrides the Deny rule at priority

150

. In `NSG-NIC-DB`, adding an inbound Allow rule with a priority of

180

successfully overrides the Deny rule at priority

200

. Both rules target `ASG-Web` as the source and `ASG-DB` as the destination for ports

22

and

443

, which maintains the principle of least privilege.

Step-by-Step Solution

Analyze the outbound path from `VM-Web1`.

Outbound traffic from `VM-Web1` is processed by the subnet NSG `NSG-Subnet`.

Before leaving the subnet, traffic is evaluated against outbound rules. The existing rule has a priority of

150

and blocks all outbound traffic to `Subnet-DB` (

10.0.2.0/24

Resolve the outbound block in `NSG-Subnet`.

An outbound rule with a priority lower than

150

(such as

120

) must be added.

Azure processes rules in order of priority (lower numbers first). To allow SSH (

22

) and HTTPS (

443

) traffic from `ASG-Web` to `ASG-DB` before the Deny rule is processed, the new rule must have a priority number less than

150

Analyze the inbound path to `VM-DB1`.

Inbound traffic is evaluated by the network interface NSG `NSG-NIC-DB`.

Since `Subnet-DB` has no subnet-level NSG, the traffic is evaluated directly at the NIC-level NSG. The existing rule has a priority of

200

and blocks all inbound traffic from `Subnet-Web` (

10.0.1.0/24

Resolve the inbound block in `NSG-NIC-DB`.

An inbound rule with a priority lower than

200

(such as

180

) must be added.

To allow the traffic to pass the NIC-level NSG, an inbound Allow rule for TCP ports

22

and

443

targeting `ASG-Web` to `ASG-DB` must be processed before the Deny rule at priority

200

Key Concept

Azure NSGs evaluate rules sequentially using priority numbers where lower numbers have higher precedence. When traffic flows across subnets, outbound rules on the source subnet/NIC are evaluated first, followed by inbound rules on the destination subnet/NIC.

Question 810Question →

Your company is deploying application servers in a new Azure virtual network named CorpVNet. You need to configure Azure Bastion in CorpVNet to enable secure RDP and SSH connections to the virtual machines. Which subnet configuration meets the requirements for the Azure Bastion deployment?

A subnet named BastionSubnet with an address space prefix of /26

A subnet named AzureBastionSubnet with an address space prefix of /27

A subnet named AzureBastionSubnet with an address space prefix of /26

A subnet named BastionSubnet with an address space prefix of /24

Show answer & explanation

Answer: A subnet named AzureBastionSubnet with an address space prefix of /26

Answer

A subnet named AzureBastionSubnet with an address space prefix of /26

Azure Bastion requires a dedicated subnet named exactly AzureBastionSubnet. The subnet must have a prefix size of /26 or larger (such as /25 or /24) to support scale-out operations and management traffic.

Step-by-Step Solution

Identify the mandatory subnet name required for Azure Bastion deployment.

The subnet name must be exactly AzureBastionSubnet.

Azure Bastion only recognizes and deploys into a subnet with this specific name.

Determine the minimum address space prefix requirement for the Bastion subnet.

The subnet prefix must be /26 or larger.

Azure Bastion requires at least a /26 subnet to support scale-out and underlying infrastructure management.

Key Concept

Azure Bastion subnet requirements (exact naming and minimum subnet size)

Question 811Question →

You are preparing a virtual network in Azure for the deployment of a new Application Gateway instance to distribute incoming web traffic. When preparing the target subnet for the gateway, which rule or constraint must you follow?

The subnet must be dedicated solely to the Application Gateway resources.

The subnet must be named GatewaySubnet to allow routing to the backend.

The subnet must host the backend virtual machines to prevent latency.

The subnet must block all inbound traffic on ports 65200 through 65535 using a Network Security Group.

Show answer & explanation

Answer: The subnet must be dedicated solely to the Application Gateway resources.

Answer

The subnet must be dedicated solely to the Application Gateway resources.

The correct answer is that the subnet must be dedicated solely to the Application Gateway resources. Azure requires a dedicated subnet for Application Gateway deployments. You cannot host other resources, such as virtual machines or standard load balancers, in the same subnet.

Step-by-Step Solution

Analyze the subnet requirements for deploying an Azure Application Gateway.

Identify that the subnet hosting the Application Gateway cannot contain any other resource types.

Azure enforces this restriction so that the gateway can scale and manage its own internal infrastructure within the subnet without resource contention.

Evaluate the naming and routing requirements.

Determine that while the subnet requires an appropriate size (typically /26 or larger), it does not have a naming restriction like 'GatewaySubnet', and backend hosts must be placed elsewhere.

Using reserved names like 'GatewaySubnet' will conflict with virtual network gateways, and mixing backend VMs with the gateway violates isolation rules.

Key Concept

Subnet requirements for Azure Application Gateway

Estimated Time:45s

Question 812Question →

You need to write a Kusto Query Language (KQL) query in Azure Log Analytics to find all heartbeat records from the last 24 hours for a virtual machine named VM1. Which KQL query should you use?

Heartbeat | where TimeGenerated > ago(24h) and Computer = "VM1"

SELECT * FROM Heartbeat WHERE TimeGenerated > ago(24h) AND Computer = 'VM1'

Heartbeat | where TimeGenerated > ago(24h) and Computer == "VM1"

Heartbeat | filter TimeGenerated > ago(24h) and Computer == "VM1"

Show answer & explanation

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

Answer

The KQL query that retrieves heartbeat records using the 'where' operator and the double equals (==) comparison operator: Heartbeat | where TimeGenerated > ago(24h) and Computer == "VM1"

The query correctly initiates the scan of the Heartbeat table, pipes it to the where operator to filter based on TimeGenerated using the ago() function, and applies the string comparison constraint on the Computer column using the double equals (==) operator.

Step-by-Step Solution

Select the correct target log table.

Identify the 'Heartbeat' table as the source of agent diagnostic logs.

Azure Monitor VM agent status and availability details are stored in the Heartbeat table.

Apply the time filter using a relative time range helper function.

Add '| where TimeGenerated > ago(24h)' to query only logs generated within the last 24 hours.

The 'ago' function dynamically calculates the start time point relative to the current execution execution.

Filter by the virtual machine name using the proper comparison operator.

Add 'and Computer == "VM1"' to refine the records.

In KQL, the logical equality operator is represented by '==' and is case-insensitive for strings.

Key Concept

Basic KQL querying using the where operator, time ranges, and equality comparisons.

Question 813Question →

An organization manages its cloud resources using the following Azure hierarchy:
- Management Group: `MG-Production`
- Subscription: `Sub-AppStore`
- Resource Groups: `RG-Services` and `RG-Database`

You need to delegate the ability to manage Azure Role-Based Access Control (RBAC) role assignments for all current and future resource groups inside `Sub-AppStore` to a security group named `Group-SecurityAdmins`. Members of `Group-SecurityAdmins` must not be able to create, delete, or modify any actual resources within the subscription.

Which role and scope should you assign to `Group-SecurityAdmins` to meet the requirements while adhering to the principle of least privilege?

User Access Administrator at the `Sub-AppStore` subscription scope

Owner at the `Sub-AppStore` subscription scope

User Access Administrator at the `RG-Services` and `RG-Database` resource group scopes

User Administrator in Microsoft Entra ID

Show answer & explanation

Answer: User Access Administrator at the `Sub-AppStore` subscription scope

Answer

Assign the User Access Administrator role at the `Sub-AppStore` subscription scope.

Assigning the User Access Administrator role at the `Sub-AppStore` subscription scope is correct because the User Access Administrator role is designed specifically to manage access to Azure resources (RBAC assignments) without granting the ability to create, delete, or modify the resources themselves. Because Azure RBAC assignments inherit down the hierarchy, configuring this role at the subscription level automatically extends the access to all current and future resource groups inside that subscription, satisfying the least privilege requirement.

Step-by-Step Solution

Identify the administrative requirement and scope.

The requirement is to manage role assignments for all current and future resource groups in the `Sub-AppStore` subscription.

This determines the scope of the assignment. Because role assignments are inherited downward in the Azure resource hierarchy, assigning a role at the subscription scope ensures it automatically applies to all existing and future resource groups within that subscription.

Determine the least-privileged role that allows managing role assignments.

The User Access Administrator role allows managing Azure resource access (RBAC assignments) but does not allow resource modification, unlike the Owner role which grants full control.

This aligns with the principle of least privilege, ensuring that users can perform the necessary administrative tasks without having excess permissions to modify or delete resources.

Differentiate between Azure RBAC roles and Microsoft Entra ID roles.

Microsoft Entra ID roles like User Administrator operate at the directory level and cannot manage Azure resource RBAC assignments directly.

This rules out directory roles which do not have authority over subscription-level resources.

Key Concept

Azure RBAC inheritance and the distinction between the Owner and User Access Administrator roles for least privilege.

Estimated Time:1m 30s

Question 814Question →

An administrator is configuring network security for a two-tier application in an Azure subscription. The subscription contains a virtual network named $VNet1$ with two subnets: $Subnet-Web$ and $Subnet-Database$ .

- $VM-Web$ is deployed in $Subnet-Web$ and has its network interface associated with an Application Security Group named $ASG-Web$ .
- $VM-Database$ is deployed in $Subnet-Database$ and has its network interface associated with an Application Security Group named $ASG-Database$ .
- A Network Security Group named $NSG-Subnet$ is associated with $Subnet-Database$ .
- A Network Security Group named $NSG-NIC$ is associated with the network interface of $VM-Database$ .

You need to allow database traffic on TCP port $1433$ from $VM-Web$ to $VM-Database$ while maintaining the principle of least privilege.

Which of the following actions should you perform? (Select two.)

Select all that apply

In NSG-Subnet, create an inbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.

In NSG-NIC, create an inbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.

In NSG-Subnet, create an outbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.

In NSG-NIC, create an outbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.

Associate ASG-Web with Subnet-Web.

Show answer & explanation

Answer: In NSG-Subnet, create an inbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.; In NSG-NIC, create an inbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.

Answer

In NSG-Subnet, create an inbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database; and in NSG-NIC, create an inbound security rule that allows TCP port 1433 traffic from source ASG-Web to destination ASG-Database.

For inbound traffic to a VM in a subnet that has a subnet-level NSG and whose NIC has a NIC-level NSG, the traffic is evaluated by the subnet NSG first, followed by the NIC NSG. To permit the connection, both NSGs must have an inbound rule allowing the traffic. Specifying ASG-Web as the source and ASG-Database as the destination on TCP port 1433 maintains the principle of least privilege.

Step-by-Step Solution

Analyze the network security group evaluation flow for inbound traffic.

Inbound traffic destined for a virtual machine is evaluated first by any Network Security Group (NSG) associated with the subnet, and then by any NSG associated with the network interface (NIC).

This establishes that both NSG-Subnet and NSG-NIC must explicitly permit the traffic.

Identify the source and destination resources using Application Security Groups (ASGs).

The source is VM-Web (represented by ASG-Web) and the destination is VM-Database (represented by ASG-Database) on TCP port 1433.

This ensures the rules use the most specific targets to maintain the principle of least privilege.

Formulate the required rules for both NSGs.

Create an inbound rule in NSG-Subnet allowing TCP 1433 from ASG-Web to ASG-Database, and create an identical inbound rule in NSG-NIC.

This allows the traffic through both evaluation points.

Key Concept

Inbound traffic to an Azure virtual machine with NSGs associated at both the subnet and NIC levels must pass through rules in both NSGs. Using Application Security Groups allows grouping network interfaces to simplify security policies.

Question 815Question →

An administrator is deploying an Azure Virtual Machine Scale Set named `vmss-worker`. The scale set will run a containerized background processing application. The startup script of the application registers each virtual machine instance with an external monitoring service. You need to ensure that the scale set does not provision temporary, excess virtual machine instances during scale-out events, as this leads to orphaned registrations in the monitoring service. What should you do?

Set the overprovision property of the Virtual Machine Scale Set to false.

Set the upgrade policy of the Virtual Machine Scale Set to Manual.

Set the scale-in policy of the Virtual Machine Scale Set to NewestVM.

Set the singlePlacementGroup property of the Virtual Machine Scale Set to false.

Show answer & explanation

Answer: Set the overprovision property of the Virtual Machine Scale Set to false.

Answer

Disable overprovisioning by setting the overprovision property of the Virtual Machine Scale Set to false.

Disabling overprovisioning by setting the overprovision property to false prevents Azure from spinning up temporary, excess virtual machine instances during scale-out events. This ensures that only the requested number of instances are provisioned and initialized, preventing orphaned registrations in external services like monitoring tools.

Step-by-Step Solution

Analyze the scale-out behavior of the Virtual Machine Scale Set.

By default, the scale set has overprovisioning enabled (overprovision=true), which deploys extra VMs to speed up provisioning time and deletes them once the target count is healthy.

Identify why temporary VMs are running initialization scripts and causing orphaned registrations.

Determine the configuration setting to prevent extra VM provisioning.

Disabling overprovisioning (setting overprovision to false) restricts Azure to provisioning only the exact number of instances specified in the scale-out request.

Ensures startup/initialization scripts are executed only on virtual machines that will remain part of the active scale set.

Select the correct parameter modification in the Azure Resource Manager (ARM) template or CLI/PowerShell command.

Setting the overprovision property to false resolves the orphaned registration issue.

Applies the required configuration to the scale set's deployment template.

Key Concept

Disabling Virtual Machine Scale Set (VMSS) overprovisioning prevents the creation and subsequent immediate deletion of temporary virtual machine instances during scale-out events, which is critical when initialization scripts perform external registrations.

Question 816Question →

Your company has an Azure subscription containing an Azure Private DNS zone named corp.contoso.com. You have two virtual networks named VNet1 and VNet2 in the same Azure region. You need to configure Azure Private DNS so that virtual machines in VNet1 can resolve names in corp.contoso.com and automatically register their own DNS records. Virtual machines in VNet2 must be able to resolve names in corp.contoso.com but must not automatically register their DNS records. Which two configurations should you implement? (Select two.)

Select all that apply

A virtual network link from corp.contoso.com to VNet1 with auto-registration enabled

A virtual network link from corp.contoso.com to VNet2 with auto-registration disabled

A virtual network link from corp.contoso.com to VNet2 with auto-registration enabled

A virtual network peering connection between VNet1 and VNet2 with transit enabled

Show answer & explanation

Answer: A virtual network link from corp.contoso.com to VNet1 with auto-registration enabled; A virtual network link from corp.contoso.com to VNet2 with auto-registration disabled

Answer

Configure a virtual network link from the private DNS zone to VNet1 with auto-registration enabled, and configure a virtual network link from the private DNS zone to VNet2 with auto-registration disabled.

To enable name resolution and auto-registration for VNet1, you must create a virtual network link from the Private DNS zone to VNet1 with auto-registration enabled. To allow only name resolution for VNet2 without auto-registration, you must link the Private DNS zone to VNet2 with auto-registration disabled. Azure Private DNS allows multiple virtual network links to a single zone, but only one link can have auto-registration enabled at any time.

Step-by-Step Solution

Analyze VNet1 requirements

Identify that VNet1 requires both name resolution and auto-registration.

This determines that a virtual network link is needed with the auto-registration setting set to enabled.

Analyze VNet2 requirements

Identify that VNet2 requires name resolution but must not register hostnames.

This determines that a virtual network link is needed with the auto-registration setting set to disabled.

Evaluate Azure Private DNS limitations

Verify that a Private DNS zone can support only one link with auto-registration enabled, which aligns with VNet1 being the only auto-registered VNet.

Ensures the proposed design is valid and compliant with Azure limits.

Key Concept

Azure Private DNS virtual network links and auto-registration behavior

Estimated Time:2m 0s

Question 817Question →

An administrator is configuring inbound internet access to an internal web server through an Azure Firewall. The administrator needs to allow HTTP traffic on port 80 to the web server while ensuring all other inbound traffic is blocked.

Which of the following configurations are required to meet these requirements? (Select two)

Select all that apply

Configure a Destination Network Address Translation (DNAT) rule to map the firewall's public IP address to the web server's private IP address.

Associate at least one public IP address with the Azure Firewall to receive the incoming traffic.

Create a Network rule in the firewall to explicitly allow inbound TCP port 80 traffic to the web server's private IP address.

Associate a Network Security Group (NSG) to the AzureFirewallSubnet with an inbound allow rule for TCP port 80.

Show answer & explanation

Answer: Configure a Destination Network Address Translation (DNAT) rule to map the firewall's public IP address to the web server's private IP address.; Associate at least one public IP address with the Azure Firewall to receive the incoming traffic.

Answer

To allow inbound HTTP traffic to the internal web server, the administrator must configure a Destination Network Address Translation (DNAT) rule mapping the firewall's public IP address to the web server's private IP, and associate at least one public IP address with the Azure Firewall.

Configuring a Destination Network Address Translation (DNAT) rule translates incoming traffic to the firewall's public IP into the web server's private IP, and associating at least one public IP address provides the necessary entry point for external traffic.

Step-by-Step Solution

Identify the traffic direction and required translation.

Since traffic is inbound from the internet to a private IP, Destination Network Address Translation (DNAT) is required.

DNAT maps the public IP of the firewall to the private IP of the web server.

Ensure the firewall has a public endpoint to listen on.

The firewall must be associated with at least one public IP address.

Without a public IP address, the firewall cannot receive external internet traffic or apply DNAT rules.

Evaluate rule requirements and implicit rules.

No separate Network rule is required because DNAT rules automatically include an implicit allow rule for the translated traffic.

Understanding implicit rules prevents redundant or incorrect firewall rule configurations.

Key Concept

Azure Firewall inbound traffic configuration requires a public IP and a DNAT rule, which automatically creates an implicit allow rule.

Question 818Question →

You plan to deploy a public Standard Load Balancer named $LB1$ . $LB1$ will have a backend pool named $Pool1$ . You have a virtual network named $VNet1$ that contains a subnet named $Subnet1$ . $Subnet1$ contains three virtual machines:

- $VM1$ : Configured with a Basic SKU public IP address directly assigned to its network interface ( $NIC1$ ).
- $VM2$ : Configured with a Standard SKU public IP address directly assigned to its network interface ( $NIC2$ ).
- $VM3$ : Configured with no public IP address.

Currently, no Network Security Groups (NSGs) are associated with $Subnet1$ or any of the virtual machine network interfaces. Which of the following sets of actions must you perform to successfully add all three virtual machines to $Pool1$ and ensure that health probes succeed?

Associate a network security group (NSG) to

Subnet1

with an inbound rule allowing the `AzureLoadBalancer` service tag, and either upgrade the public IP of

VM1

to Standard SKU or dissociate it from

NIC1

Associate a network security group (NSG) to

Subnet1

with an inbound rule allowing the `AzureLoadBalancer` service tag, and change the public IP of

VM2

to a Basic SKU public IP.

Remove

VM1

from

Pool1

and configure a network security group (NSG) on

Subnet1

with an inbound rule allowing the `Internet` service tag.

Dissociate the public IP address from

VM2

, and create an inbound network security group (NSG) rule allowing the `AzureLoadBalancer` service tag on

NIC1

only.

Show answer & explanation

Answer: Associate a network security group (NSG) to $Subnet1$ with an inbound rule allowing the `AzureLoadBalancer` service tag, and either upgrade the public IP of $VM1$ to Standard SKU or dissociate it from $NIC1$ .

Answer

Associate a network security group (NSG) to Subnet1 with an inbound rule allowing the AzureLoadBalancer service tag, and either upgrade the public IP of VM1 to Standard SKU or dissociate it from NIC1.

The correct action resolves the SKU compatibility issue on VM1 while satisfying the security requirements of the Standard Load Balancer. Since Standard Load Balancers only support Standard SKU public IPs or interfaces with no public IPs in their backend pool, VM1's Basic public IP must be upgraded or dissociated. Furthermore, Standard Load Balancers are secure by default, so health probes will fail unless an NSG is associated with the subnet (or NICs) and contains an inbound rule allowing traffic from the AzureLoadBalancer service tag.

Step-by-Step Solution

Analyze the SKU compatibility requirements for the Standard Load Balancer backend pool.

Standard Load Balancers require all backend network interfaces to either have no public IP or have a Standard SKU public IP. VM1's Basic SKU public IP is incompatible.

To identify why VM1 cannot be added directly to the backend pool.

Select the resolution for VM1's IP address SKU mismatch.

The public IP of VM1 must be upgraded to Standard SKU or dissociated from NIC1. VM2 and VM3 do not require changes.

To align VM1's configuration with the Standard Load Balancer requirements.

Analyze health probe behavior and default security settings of Standard Load Balancers.

Standard Load Balancers are secure by default, meaning all inbound traffic to backend instances (including health probes) is blocked without an NSG.

To determine why health probes would fail by default.

Define the security rule requirement to allow health probes.

Associate an NSG to Subnet1 and configure an inbound security rule allowing traffic from the AzureLoadBalancer service tag.

To permit the load balancer health probe traffic to reach all backend VMs.

Key Concept

Azure Standard Load Balancer SKU compatibility and default security behaviors.

Estimated Time:3m 0s

Question 819Question →

An administrator is configuring a public Azure Load Balancer. The administrator first deploys a Standard SKU public IP address named Pub-IP1.

The backend pool of the load balancer will contain two virtual machines, VM1 and VM2, which are deployed in a single Availability Set.

Which of the following configurations must be used to ensure the load balancer and its backend pool can be successfully deployed? (Select two.)

Select all that apply

A Standard SKU load balancer

A Basic SKU load balancer

Virtual machine network interfaces (NICs) configured with Standard SKU public IP addresses or no instance-level public IP addresses

Virtual machine network interfaces (NICs) configured with Basic SKU public IP addresses

Show answer & explanation

Answer: A Standard SKU load balancer; Virtual machine network interfaces (NICs) configured with Standard SKU public IP addresses or no instance-level public IP addresses

Answer

A Standard SKU load balancer and virtual machine network interfaces (NICs) configured with Standard SKU public IP addresses or no instance-level public IP addresses must be used.

To successfully deploy the solution, a Standard SKU load balancer must be used because the frontend public IP address is a Standard SKU. Additionally, the backend virtual machines' network interfaces must either have no instance-level public IP addresses or use Standard SKU public IP addresses to remain compatible with the Standard SKU load balancer.

Step-by-Step Solution

Identify the SKU of the deployed public IP address.

The public IP address Pub-IP1 is a Standard SKU public IP.

The load balancer SKU must match the public IP SKU associated with its frontend configuration.

Determine the load balancer SKU that is compatible with Pub-IP1.

A Standard SKU load balancer is required.

Basic SKU load balancers cannot be associated with Standard SKU public IPs.

Evaluate compatibility requirements for the backend pool virtual machines.

The NICs of VM1 and VM2 must either have no instance-level public IP addresses or have Standard SKU public IP addresses.

Basic SKU public IPs on backend NICs are incompatible with a Standard SKU load balancer.

Key Concept

Azure Load Balancer SKU compatibility rules require matching SKUs between the load balancer, its frontend public IP addresses, and any instance-level public IP addresses on backend virtual machines.

Question 820Question →

An administrator manages a virtual network named `VNet-Sales` with the address space $172.20.0.0/16$ . The virtual network contains the following subnets:

* `Subnet-Web`: $172.20.10.0/24$
* `Subnet-App`: $172.20.20.0/24$
* `Subnet-Security`: $172.20.30.0/24$

A custom security appliance named `NVA-Firewall` is deployed in `Subnet-Security` with the IP address $172.20.30.4$ . IP forwarding is enabled on the network interface of `NVA-Firewall`.

The administrator wants to ensure that all traffic from `Subnet-Web` destined for `Subnet-App` is routed through `NVA-Firewall` for inspection.

Which route table configuration and association should the administrator apply to achieve this goal?

Create a route with a destination prefix of

172.20.20.0/24

, set the next hop type to Virtual Network Gateway, specify the next hop IP address as

172.20.30.4

, and associate the route table with Subnet-Web.

Create a route with a destination prefix of

172.20.20.0/24

, set the next hop type to Virtual appliance, specify the next hop IP address as

172.20.30.4

, and associate the route table with Subnet-Web.

Create a route with a destination prefix of

172.20.20.0/24

, set the next hop type to Virtual appliance, specify the next hop IP address as

172.20.30.4

, and associate the route table with Subnet-App.

Create a route with a destination prefix of

172.20.0.0/16

, set the next hop type to Virtual appliance, specify the next hop IP address as

172.20.30.4

, and associate the route table with Subnet-Web.

Show answer & explanation

Answer: Create a route with a destination prefix of $172.20.20.0/24$ , set the next hop type to Virtual appliance, specify the next hop IP address as $172.20.30.4$ , and associate the route table with Subnet-Web.

Answer

Create a route with a destination prefix of

172.20.20.0/24

, set the next hop type to Virtual appliance, specify the next hop IP address as

172.20.30.4

, and associate the route table with Subnet-Web.

To route traffic from Subnet-Web to Subnet-App through a Network Virtual Appliance (NVA), you must associate a route table with the source subnet (Subnet-Web). The route in the route table must target the destination subnet (Subnet-App:

172.20.20.0/24

) and use the 'Virtual appliance' next hop type pointing to the private IP address of the NVA (

172.20.30.4

). Since a specific subnet route (

172.20.20.0/24

) is more specific than the default virtual network local route (

172.20.0.0/16

), Azure's Longest Prefix Match (LPM) rule ensures that traffic to Subnet-App is directed to the NVA.

Step-by-Step Solution

Identify the source of the traffic flow and the required subnet association.

The traffic originates from Subnet-Web. Therefore, the User-Defined Route (UDR) table must be associated with Subnet-Web to govern its outbound routing.

Azure route tables only affect outbound traffic originating from resources in the subnets to which the route table is associated.

Determine the correct destination IP prefix and routing precedence.

The target destination subnet is Subnet-App (

172.20.20.0/24

By defining a specific route for

172.20.20.0/24

, Azure's Longest Prefix Match (LPM) logic selects this route over the more general default virtual network system route (

172.20.0.0/16

Specify the next hop type and next hop IP address for the firewall VM.

The next hop type must be set to 'Virtual appliance' and the next hop IP address must be set to the NVA's interface IP (

172.20.30.4

A custom VM serving as a firewall is classified as a Virtual appliance in Azure. The next hop IP address must be within a subnet located inside the same virtual network or a peered virtual network.

Key Concept

User-Defined Routes (UDR) Next Hop and Subnet Association

Estimated Time:1m 30s

PreviousPage 41 / 63Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept