All practice questions

1252 questions

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

You are managing an Azure environment with a single virtual network named `VNet1`. The virtual network contains two subnets: `Subnet-Web` and `Subnet-DB`.

The resources are configured as follows:
- A virtual machine named `VM-Web` is deployed in `Subnet-Web` and is associated with an Application Security Group named `ASG-Web`.
- A virtual machine named `VM-DB` is deployed in `Subnet-DB` and is associated with an Application Security Group named `ASG-DB`.
- A Network Security Group named `NSG-Subnet-DB` is associated with `Subnet-DB`.
- A Network Security Group named `NSG-NIC-DB` is associated with the network interface of `VM-DB`.

`NSG-Subnet-DB` contains the following inbound security rules:

Priority	Source	Source Port	Destination	Destination Port	Protocol	Action
$200$	`ASG-Web`	`*`	`ASG-DB`	$5432$	TCP	Allow
$300$	`VirtualNetwork`	`*`	`VirtualNetwork`	$5432$	TCP	Deny

`NSG-NIC-DB` contains the following inbound security rules:

Priority	Source	Source Port	Destination	Destination Port	Protocol	Action
$150$	`VirtualNetwork`	`*`	`ASG-DB`	$5432$	TCP	Deny
$250$	`ASG-Web`	`*`	`ASG-DB`	$5432$	TCP	Allow

`VM-Web` attempts to establish a database connection to `VM-DB` on TCP port $5432$ .

What is the outcome of this connection attempt?

The connection is blocked because the inbound rule with priority

150

in `NSG-NIC-DB` matches and denies the traffic.

The connection is allowed because the inbound rule with priority

200

in `NSG-Subnet-DB` allows the traffic, which takes precedence over network interface rules.

The connection is allowed because the inbound rule with priority

250

in `NSG-NIC-DB` specifically allows traffic from `ASG-Web` to `ASG-DB`.

The connection is blocked because the inbound rule with priority

300

in `NSG-Subnet-DB` denies the traffic.

Show answer & explanation

Answer: The connection is blocked because the inbound rule with priority $150$ in `NSG-NIC-DB` matches and denies the traffic.

Answer

The connection is blocked because the inbound rule with priority

150

in `NSG-NIC-DB` matches and denies the traffic.

For inbound traffic to a VM, Azure first evaluates the NSG associated with the subnet, followed by the NSG associated with the network interface (NIC). At each level, rules are processed sequentially by priority number (lowest value first), and evaluation stops at the first matching rule. In this scenario, the subnet NSG allows the traffic at priority

200

. Then, the NIC NSG evaluates the traffic. The rule with priority

150

(Deny) matches the traffic because the source VM is in the same virtual network (VirtualNetwork) and the destination is the database ASG on port

5432

. Because priority

150

is lower than

250

, the Deny rule matches first, blocking the connection.

Step-by-Step Solution

Evaluate the subnet-level NSG (NSG-Subnet-DB) for the inbound traffic from VM-Web to VM-DB on TCP port 5432.

The traffic is allowed by the rule with priority 200 (Source: ASG-Web, Destination: ASG-DB, Port: 5432, Action: Allow) because rule 200 is processed before rule 300.

For inbound traffic, Azure processes the subnet-level NSG first. Rules within an NSG are processed in priority order (lowest number first), and processing stops on the first match.

Evaluate the network interface-level NSG (NSG-NIC-DB) for the inbound traffic.

The traffic matches the rule with priority 150 (Source: VirtualNetwork, Destination: ASG-DB, Port: 5432, Action: Deny) because VM-Web's IP is within the VirtualNetwork prefix.

If the subnet NSG allows the traffic, the NIC NSG is processed next. Rules are again processed in priority order.

Determine the final state of the traffic connection.

The connection is blocked at the network interface level by the priority 150 rule.

Since the NIC NSG matches a Deny rule (priority 150) before reaching the Allow rule (priority 250), the traffic is dropped.

Key Concept

Inbound NSG traffic evaluation flow and rule priority logic using Application Security Groups (ASGs)

Estimated Time:1m 30s

Question 602Question →

An administrator plans to deploy a new Azure Kubernetes Service (AKS) cluster. The cluster pods must be assigned IP addresses directly from an existing Azure Virtual Network subnet to enable direct routing to other resources in the virtual network without performing Network Address Translation (NAT). Which network plugin should be selected during the AKS cluster configuration?

Azure CNI

Kubenet

Azure Application Gateway Ingress Controller

Kubenet with Calico network policies

Show answer & explanation

Answer: Azure CNI

Answer

Azure CNI

The network plugin that meets this requirement is Azure CNI. When using Azure CNI, every pod receives a native IP address from the virtual network subnet. This allows pods to communicate directly with other resources in the virtual network, peered networks, or on-premises networks without using Network Address Translation (NAT).

Step-by-Step Solution

Analyze the requirements for pod IP allocation.

Pods must get IP addresses directly from the virtual network subnet and communicate without NAT.

This requirement determines the choice of AKS network plugin.

Compare the features of Kubenet and Azure CNI network plugins.

Azure CNI provides direct VNet IP allocation for pods, whereas Kubenet uses NAT and a separate logical IP space.

Matching the features to the requirement identifies the correct option.

Key Concept

Azure Kubernetes Service (AKS) network models (Azure CNI vs Kubenet)

Question 603Question →

A company has an Azure virtual network with two subnets named Subnet-Web and Subnet-DB. A virtual machine named VM-Web is deployed in Subnet-Web and associated with an Application Security Group (ASG) named ASG-Web. A virtual machine named VM-DB is 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, and an NSG named NSG-DB is associated with Subnet-DB.

In NSG-DB, the following inbound security rules are configured:
- Rule1: Priority 150, Source: ASG-Web, Destination: ASG-DB, Port: 80, Protocol: TCP, Action: Deny
- Rule2: Priority 250, Source: Any, Destination: Any, Port: 80, Protocol: TCP, Action: Allow

NSG-Web contains a custom outbound rule that allows all traffic on port 80 to ASG-DB.

What is the outcome when VM-Web attempts to establish an HTTP connection on TCP port 80 to VM-DB?

The connection is blocked because NSG-DB evaluates Rule1 (priority 150) before Rule2 (priority 250), which denies the traffic.

The connection is allowed because Rule2 in NSG-DB has a higher priority number (250) than Rule1 (150).

The connection is allowed because NSG-Web allows the outbound traffic, which automatically bypasses the inbound rules of NSG-DB.

The connection is allowed because Application Security Groups bypass inbound Network Security Group rules when VMs are in the same virtual network.

Show answer & explanation

Answer: The connection is blocked because NSG-DB evaluates Rule1 (priority 150) before Rule2 (priority 250), which denies the traffic.

Answer

The connection is blocked because NSG-DB evaluates the rule with the lower priority number (150) first, which denies the traffic.

The connection is blocked because Azure Network Security Groups evaluate rules in ascending order of their priority numbers. Rule1 has a priority of 150, which is lower than Rule2's priority of 250. Because 150 is evaluated first and matches the source and destination ASGs on port 80, the traffic is denied immediately, and Rule2 is never processed.

Step-by-Step Solution

Evaluate the outbound path from VM-Web.

The traffic is allowed to leave Subnet-Web because NSG-Web has a custom outbound rule allowing port 80 to ASG-DB.

Traffic must pass outbound NSG rules at the source subnet and interface before reaching the destination.

Evaluate the inbound path at NSG-DB in order of rule priority.

Rule1 (priority 150) is compared against Rule2 (priority 250). Since 150 < 250, Rule1 is evaluated first.

Azure processes Network Security Group rules sequentially, starting with the lowest numerical priority value.

Match the traffic against the rule criteria in Rule1.

The traffic matches the source (ASG-Web), destination (ASG-DB), port (80), and protocol (TCP). The Deny action is applied.

Since a match is found, further rule evaluation (including Rule2) stops immediately, and the connection is blocked.

Key Concept

Azure NSG rule processing order and priority numbers

Estimated Time:1m 0s

Question 604Question →

You have an Azure virtual network named `VNet1` that contains two subnets: `Subnet1` ( $10.0.1.0/24$ ) and `Subnet2` ( $10.0.2.0/24$ ). You deploy a virtual machine in `Subnet2` that acts as a Network Virtual Appliance (NVA) with the private IP address of $10.0.2.4$ . You need to route all outbound traffic from `Subnet1` destined for the internet through the NVA. Which two actions should you perform? (Select two.)

Select all that apply

Create a route table, add a route for destination

0.0.0.0/0

with the next hop type set to Virtual appliance pointing to

10.0.2.4

, and associate the route table with Subnet1.

Enable IP forwarding on the network interface (NIC) attached to the virtual machine acting as the Network Virtual Appliance.

Associate the custom route table with Subnet2 to ensure the Network Virtual Appliance can route the traffic.

Create a route table, add a route for destination

0.0.0.0/0

with the next hop type set to Virtual Network Gateway pointing to

10.0.2.4

, and associate the route table with Subnet1.

Show answer & explanation

Answer: Create a route table, add a route for destination $0.0.0.0/0$ with the next hop type set to Virtual appliance pointing to $10.0.2.4$ , and associate the route table with Subnet1.; Enable IP forwarding on the network interface (NIC) attached to the virtual machine acting as the Network Virtual Appliance.

Answer

To successfully route outbound traffic from Subnet1 through the Network Virtual Appliance, you must create a route table with a default route (

0.0.0.0/0

) using the next hop type 'Virtual appliance' pointing to the appliance's IP address, associate this route table with Subnet1, and enable IP forwarding on the appliance's network interface.

Routing outbound traffic through a Network Virtual Appliance requires redirecting source traffic via a custom route table associated with the source subnet, referencing the appliance IP as a Virtual appliance next hop. In addition, the virtual machine hosting the appliance must have IP forwarding enabled at its Azure network interface level, otherwise the platform will discard the forwarded packets.

Step-by-Step Solution

Configure the User-Defined Route (UDR).

Create a route table, add a route targeting

0.0.0.0/0

with a next hop type of Virtual appliance and the IP address of

10.0.2.4

, and associate the route table with Subnet1.

This overrides the default system route for internet traffic from Subnet1 and directs it to the Network Virtual Appliance.

Enable IP forwarding on the Network Virtual Appliance.

Enable IP forwarding on the Azure network interface (NIC) of the virtual machine acting as the Network Virtual Appliance.

This permits the virtual machine's network interface to accept and forward network traffic that is not directly addressed to itself.

Key Concept

Routing traffic through a Network Virtual Appliance (NVA) requires creating a User-Defined Route (UDR) with the 'Virtual appliance' next hop type associated with the source subnet, along with enabling IP forwarding on the NVA's network interface in Azure.

Question 605Question →

An administrator is configuring Microsoft Entra ID to meet security, governance, and hybrid connectivity requirements. Match each administrative requirement to its minimum required license tier or configuration setting.

Click a left item, then click its matching right item

Show answer & explanation

Answer

The requirement to configure password writeback from Microsoft Entra ID to on-premises AD DS matches with the Microsoft Entra ID P1 or P2 license tier. The requirement to restrict guest user invitations to only users assigned to specific administrative roles matches with Guest invite settings in External collaboration settings. The requirement to enable guest user self-service sign-up for an enterprise application matches with an External Identities user flow associated with the application.

The correct mapping pairs password writeback with the Microsoft Entra ID P1/P2 license, limits guest invitation scoping using the External collaboration settings, and assigns self-service sign-up to External Identities user flows linked to the application.

Step-by-Step Solution

Analyze the licensing requirement for password writeback.

Password writeback is an SSPR feature that synchronizes cloud password changes back to on-premises Active Directory.

This functionality requires a paid premium license, specifically Microsoft Entra ID P1 or P2.

Determine how to control who can invite guest users.

Locate the invitation restriction setting, which limits invitations to administrative roles such as Guest Inviter.

This is configured in the tenant's External collaboration settings under Guest invite settings.

Evaluate the mechanism for self-service sign-up of external users.

Identify that a user flow must be created to define the authentication methods and attributes collected during sign-up.

The user flow must then be linked directly to the application in the External Identities settings.

Key Concept

Microsoft Entra ID Self-Service Password Reset (SSPR) licensing requirements and External Collaboration configuration settings.

Estimated Time:1m 30s

Question 606Question →

An organization hosts a web application on an Azure App Service named `hr-prod-app` that runs on a Standard (S1) App Service plan. You need to implement a new deployment slot named `hr-stage-app` to test code updates. To perform canary testing under production load, you must direct $15\%$ of incoming user traffic to the staging slot. Which two actions should you perform? (Select TWO.)

Select all that apply

Add a deployment slot named `hr-stage-app` to the `hr-prod-app` App Service.

From the Deployment slots blade of `hr-prod-app`, configure the Traffic % setting of the `hr-stage-app` slot to

15

Scale up the App Service plan for `hr-prod-app` to the Premium V3 (P1v3) pricing tier.

Create a Network Security Group (NSG) and configure inbound security rules with custom priority values to distribute traffic.

Show answer & explanation

Answer: Add a deployment slot named `hr-stage-app` to the `hr-prod-app` App Service.; From the Deployment slots blade of `hr-prod-app`, configure the Traffic % setting of the `hr-stage-app` slot to $15$ .

Answer

To implement the deployment slot and canary testing, you must add the deployment slot named `hr-stage-app` to the App Service, and then on the Deployment slots blade of `hr-prod-app`, configure the Traffic % setting of the `hr-stage-app` slot to

15

To host the staging environment and route

15\%

of production traffic to it, you must first create the deployment slot named `hr-stage-app` in the App Service. Since the App Service is running on a Standard (S1) plan, it natively supports up to

5

deployment slots. Second, you use the built-in Testing in production feature on the Deployment slots blade of the production app (`hr-prod-app`) to set the Traffic % of the staging slot to

15

. This redirects

15\%

of incoming requests to the staging slot automatically.

Step-by-Step Solution

Verify if the current App Service Plan supports deployment slots.

The App Service is running on a Standard (S1) plan, which supports up to

5

deployment slots. No scale-up is required.

Before deploying a slot, you must ensure the App Service Plan is at least on the Standard tier.

Create the deployment slot.

A new slot named `hr-stage-app` is created under the `hr-prod-app` App Service.

This provides the staging environment to deploy and test the new code updates.

Configure canary routing to the staging slot.

In the Deployment slots blade of the production app, the Traffic % for the `hr-stage-app` slot is set to

15

This natively routes

15\%

of production traffic to the staging slot for canary testing.

Key Concept

Azure App Service deployment slots and native traffic routing (testing in production) allow administrators to deploy code to non-production slots and route a specified percentage of production traffic to them without upgrading to Premium tiers if already on Standard.

Estimated Time:2m 0s

Question 607Question →

A retail company is preparing to launch a new customer portal on Azure App Service. The portal must be hosted under a custom domain name with a custom SSL certificate. The operations team needs to test new updates in a staging environment before routing live user traffic to them. Additionally, the hosting environment must support scaling out to $3$ dedicated instances to handle traffic spikes. Which App Service plan pricing tier is the most cost-effective option that satisfies all requirements?

P1v3

Show answer & explanation

Answer: S1

Answer

The S1 tier is the most cost-effective pricing tier that provides custom SSL support, dedicated compute instances with scaling capabilities, and deployment slots for staging environments. The S1 tier supports up to

5

deployment slots and scaling up to

10

instances.

Step-by-Step Solution

Analyze the requirement for staging slots.

Eliminates the F1, D1, and B1 pricing tiers, as deployment slots are only supported starting from the Standard (S) tier.

Deployment slots are not available in the Free, Shared, or Basic tiers.

Analyze the requirements for custom domains with custom SSL certificates and scaling.

S1 and P1v3 both support custom domains, custom SSL, and scaling out to at least

3

instances.

The Standard tier supports up to

10

instances and

5

slots, while Premium v3 supports up to

30

instances and

20

slots.

Compare the cost of the remaining tiers (S1 and P1v3) to determine the most cost-effective solution.

S1 is selected as the correct answer.

S1 meets all constraints and is less expensive than P1v3.

Key Concept

App Service Plan pricing tier capabilities

Question 608Question →

You have an Azure Storage account named financestorage that contains a blob container named audits. You need to grant an external audit application temporary access to read and list blobs in the audits container. The solution must meet the following requirements:
- Limit access to the IP address range 203.0.113.0/24.
- Allow connections only over HTTPS.
- Limit access to a duration of 8 hours.
- Provide the ability to immediately revoke access before the 8-hour period expires without rotating the storage account access keys.

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

Select all that apply

Create a stored access policy on the audits container.

Generate a service SAS for the audits container that references the stored access policy.

Generate an account SAS that has the IP range and expiration time configured directly on the token.

Assign the Reader Azure RBAC role to the application's identity at the financestorage level.

Enable the firewall bypass for trusted Microsoft services on the financestorage account.

Show answer & explanation

Answer: Create a stored access policy on the audits container.; Generate a service SAS for the audits container that references the stored access policy.

Answer

To meet the requirements, you must create a stored access policy on the container and generate a service SAS that references this policy.

To satisfy the requirements of immediate revocation without key rotation, a stored access policy must be used. Stored access policies are supported on service SAS tokens (which apply at the container level). By creating a stored access policy on the container and generating a service SAS that references it, you can revoke access at any time by simply deleting the policy or changing its expiration date. This avoids rotating the storage account keys.

Step-by-Step Solution

Define a stored access policy on the target container.

A policy is created that contains the permissions (read and list), start time, expiry time, and optional IP constraints.

Stored access policies provide group control over SAS tokens, enabling immediate revocation by changing the policy's expiration or deleting it entirely.

Generate a service SAS for the container.

A service SAS token is produced that links to the stored access policy.

A service SAS can delegate access to resources in a single container and can be associated with a stored access policy, unlike an account SAS which cannot.

Key Concept

Stored access policies provide the ability to revoke service SAS tokens immediately without rotating the storage account access keys.

Question 609Question →

You have an Azure subscription that contains the virtual networks shown in the following table:

Virtual Network	Address Space	Resources Deployed
`VNet-Hub`	$10.10.0.0/16$	`VPNGW1` (VPN Gateway), `NVA1` (Network Virtual Appliance at $10.10.1.4$ )
`VNet-Spoke1`	$10.20.0.0/16$	`VM1` (Virtual Machine at $10.20.1.4$ )
`VNet-Spoke2`	$10.30.0.0/16$	`VM2` (Virtual Machine at $10.30.1.4$ )

An on-premises network ( $192.168.1.0/24$ ) is connected to `VPNGW1` via a Site-to-Site VPN connection. IP forwarding is enabled on the network interface of `NVA1`.

You configure the following virtual network peering connections:
1. `Peering-Hub-Spoke1` between `VNet-Hub` and `VNet-Spoke1`
2. `Peering-Hub-Spoke2` between `VNet-Hub` and `VNet-Spoke2`

The peerings are currently configured with the following settings:
- On both peerings, the hub-side settings have 'Traffic forwarded from remote virtual network' set to Block, and 'Use this virtual network's gateway or Route Server' set to Block (disabled).
- On both peerings, the spoke-side settings have 'Traffic forwarded from remote virtual network' set to Block, and 'Use the remote virtual network's gateway or Route Server' set to Allow (enabled).

You associate route tables to the subnets in `VNet-Spoke1` and `VNet-Spoke2` to route traffic destined for the opposite spoke to `NVA1` ( $10.10.1.4$ ).

You need to ensure that:
1. `VM1` and `VM2` can communicate with each other through `NVA1`.
2. Both `VM1` and `VM2` can access the on-premises network through `VPNGW1`.

Which configuration changes should you perform?

Enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings, and enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings.

Create a direct virtual network peering between `VNet-Spoke1` and `VNet-Spoke2`, and configure both sides to allow gateway transit.

Enable 'Traffic forwarded from remote virtual network' on the hub-side peerings, and enable 'Use this virtual network's gateway or Route Server' on the spoke-side peerings.

Enable 'Traffic forwarded from remote virtual network' on both the hub-side and spoke-side peerings, and disable 'Use the remote virtual network's gateway or Route Server' on the spoke-side peerings.

Show answer & explanation

Answer: Enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings, and enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings.

Answer

Enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings, and enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings.

To satisfy both requirements, you must first enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings so that the spokes can transit traffic through the hub gateway to the on-premises network. Second, because traffic between the spokes is routed through the Network Virtual Appliance (NVA1) in the hub, the packets entering the spokes from the hub originate from the other spoke's IP space. This makes it forwarded traffic from the spokes' perspective. Thus, you must enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings so they do not drop these forwarded packets.

Step-by-Step Solution

Analyze the gateway transit configuration.

To allow the spokes to route on-premises traffic through the hub's VPN Gateway (VPNGW1), the hub-side peering must allow gateway transit (Use this virtual network's gateway or Route Server) and the spoke-side peering must use the remote gateway.

By default, virtual network gateway sharing is disabled on peerings.

Trace the spoke-to-spoke network path via the NVA.

Traffic from VM1 (

10.20.1.4

) to VM2 (

10.30.1.4

) is sent to NVA1 (

10.10.1.4

). NVA1 forwards the packet to VM2. For VNet-Spoke2, the incoming packet originates from the

10.20.0.0/16

address space, which is external to VNet-Hub.

Azure classifies packets delivered over a peering that originate outside the peered virtual network as forwarded traffic.

Determine the required forwarded traffic settings.

To prevent VM1's forwarded packets from being dropped when they enter VNet-Spoke2, the spoke-side peering on VNet-Spoke2 must allow forwarded traffic. The same applies to VNet-Spoke1 for the return traffic.

Peering links block forwarded traffic by default if the option is disabled, preventing transit routing via NVAs.

Key Concept

Configuring Virtual Network Peering settings for gateway transit and transit routing through a hub NVA.

Question 610Question →

An organization has a backend API hosted on an Azure App Service web app. You need to restrict inbound network access to the API so that it only accepts traffic originating from a virtual network subnet named Subnet1. Which configuration should you implement?

Configure regional virtual network integration on the App Service pointing to Subnet1.

Enable the Microsoft.Web service endpoint on Subnet1, and configure a virtual network access restriction rule on the App Service.

Associate a Network Security Group (NSG) containing an inbound security rule to the App Service.

Configure a virtual network peering link between the App Service and Subnet1.

Show answer & explanation

Answer: Enable the Microsoft.Web service endpoint on Subnet1, and configure a virtual network access restriction rule on the App Service.

Answer

Enable the Microsoft.Web service endpoint on Subnet1, and configure a virtual network access restriction rule on the App Service.

To restrict inbound traffic to an Azure App Service web app to a specific subnet, you must enable the Microsoft.Web service endpoint on that subnet. This allows the App Service to verify the source subnet of the incoming requests. You then configure a virtual network rule under the Access Restrictions settings of the App Service to permit traffic from that subnet. This blocks all other incoming public IP addresses and subnets.

Step-by-Step Solution

Enable the service endpoint on the subnet.

The Microsoft.Web service endpoint is enabled on Subnet1, allowing the subnet's traffic to be identified by Azure App Services.

This is a prerequisite to allow the App Service to configure rules based on this specific subnet.

Configure Access Restrictions on the web app.

An access restriction rule is added to the App Service's Networking configuration pointing to Subnet1.

This configuration permits inbound traffic from Subnet1 while implicitly blocking all other public traffic.

Key Concept

Configuring App Service inbound network security using access restrictions and service endpoints.

Estimated Time:1m 30s

Question 611Question →

An administrator of a Microsoft Entra ID tenant configures a Self-Service Password Reset (SSPR) policy. The policy requires two authentication methods for a password reset. The enabled authentication methods in the SSPR policy are:
- Mobile app notification
- Email
- Security questions

Three users in the tenant register the following authentication methods:
- Elena: Registers an email address and configures the Microsoft Authenticator app for notifications.
- David: Registers an email address and a mobile phone number.
- Chloe: Registers a mobile phone number and configures security questions.

Which user or users will be able to successfully perform a self-service password reset?

Elena, David, and Chloe

Elena and David only

Elena only

Elena and Chloe only

Show answer & explanation

Answer: Elena only

Answer

Only the user who registered an email address and configured the Microsoft Authenticator app for notifications is able to perform a password reset.

The SSPR policy requires two valid authentication methods and has enabled only email, mobile app notifications, and security questions. Only the user who registered an email address and configured the Microsoft Authenticator app for notifications has registered two valid methods under this policy.

Step-by-Step Solution

Determine the SSPR policy requirements.

The SSPR policy requires two authentication methods to reset a password, and the allowed methods are limited to Mobile app notification, Email, and Security questions.

This establishes the criteria that each user must satisfy to reset their password.

Evaluate the first user's registered methods against the policy.

The first user has registered an email and a mobile app for notifications. Both methods are enabled in the SSPR policy, giving her two valid methods.

This satisfies the policy requirement of two valid methods.

Evaluate the second and third users' registered methods against the policy.

The second user has only one valid method (email) and one invalid method (mobile phone). The third user has only one valid method (security questions) and one invalid method (mobile phone). Neither meets the requirement of two valid methods.

Mobile phone is not enabled in the tenant's SSPR policy, so it does not count toward the required two methods.

Key Concept

Microsoft Entra ID SSPR authentication method policy enforcement

Question 612Question →

You have an Azure Virtual Machine Scale Set named vmss-prod that has a manual upgrade policy. You need to configure the scale set to retrieve a secret from an Azure Key Vault named kv-prod. The configuration must use the principle of least privilege. Which sequence of actions should you perform? To answer, drag the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, enable a system-assigned managed identity on the scale set. Second, assign the Key Vault Secrets User role to the scale set's managed identity on the Key Vault. Third, add the Key Vault virtual machine extension to the scale set model. Finally, upgrade the existing instances of the scale set to apply the updated configuration.

The correct sequence starts with enabling the system-assigned managed identity on the Virtual Machine Scale Set to create the security principal. Next, permissions are granted by assigning the Key Vault Secrets User role to this identity on the Key Vault. Then, the Key Vault virtual machine extension is added to the scale set model to retrieve the secret. Finally, because the scale set uses a manual upgrade policy, the existing instances must be upgraded to apply the updated model containing the identity and extension.

Step-by-Step Solution

Enable the system-assigned managed identity on the Virtual Machine Scale Set.

An identity principal is created in Microsoft Entra ID representing the scale set.

You cannot assign RBAC roles to an identity until the system-assigned managed identity is enabled and registered in Entra ID.

Assign the Key Vault Secrets User role to the managed identity on the Key Vault.

The identity principal is authorized to retrieve secrets from the Key Vault.

This grants the minimum required permission (least privilege) for the VM instances to retrieve the secret.

Add the Key Vault virtual machine extension to the scale set configuration model.

The model template is updated to include the extension, referencing the Key Vault.

The extension orchestrates the retrieval and management of the secret on the virtual machines.

Select the existing VMSS instances and trigger an upgrade.

The instances are updated to the latest model configuration.

Because the scale set's upgrade policy is set to Manual, existing instances do not automatically pull model changes. An explicit upgrade action is required.

Key Concept

Configuring Virtual Machine Scale Sets with Managed Identities, Extensions, and Manual Upgrade Policies.

Estimated Time:2m 0s

Question 613Question →

An organization implements an Azure virtual network named `VNet-Production` ( $10.50.0.0/16$ ). The virtual network contains four subnets:
- `FrontEndSubnet` ( $10.50.1.0/24$ )
- `BackEndSubnet` ( $10.50.2.0/24$ )
- `SecuritySubnet` ( $10.50.3.0/24$ )
- `GatewaySubnet` ( $10.50.0.0/24$ ) which contains a Virtual Network Gateway configured with BGP to propagate routes for an on-premises network ( $172.30.0.0/16$ ).

A virtual machine named `NVA1` is deployed in `SecuritySubnet` and has the private IP address $10.50.3.10$ .

You need to implement custom routing to meet the following requirements:
- All outbound traffic from `FrontEndSubnet` to the internet must be routed through `NVA1`.
- All traffic from `FrontEndSubnet` to `BackEndSubnet` must be routed through `NVA1`.
- Traffic from `FrontEndSubnet` to the on-premises network ( $172.30.0.0/16$ ) must bypass `NVA1` and route directly through the Virtual Network Gateway.

Which two actions should you perform to implement this routing configuration? (Select two.)

Select all that apply

Enable IP forwarding on the Azure network interface associated with `NVA1`.

Create a route table containing a route for

10.50.2.0/24

with the next hop type Virtual appliance pointing to

10.50.3.10

, and a route for

0.0.0.0/0

with the next hop type Virtual appliance pointing to

10.50.3.10

. Associate this route table with `FrontEndSubnet`.

Create a route table containing a route for

10.50.2.0/24

with the next hop type Virtual network gateway pointing to

10.50.3.10

, and a route for

0.0.0.0/0

with the next hop type Virtual network gateway pointing to

10.50.3.10

. Associate this route table with `FrontEndSubnet`.

Create a route table containing a route for

10.50.2.0/24

with the next hop type Virtual appliance pointing to

10.50.3.10

. Associate this route table with `SecuritySubnet` and `BackEndSubnet`.

Show answer & explanation

Answer: Enable IP forwarding on the Azure network interface associated with `NVA1`.; Create a route table containing a route for $10.50.2.0/24$ with the next hop type Virtual appliance pointing to $10.50.3.10$ , and a route for $0.0.0.0/0$ with the next hop type Virtual appliance pointing to $10.50.3.10$ . Associate this route table with `FrontEndSubnet`.

Answer

To implement this routing design, you must enable IP forwarding on the Azure network interface associated with the network virtual appliance, and associate a route table to the frontend subnet that routes the backend subnet and default route traffic to the network virtual appliance's IP address.

The correct implementation requires two configurations. First, enabling IP forwarding on the Azure network interface associated with the network virtual appliance is mandatory so that Azure does not drop transit traffic. Second, creating a route table and associating it with the frontend subnet ensures that traffic to the backend subnet and the internet is redirected to the virtual appliance's IP address. By using a default route for the internet traffic, on-premises traffic propagated via BGP is preserved and bypasses the appliance because its prefix length is more specific than the default route, adhering to Longest Prefix Match rules.

Step-by-Step Solution

Enable IP forwarding on the network virtual appliance.

IP forwarding is enabled on the Azure network interface associated with the virtual machine.

By default, Azure VMs discard packets where the destination IP does not match the VM's assigned IP. Enabling IP forwarding allows the virtual machine's interface to forward transit traffic.

Configure the User-Defined Routes (UDR) for traffic direction.

A route table is defined with a specific route for the backend subnet prefix and a default route for all other traffic, both pointing to the virtual appliance's IP address.

The user-defined route for the backend prefix overrides the local VNet default route. The default route (0.0.0.0/0) redirects all internet traffic through the appliance.

Leverage Longest Prefix Match (LPM) rules for the on-premises bypass.

On-premises routes propagated via BGP are evaluated, and traffic to the on-premises prefix uses the BGP route instead of the default route.

Azure route selection evaluates the longest prefix match. A BGP-learned route (e.g., 172.30.0.0/16) is a longer prefix match than the default route (0.0.0.0/0). Therefore, traffic destined for the on-premises network is routed directly to the Virtual Network Gateway without needing an explicit UDR bypass route.

Associate the route table with the source subnet.

The route table is associated with the frontend subnet.

UDRs only affect traffic originating from the subnets with which the route table is associated.

Key Concept

Azure Route Selection Precedence, Longest Prefix Match (LPM), and NVA Integration

Question 614Question →

An administrator is designing a virtual network named `vnet-prod` in an Azure subscription. The virtual network is assigned the address space $10.100.0.0/22$ . The administrator needs to configure subnets to support the following requirements:

* A subnet named `subnet-app` to host at least $27$ virtual machines.
* A subnet named `AzureBastionSubnet` to enable secure administrative access.
* A subnet named `GatewaySubnet` to support a VPN gateway.

The administrator proposes the following subnet allocations:

* `subnet-app`: $10.100.0.0/27$
* `AzureBastionSubnet`: $10.100.0.32/27$
* `GatewaySubnet`: $10.100.0.64/29$

Which subnet in the proposed configuration will cause a deployment or configuration failure due to Azure subnet size constraints?

AzureBastionSubnet only

subnet-app only

GatewaySubnet only

All subnets are valid because they meet host count requirements and do not overlap.

Show answer & explanation

Answer: AzureBastionSubnet only

Answer

AzureBastionSubnet only

The subnet named AzureBastionSubnet is assigned the CIDR block

10.100.0.32/27

. The Azure Bastion service requires its subnet to be named exactly AzureBastionSubnet and to have a prefix size of

/26

or larger (e.g.,

/26

/25

/24

). A

/27

subnet is too small, which will cause the deployment of the Azure Bastion host to fail. The subnet-app is valid because a

/27

subnet offers

32

IPs, and subtracting the

5

reserved IPs leaves exactly

27

usable IPs for the virtual machines. The GatewaySubnet is valid because Azure supports a GatewaySubnet prefix size as small as

/29

Step-by-Step Solution

Analyze the capacity and sizing for `subnet-app`.

The proposed subnet size is

/27

, which provides

2^5 = 32

total IP addresses. Since Azure reserves

5

IP addresses per subnet, the usable IPs equal

32 - 5 = 27

. This matches the requirement to host at least

27

virtual machines, so this subnet configuration is valid.

To verify if the proposed address block satisfies the required host count when accounting for Azure's reserved IP addresses.

Evaluate the platform size constraint for `AzureBastionSubnet`.

Azure Bastion has a strict requirement that its dedicated subnet (`AzureBastionSubnet`) must be configured with a prefix of

/26

or larger. The proposed allocation of

10.100.0.32/27

uses a

/27

prefix, which is invalid.

To check if the subnet size meets the minimum supported prefix size mandated by the Azure Bastion service.

Evaluate the platform size constraint for `GatewaySubnet`.

Azure virtual network gateways support a minimum subnet size of

/29

(or larger, such as

/28

/27

). The proposed allocation of

10.100.0.64/29

uses a

/29

prefix, which is technically valid.

To determine if the gateway subnet configuration meets Azure virtual network gateway specifications.

Key Concept

Azure subnets reserve

5

IP addresses for internal management (the first four and the last one). Additionally, certain Azure resources require dedicated subnets with minimum size constraints. For example, Azure Bastion requires a subnet named exactly `AzureBastionSubnet` with a minimum prefix size of

/26

, whereas a `GatewaySubnet` requires a minimum prefix size of

/29

Estimated Time:1m 30s

Question 615Question →

An administrator is configuring security rules for an Azure virtual network named `VNet1`. The virtual network contains two subnets: `Subnet-Web` ( $10.10.1.0/24$ ) and `Subnet-Data` ( $10.10.2.0/24$ ).

The environment contains the following resources:
- `VM-Web1`: Located in `Subnet-Web` and associated with the Application Security Group `ASG-Web`.
- `VM-Data1`: Located in `Subnet-Data` and associated with the Application Security Group `ASG-Data`.
- `NSG-SubnetWeb`: A Network Security Group associated with `Subnet-Web`.
- `NSG-SubnetData`: A Network Security Group associated with `Subnet-Data`.
- `NSG-NicData`: A Network Security Group associated with the network interface of `VM-Data1`.

Currently, database traffic on TCP port $1433$ from `VM-Web1` to `VM-Data1` is blocked. The security groups contain the custom rules shown in the following tables:

NSG-SubnetWeb (Outbound Rules)

Priority	Source	Destination	Port	Protocol	Action
500	`ASG-Web`	`ASG-Data`	Any	Any	Deny

NSG-SubnetData (Inbound Rules)

Priority	Source	Destination	Port	Protocol	Action
600	`10.10.1.0/24`	`ASG-Data`	1433	TCP	Deny

NSG-NicData (Inbound Rules)
- Only default rules are active.

You need to allow SQL Server database traffic on TCP port $1433$ from `VM-Web1` to `VM-Data1` while maintaining the principle of least privilege.

Which two configuration changes should you perform?

Select all that apply

Add an outbound rule to `NSG-SubnetWeb` with a priority of 400 that allows outbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

Add an inbound rule to `NSG-SubnetData` with a priority of 500 that allows inbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

Add an outbound rule to `NSG-SubnetWeb` with a priority of 600 that allows outbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

Add an inbound rule to `NSG-SubnetData` with a priority of 700 that allows inbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

Add an inbound rule to `NSG-NicData` with a priority of 400 that allows inbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

Show answer & explanation

Answer: Add an outbound rule to `NSG-SubnetWeb` with a priority of 400 that allows outbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.; Add an inbound rule to `NSG-SubnetData` with a priority of 500 that allows inbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

Answer

Add an outbound rule to `NSG-SubnetWeb` with a priority of 400 that allows outbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`, and add an inbound rule to `NSG-SubnetData` with a priority of 500 that allows inbound TCP traffic on port 1433 from `ASG-Web` to `ASG-Data`.

To allow SQL Server traffic from the Web subnet to the Data subnet, rules must permit the traffic both outbound at the source and inbound at the destination. The custom outbound rule at priority 500 in the subnet NSG of the source blocks all traffic to the target ASG, requiring a custom allow rule with a priority number less than 500 (such as 400). Similarly, the custom inbound rule at priority 600 in the subnet NSG of the destination blocks TCP port 1433 traffic from the source subnet, requiring a custom allow rule with a priority number less than 600 (such as 500). No configuration changes are needed at the destination NIC level because the default AllowVnetInbound rule (priority 65000) already allows traffic from within the VNet.

Step-by-Step Solution

Evaluate the outbound path from VM-Web1

Outbound traffic from VM-Web1 must pass through the subnet-level NSG (NSG-SubnetWeb). Currently, NSG-SubnetWeb contains Rule 500, which denies all traffic from ASG-Web to ASG-Data. To allow SQL Server traffic, we must create a custom outbound rule with a priority value less than 500 (such as priority 400).

Lower priority numbers represent higher evaluation precedence in Azure Network Security Groups.

Evaluate the inbound path to VM-Data1 at the subnet level

Inbound traffic must pass through the subnet-level NSG (NSG-SubnetData). NSG-SubnetData currently contains Rule 600, which denies TCP 1433 traffic from the Web subnet (10.10.1.0/24) to ASG-Data. To allow the SQL Server traffic, we must create a custom inbound rule in NSG-SubnetData with a priority value less than 600 (such as priority 500).

Traffic must pass through the subnet-level NSG before it reaches the network interface (NIC) level NSG.

Evaluate the inbound path to VM-Data1 at the NIC level

Inbound traffic must also pass through the NIC-level NSG (NSG-NicData). Since NSG-NicData has only default rules, the default rule AllowVnetInbound (priority 65000) permits VNet-internal traffic. Because VM-Web1 and VM-Data1 are within the same virtual network, the default rule allows the traffic at this stage.

No additional custom rules are required on NSG-NicData because the default inbound rules do not block this internal VNet traffic.

Key Concept

Azure Network Security Group rules are processed sequentially in priority order (lower numbers having higher precedence). For cross-subnet traffic, outbound rules are evaluated first at the NIC and then the subnet of the source, followed by inbound rules evaluated first at the subnet and then the NIC of the destination. Default rules apply if no custom rules match, and Application Security Groups can be used to define security policies across subnet boundaries.

Question 616Question →

An administrator is planning the deployment of a new Azure virtual machine named VM-Prod1 in the West US 3 region. The deployment must meet the following requirements:
- Ensure the virtual machine is protected against datacenter-wide outages within the region.
- Back up VM-Prod1 to an existing Recovery Services vault named Vault1, which is located in the West US 3 region.

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

Select all that apply

Deploy VM-Prod1 to a specific Availability Zone in the West US 3 region.

Associate VM-Prod1 with Vault1 to configure the backup.

Deploy VM-Prod1 to a new Availability Set.

Create a new Recovery Services vault in the East US region and associate it with VM-Prod1.

Show answer & explanation

Answer: Deploy VM-Prod1 to a specific Availability Zone in the West US 3 region.; Associate VM-Prod1 with Vault1 to configure the backup.

Answer

Deploy the virtual machine in an Availability Zone and associate it with the existing Recovery Services vault in the same region.

To protect against datacenter-wide outages, virtual machines must be deployed across Availability Zones. Additionally, because the existing Recovery Services vault is in the same region as the virtual machine (West US 3), the virtual machine can be backed up directly using this vault.

Step-by-Step Solution

Evaluate the resiliency requirement to determine the appropriate availability option.

Availability Zones provide protection against datacenter-wide outages by utilizing physically separate datacenters, whereas Availability Sets only protect against localized hardware failures within a single datacenter.

To satisfy the requirement of protecting the virtual machine from datacenter-wide outages.

Evaluate the backup requirement and identify region constraints.

The existing vault is in West US 3, which matches the virtual machine's region. Azure Backup requires the vault and the virtual machine to be in the same region.

To satisfy the backup requirement without creating unnecessary resources or violating region restrictions.

Key Concept

Virtual machine availability options and region constraints for Recovery Services vault backups

Question 617Question →

You have an Azure virtual network named `VNet1` that contains three subnets named `Subnet-Public` ( $10.0.1.0/24$ ), `Subnet-Secure` ( $10.0.2.0/24$ ), and `Subnet-DMZ` ( $10.0.3.0/24$ ). A Network Virtual Appliance (NVA) is deployed in `Subnet-DMZ` and is assigned the private IP address $10.0.3.4$ . You need to create a user-defined route in a route table associated with `Subnet-Secure` to direct all outbound internet traffic from `Subnet-Secure` through the NVA. Which next hop type and next hop IP address should you configure in the route table to meet this requirement?

Next hop type: Virtual appliance; Next hop IP address:

10.0.3.4

Next hop type: Virtual network gateway; Next hop IP address:

10.0.3.4

Next hop type: Virtual appliance; Next hop IP address:

10.0.2.4

Next hop type: Virtual network; Next hop IP address:

10.0.3.4

Show answer & explanation

Answer: Next hop type: Virtual appliance; Next hop IP address: $10.0.3.4$

Answer

Next hop type: Virtual appliance; Next hop IP address:

10.0.3.4

To route traffic to an NVA, you must configure a route with the next hop type of 'Virtual appliance' and the next hop IP address set to the NVA's private IP (

10.0.3.4

Step-by-Step Solution

Determine the routing target and destination.

The destination is the internet (

0.0.0.0/0

), and the traffic must be directed to a Network Virtual Appliance (NVA) at

10.0.3.4

Identifying the flow destination and gateway IP is necessary for constructing the user-defined route.

Identify the correct Next Hop Type for an NVA.

The Next Hop Type must be set to 'Virtual appliance'.

Azure routing uses 'Virtual appliance' to identify virtual machines or firewalls configured to route traffic.

Select the correct Next Hop IP address.

The Next Hop IP address must be the private IP address of the NVA interface in Subnet-DMZ (

10.0.3.4

The next hop IP must be a reachable address on a local subnet within the VNet.

Key Concept

Azure User-Defined Routes Next Hop Types

Question 618Question →

Your company has a hub-and-spoke network topology in Azure consisting of three virtual networks: `Hub-VNet` ( $10.10.0.0/16$ ), `Spoke-VNet1` ( $10.20.0.0/16$ ), and `Spoke-VNet2` ( $10.30.0.0/16$ ). Virtual machines are deployed in subnets within all three virtual networks to establish data plane connectivity.

You configure virtual network peering between `Hub-VNet` and `Spoke-VNet1`, and between `Hub-VNet` and `Spoke-VNet2`. No virtual network gateways or virtual appliances are deployed.

Which configuration is required to allow virtual machines in `Spoke-VNet1` to communicate directly with virtual machines in `Spoke-VNet2` over the Azure backbone network?

Enable 'Allow gateway transit' on the peering from `Hub-VNet` to both spokes.

Configure a direct virtual network peering between `Spoke-VNet1` and `Spoke-VNet2`.

Enable 'Use remote gateways' on the peering from the spokes to `Hub-VNet`.

Enable 'Allow forwarded traffic' on all peerings to automatically route traffic between the spokes.

Show answer & explanation

Answer: Configure a direct virtual network peering between `Spoke-VNet1` and `Spoke-VNet2`.

Answer

Configure a direct virtual network peering between `Spoke-VNet1` and `Spoke-VNet2`.

The correct answer is configuring a direct virtual network peering between the two spokes. Since Azure virtual network peering is non-transitive, traffic cannot flow from one spoke to another through a hub VNet without a transit routing mechanism such as a Network Virtual Appliance (NVA) and User-Defined Routes (UDRs). Peerings must be established directly between the communicating virtual networks to allow direct communication over the Azure backbone network.

Step-by-Step Solution

Analyze the existing network topology and peering configuration.

Two spokes (`Spoke-VNet1` and `Spoke-VNet2`) are peered with `Hub-VNet`, but not directly with each other.

To determine how traffic flows between virtual networks.

Apply the rule of virtual network peering transitivity.

Since Azure virtual network peering is non-transitive by default, traffic cannot transit from `Spoke-VNet1` through `Hub-VNet` to reach `Spoke-VNet2`.

To identify why the current configuration does not allow communication between the spokes.

Select the correct solution to establish direct connectivity.

Creating a direct peering connection between `Spoke-VNet1` and `Spoke-VNet2` bypasses the non-transitive limitation.

Direct peering enables direct VM-to-VM communication over the Azure backbone without routing through the hub.

Key Concept

Azure virtual network peering is non-transitive. To route traffic between two spokes in a hub-and-spoke topology without deploying a network virtual appliance in the hub, a direct virtual network peering link must be established between the two spokes.

Question 619Question →

You have an Azure subscription that contains a Standard Load Balancer named LB1 and two virtual machines named VM1 and VM2. VM1 and VM2 are deployed in the same virtual network. The network interfaces of VM1 and VM2 are currently associated with Basic SKU public IP addresses.

You need to add VM1 and VM2 to the backend pool of LB1. The virtual machines must remain accessible from the internet via public IP addresses.

Which two actions should you perform?

Select all that apply

Disassociate the Basic SKU public IP addresses from the network interfaces of VM1 and VM2.

Create and associate Standard SKU public IP addresses with the network interfaces of VM1 and VM2.

Change the allocation method of the existing Basic SKU public IP addresses to Static.

Configure the frontend IP configuration of LB1 to use a Basic SKU public IP address.

Show answer & explanation

Answer: Disassociate the Basic SKU public IP addresses from the network interfaces of VM1 and VM2.; Create and associate Standard SKU public IP addresses with the network interfaces of VM1 and VM2.

Answer

To add the virtual machines to the backend pool of a Standard Load Balancer while maintaining public IP connectivity, you must disassociate the Basic SKU public IP addresses from the network interfaces of VM1 and VM2, and then create and associate Standard SKU public IP addresses with those network interfaces.

A Standard Load Balancer requires that all resources in its backend pool match the Standard SKU. If virtual machines in the backend pool are configured with public IP addresses, those public IP addresses must be Standard SKU public IP addresses. Therefore, to resolve the SKU mismatch, the administrator must disassociate the existing Basic SKU public IP addresses from the network interfaces of the virtual machines and replace them with Standard SKU public IP addresses.

Step-by-Step Solution

Identify SKU requirements for the Standard Load Balancer backend pool.

Determine that all virtual machines in the backend pool of a Standard Load Balancer must either have no public IP addresses or must use Standard SKU public IP addresses.

Azure enforces SKU boundary consistency, meaning Basic SKU resources and Standard SKU resources cannot be mixed within the backend pool configuration of a Standard Load Balancer.

Disassociate the incompatible public IP addresses.

Disassociate the Basic SKU public IP addresses from the network interfaces of VM1 and VM2.

This removes the incompatible Basic SKU public IPs so that the virtual machines can be successfully associated with the Standard Load Balancer backend pool.

Provision and assign compatible public IP addresses.

Create new Standard SKU public IP addresses and associate them with the primary IP configurations of the network interfaces of VM1 and VM2.

This restores public internet access to the virtual machines using public IP addresses that are compatible with the Standard Load Balancer backend pool.

Key Concept

Azure Public IP SKU compatibility with Standard Load Balancer backend pools

Question 620Question →

An organization deploys three Azure virtual networks in the East US region: `VNet-Alpha` ( $172.16.0.0/16$ ), `VNet-Beta` ( $172.17.0.0/16$ ), and `VNet-Gamma` ( $172.18.0.0/16$ ). Virtual machines are running within the subnets of each virtual network.

You establish a virtual network peering link between `VNet-Alpha` and `VNet-Beta`. Next, you establish a virtual network peering link between `VNet-Beta` and `VNet-Gamma`.

The peering configurations have 'Allow forwarded traffic' enabled, and 'Use remote gateways' and 'Allow gateway transit' are disabled. There are no virtual network gateways or network virtual appliances in any of the virtual networks.

What is the resulting connectivity between the virtual machines in `VNet-Alpha` and the virtual machines in `VNet-Gamma`?

The virtual machines can communicate directly because virtual network peering is transitive when 'Allow forwarded traffic' is enabled.

The virtual machines cannot communicate because virtual network peering is non-transitive, and there is no gateway or network virtual appliance to route traffic between them.

The virtual machines can communicate only if 'Allow gateway transit' is enabled on both peering links, which automatically routes traffic through the transit network.

The virtual machines can communicate because 'Allow forwarded traffic' is enabled, which automatically routes transit traffic through the intermediate virtual network.

Show answer & explanation

Answer: The virtual machines cannot communicate because virtual network peering is non-transitive, and there is no gateway or network virtual appliance to route traffic between them.

Answer

The virtual machines cannot communicate because virtual network peering is non-transitive, and there is no gateway or network virtual appliance to route traffic between them.

The correct answer is correct because Azure virtual network peering is non-transitive. Peering VNet-Alpha to VNet-Beta and VNet-Beta to VNet-Gamma does not allow resources in VNet-Alpha to reach VNet-Gamma. For transit routing to occur, a gateway or a network virtual appliance (NVA) must be present in VNet-Beta, and the peering settings must be configured to allow gateway transit or transit routing.

Step-by-Step Solution

Analyze the topology and peering configuration between the virtual networks.

VNet-Alpha is peered with VNet-Beta, and VNet-Beta is peered with VNet-Gamma, creating a linear chain.

To determine connectivity, the relationships between all networks must be mapped.

Check the transitivity of Azure virtual network peering.

Azure virtual network peering is non-transitive by default.

Traffic does not flow automatically from one peered network through a middle network to reach a third network.

Verify if any transit mechanisms are deployed to enable routing.

There are no virtual network gateways or network virtual appliances (NVAs) configured to route transit traffic.

Without these transit mechanisms, communication between the non-peered networks at the ends of the chain is impossible.

Key Concept

Virtual network peering in Azure is non-transitive. To route traffic through an intermediate virtual network, you must use a virtual network gateway or a network virtual appliance (NVA) along with user-defined routing.

Estimated Time:1m 0s

PreviousPage 31 / 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