All practice questions

1252 questions

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

A company deploys two virtual machines in the same subnet of an Azure virtual network. The network interface of the first virtual machine, named `VM-App`, is associated with an Application Security Group named `ASG-App`. The network interface of the second virtual machine, named `VM-Data`, is associated with an Application Security Group named `ASG-Data`. The subnet is associated with a Network Security Group named `NSG-Subnet` that contains the following inbound security rules:

* Rule1: Priority $150$ , Source: `ASG-App`, Destination: `ASG-Data`, Port: $1433$ , Protocol: TCP, Action: Allow
* Rule2: Priority $200$ , Source: `*`, Destination: `ASG-Data`, Port: $1433$ , Protocol: TCP, Action: Deny

A network interface-level Network Security Group named `NSG-NIC` is associated with the network interface of `VM-Data` and contains the following inbound security rules:

* Rule3: Priority $120$ , Source: `ASG-App`, Destination: `*`, Port: $1433$ , Protocol: TCP, Action: Allow
* Rule4: Priority $220$ , Source: `*`, Destination: `*`, Port: $1433$ , Protocol: TCP, Action: Deny

Which two of the following statements are correct? (Select two.)

Select all that apply

Inbound TCP port

1433

traffic from `VM-App` to `VM-Data` is allowed because both the subnet-level and network interface-level Network Security Groups permit the connection.

Modifying the priority of Rule2 in `NSG-Subnet` to

100

will block the inbound TCP port

1433

traffic from `VM-App` to `VM-Data`.

Changing the priority of Rule1 in `NSG-Subnet` to

250

will guarantee that traffic from `VM-App` to `VM-Data` takes precedence and is allowed.

Inbound TCP port

1433

traffic from `VM-App` to `VM-Data` is blocked because Rule2 in `NSG-Subnet` has a higher priority number (

200

) than Rule1 (

150

Show answer & explanation

Answer: Inbound TCP port $1433$ traffic from `VM-App` to `VM-Data` is allowed because both the subnet-level and network interface-level Network Security Groups permit the connection.; Modifying the priority of Rule2 in `NSG-Subnet` to $100$ will block the inbound TCP port $1433$ traffic from `VM-App` to `VM-Data`.

Answer

Inbound TCP port

1433

traffic from VM-App to VM-Data is allowed because both the subnet-level and network interface-level Network Security Groups permit the connection, and modifying the priority of Rule2 in NSG-Subnet to

100

will block the inbound TCP port

1433

traffic from VM-App to VM-Data.

Inbound traffic to an Azure VM network interface is evaluated first by the NSG associated with the subnet, and then by the NSG associated with the network interface. In both NSGs, rules are processed in priority order where lower numbers have higher precedence. The option stating that inbound TCP port

1433

traffic from VM-App to VM-Data is allowed because both levels permit the connection is correct because Rule1 (

150

) beats Rule2 (

200

) in NSG-Subnet, and Rule3 (

120

) beats Rule4 (

220

) in NSG-NIC. The option stating that modifying the priority of Rule2 to

100

blocks the traffic is correct because it gives the Deny rule higher precedence than the Allow rule (

150

Step-by-Step Solution

Evaluate the traffic against NSG-Subnet (subnet-level NSG) rules.

Rule1 (Allow) has a priority of

150

and Rule2 (Deny) has a priority of

200

. Since

150 < 200

, Rule1 has higher precedence. The traffic matches Rule1 and is allowed at the subnet level.

Azure processes inbound security rules in order of priority from lowest numerical value to highest.

Evaluate the traffic against NSG-NIC (NIC-level NSG) rules.

Rule3 (Allow) has a priority of

120

and Rule4 (Deny) has a priority of

220

. Since

120 < 220

, Rule3 has higher precedence. The traffic matches Rule3 and is allowed at the network interface level.

Inbound traffic must clear both the subnet-level NSG and the NIC-level NSG to be allowed.

Determine the impact of changing the priority of Rule2 (Deny) in NSG-Subnet to

100

With a priority of

100

, Rule2 is evaluated before Rule1 (priority

150

). Since Rule2 is a Deny rule, the traffic will be blocked at the subnet layer.

Lower priority numbers represent higher processing precedence.

Key Concept

Azure Network Security Group inbound rules are evaluated sequentially based on priority numbers (lower numbers represent higher precedence). For inbound traffic, the subnet-level NSG is evaluated first, followed by the network interface-level NSG. Traffic must be allowed by both NSGs to reach the destination.

Question 702Question →

You have an Azure virtual network named `VNet1` that contains a subnet named `Subnet1`. A virtual machine named `VM1` is deployed to `Subnet1`. The network interface (NIC) of `VM1` is associated with a Network Security Group (NSG) named `NSG-NIC`. `Subnet1` is associated with an NSG named `NSG-Subnet`.

`NSG-Subnet` contains the following inbound security rule:

Rule Name	Priority	Source	Destination	Port	Action
Deny-Internet	$150$	Internet	Any	*	Deny

`NSG-NIC` contains the following inbound security rule:

Rule Name	Priority	Source	Destination	Port	Action
Deny-All-Internet	$200$	Internet	Any	*	Deny

You need to allow HTTP traffic (port $80$ ) from the Internet to `VM1`.

Which two rules should you add? (Choose two.)

Select all that apply

A rule in `NSG-Subnet` with a priority of

100

that allows inbound traffic from the Internet to any destination on port

80

A rule in `NSG-NIC` with a priority of

100

that allows inbound traffic from the Internet to any destination on port

80

A rule in `NSG-Subnet` with a priority of

200

that allows inbound traffic from the Internet to any destination on port

80

A rule in `NSG-NIC` with a priority of

300

that allows inbound traffic from the Internet to any destination on port

80

A rule in `NSG-Subnet` with a priority of

100

that allows outbound traffic to the Internet on port

80

Show answer & explanation

Answer: A rule in `NSG-Subnet` with a priority of $100$ that allows inbound traffic from the Internet to any destination on port $80$ .; A rule in `NSG-NIC` with a priority of $100$ that allows inbound traffic from the Internet to any destination on port $80$ .

Answer

Configure a rule in NSG-Subnet with a priority of 100 that allows inbound traffic from the Internet to any destination on port 80, and configure a rule in NSG-NIC with a priority of 100 that allows inbound traffic from the Internet to any destination on port 80.

Inbound traffic from the Internet destined for a virtual machine is evaluated sequentially by the subnet-level NSG first, and then by the NIC-level NSG. Since both NSG-Subnet and NSG-NIC contain explicit rules that deny all inbound Internet traffic, an allow rule must be added to both NSGs. In Azure NSGs, rules with lower priority numbers are processed first. Therefore, the rule in NSG-Subnet must have a priority lower than 150 (such as 100), and the rule in NSG-NIC must have a priority lower than 200 (such as 100) to override the existing deny rules.

Step-by-Step Solution

Analyze the evaluation order of Network Security Groups for inbound traffic to virtual machines.

Inbound traffic from the Internet must first pass through the subnet-level NSG (NSG-Subnet) and then through the NIC-level NSG (NSG-NIC). Traffic must be allowed at both levels.

Azure evaluates inbound traffic against subnet-associated NSGs first, and then against NIC-associated NSGs. If either NSG blocks the traffic, it will not reach the destination VM.

Evaluate the priority requirements for NSG-Subnet.

An inbound rule with a priority value lower than 150 (such as 100) must be created to allow port 80 traffic.

NSG-Subnet has an existing inbound rule that denies all Internet traffic at priority 150. Since lower priority numbers represent higher precedence, any allow rule must have a priority number lower than 150.

Evaluate the priority requirements for NSG-NIC.

An inbound rule with a priority value lower than 200 (such as 100) must be created to allow port 80 traffic.

NSG-NIC has an existing inbound rule that denies all Internet traffic at priority 200. The allow rule must have a priority number lower than 200 to override this deny behavior.

Key Concept

Azure Network Security Group dual-level evaluation and rule priority mechanics.

Question 703Question →

An administrator is configuring a peering connection from a hub virtual network named VNet-Hub ( $10.1.0.0/16$ ) to a spoke virtual network named VNet-Spoke ( $10.2.0.0/16$ ). Both virtual networks have virtual machines deployed in their subnets. VNet-Hub contains a virtual network gateway. The administrator wants virtual machines in VNet-Spoke to be able to use the virtual network gateway in VNet-Hub to access on-premises resources. Which two actions must the administrator perform to configure this gateway transit functionality?

Select all that apply

On the peering from VNet-Hub to VNet-Spoke, select 'Allow gateway transit'

On the peering from VNet-Spoke to VNet-Hub, select 'Use remote gateways'

On the peering from VNet-Spoke to VNet-Hub, select 'Allow gateway transit'

On the peering from VNet-Hub to VNet-Spoke, select 'Use remote gateways'

Show answer & explanation

Answer: On the peering from VNet-Hub to VNet-Spoke, select 'Allow gateway transit'; On the peering from VNet-Spoke to VNet-Hub, select 'Use remote gateways'

Answer

Enable 'Allow gateway transit' on the peering connection from VNet-Hub to VNet-Spoke, and enable 'Use remote gateways' on the peering connection from VNet-Spoke to VNet-Hub.

To establish gateway transit, the configuration must be set correctly on both sides of the peering connection. The peering link from the virtual network containing the gateway (the hub) must have 'Allow gateway transit' enabled. The peering link from the virtual network that wants to use the gateway (the spoke) must have 'Use remote gateways' enabled.

Step-by-Step Solution

Configure the hub-side peering link (VNet-Hub to VNet-Spoke).

Enable 'Allow gateway transit' so the hub permits peered virtual networks to use its gateway.

This allows the gateway in the hub virtual network to transit traffic for peered networks.

Configure the spoke-side peering link (VNet-Spoke to VNet-Hub).

Enable 'Use remote gateways' so the spoke routes its gateway-bound traffic through the peered hub gateway.

This configures the spoke virtual network to utilize the gateway hosted in the peered hub network.

Key Concept

Gateway transit in virtual network peering allows a spoke virtual network to share the virtual network gateway of a peered hub virtual network.

Question 704Question →

An administrator creates an Azure Private DNS zone named private.contoso.com. The administrator configures a virtual network link from private.contoso.com to a virtual network named VNet1 with auto-registration enabled. The administrator then configures a second virtual network link from private.contoso.com to a virtual network named VNet2 with auto-registration disabled. How does this configuration affect the name resolution and registration of the virtual machines deployed in VNet2?

They can resolve DNS records in private.contoso.com, but their own hostnames are not automatically registered.

They cannot resolve DNS records in private.contoso.com, and their own hostnames are not automatically registered.

They cannot resolve DNS records in private.contoso.com, but their own hostnames are automatically registered.

They can resolve DNS records in private.contoso.com only if virtual network peering is established between VNet1 and VNet2.

Show answer & explanation

Answer: They can resolve DNS records in private.contoso.com, but their own hostnames are not automatically registered.

Answer

Virtual machines in the second virtual network can resolve DNS records in the private DNS zone, but their own hostnames will not be automatically registered.

Linking a virtual network to a Private DNS Zone enables name resolution for virtual machines in that virtual network. Auto-registration is an optional setting that allows Azure DNS to dynamically create and update A records for virtual machines in the linked virtual network. Since the link for the second virtual network does not have auto-registration enabled, its virtual machines can resolve existing records but will not have their hostnames registered automatically.

Step-by-Step Solution

Determine the impact of the virtual network link on name resolution.

Virtual machines in VNet2 can resolve records present in the private DNS zone.

Creating a virtual network link enables resources within that virtual network to query and resolve names in the linked Private DNS Zone.

Analyze the impact of disabling the auto-registration option on the link.

Hostnames of virtual machines in VNet2 are not automatically registered in the DNS zone.

Auto-registration is an optional capability of the virtual network link that must be explicitly enabled to allow automatic creation of DNS records for VM private IPs.

Combine the resolution and registration behaviors to find the correct answer.

Resolution works; registration does not.

Name resolution is active because the VNet is linked, but registration is inactive because the auto-registration checkbox is cleared.

Key Concept

Azure Private DNS Zone virtual network links and the role of the auto-registration feature.

Question 705Question →

You are configuring a public load balancer in Azure to distribute incoming internet traffic across two virtual machines. You have already created a Standard SKU public IP address to be used for the frontend.

Which of the following configuration options are compatible with this setup? (Select two.)

Select all that apply

Create a Standard SKU load balancer and associate the existing Standard SKU public IP address with its frontend.

Add virtual machines deployed in different Availability Zones to the backend pool of the Standard SKU load balancer.

Create a Basic SKU load balancer and associate the existing Standard SKU public IP address with its frontend.

Add virtual machines configured with Basic SKU public IP addresses on their network interfaces to the backend pool of the Standard SKU load balancer.

Show answer & explanation

Answer: Create a Standard SKU load balancer and associate the existing Standard SKU public IP address with its frontend.; Add virtual machines deployed in different Availability Zones to the backend pool of the Standard SKU load balancer.

Answer

To configure a compatible architecture, you must create a Standard SKU load balancer to match the Standard SKU public IP address, and you can add virtual machines from different Availability Zones to its backend pool.

Standard SKU public IP addresses can only be bound to Standard SKU load balancers. Standard SKU load balancers support backend resources spanning multiple availability zones, ensuring high availability.

Step-by-Step Solution

Determine the required Load Balancer SKU based on the frontend IP address.

The frontend IP is Standard SKU, which mandates a Standard SKU load balancer.

Azure does not support mixing SKUs between the public IP frontend and the load balancer instance itself.

Verify backend pool virtual machine distribution rules for the Standard SKU load balancer.

The Standard SKU load balancer supports virtual machines distributed across multiple Availability Zones.

Standard load balancers offer zone-redundancy and zone-spanning backend pools, unlike Basic load balancers.

Evaluate the IP configuration requirements of individual virtual machine NICs in the backend pool.

All public IPs assigned to the NICs of the backend VMs must match the Standard SKU of the load balancer.

Mixing Basic SKU public IPs on backend virtual machines with a Standard SKU load balancer is unsupported.

Key Concept

Azure Load Balancer SKU alignment and backend pool zone capabilities

Question 706Question →

An Azure administrator configures a hub-and-spoke network topology in the East US region with the following virtual networks:

* VNet-Hub ( $10.200.0.0/16$ ): Contains a Virtual Network Gateway named Hub-GW and a Network Virtual Appliance (NVA).
* VNet-SpokeA ( $10.201.0.0/16$ ): Contains a virtual machine named VM-A.
* VNet-SpokeB ( $10.202.0.0/16$ ): Contains a virtual machine named VM-B.

The administrator establishes bidirectional peering between VNet-Hub and VNet-SpokeA (using peering links Link-Hub-to-A and Link-A-to-Hub), and between VNet-Hub and VNet-SpokeB (using peering links Link-Hub-to-B and Link-B-to-Hub).

The configuration must meet the following requirements:
* VM-A must be able to communicate with an on-premises network through Hub-GW.
* VM-B must be able to receive traffic originating from on-premises that is routed and forwarded through the NVA in VNet-Hub.

Which configuration settings must be enabled on the virtual network peering links to satisfy these requirements?

Enable 'Allow gateway transit' on Link-Hub-to-A, enable 'Use remote gateways' on Link-A-to-Hub, and enable 'Allow forwarded traffic' on Link-B-to-Hub.

Enable 'Use remote gateways' on Link-Hub-to-A, enable 'Allow gateway transit' on Link-A-to-Hub, and enable 'Allow gateway transit' on Link-Hub-to-B.

Enable 'Allow gateway transit' on Link-Hub-to-A, enable 'Use remote gateways' on Link-A-to-Hub, and enable 'Allow gateway transit' on Link-Hub-to-B and Link-B-to-Hub.

Enable 'Allow forwarded traffic' on Link-Hub-to-A and Link-Hub-to-B, and enable 'Use remote gateways' on Link-A-to-Hub and Link-B-to-Hub.

Show answer & explanation

Answer: Enable 'Allow gateway transit' on Link-Hub-to-A, enable 'Use remote gateways' on Link-A-to-Hub, and enable 'Allow forwarded traffic' on Link-B-to-Hub.

Answer

Enable 'Allow gateway transit' on Link-Hub-to-A, enable 'Use remote gateways' on Link-A-to-Hub, and enable 'Allow forwarded traffic' on Link-B-to-Hub.

To allow the virtual machine in the first spoke to use the gateway in the hub virtual network, the peering link on the hub side must allow gateway transit and the link on the spoke side must be configured to use remote gateways. Additionally, to allow the virtual machine in the second spoke to receive traffic forwarded by the NVA in the hub, the peering link on the second spoke must be configured to allow forwarded traffic from the hub.

Step-by-Step Solution

Evaluate the gateway requirements for the virtual machine in the first spoke.

The virtual machine needs to use the virtual network gateway in the hub virtual network.

By default, peered virtual networks cannot use each other's gateways unless explicitly configured.

Determine the peering link properties for gateway transit.

Set 'Allow gateway transit' to true on the hub link (Link-Hub-to-A) and 'Use remote gateways' to true on the spoke link (Link-A-to-Hub).

This allows the gateway-owning hub virtual network to transit traffic for the spoke, and allows the spoke to utilize the remote gateway resource.

Evaluate the routing requirements for the virtual machine in the second spoke.

The virtual machine needs to receive traffic that is forwarded by a Network Virtual Appliance (NVA) in the hub.

Traffic forwarded by an NVA has a source IP outside of the hub virtual network, which Azure filters out by default on peered networks.

Determine the peering link properties for forwarded traffic.

Set 'Allow forwarded traffic' to true on the second spoke's peering link (Link-B-to-Hub).

This configures the peering to accept traffic that did not originate from the peered virtual network itself but was forwarded through it.

Key Concept

Virtual Network Peering configuration parameters including gateway transit, remote gateways, and forwarded traffic permissions.

Estimated Time:2m 0s

Question 707Question →

An administrator is configuring autoscaling for an Azure Virtual Machine Scale Set named `vmss-payments` that uses Flexible orchestration. The scale set currently has $5$ instances and uses a Rolling upgrade policy. You configure a scale-out rule to increase the instance count by $2$ when the average CPU percentage is greater than $80\%$ for $10$ minutes. You need to configure a scale-in rule that decreases the instance count by $1$ when the average CPU percentage is less than a threshold value for $10$ minutes. To prevent instance thrashing, what is the maximum value that you should set for the scale-in CPU threshold?

40\%

60\%

70\%

75\%

Show answer & explanation

Answer: $40\%$

Answer

The correct threshold to configure is

40\%

To prevent thrashing, the scale-in threshold must be lower than the expected CPU utilization after a scale-out occurs. With

5

instances running at just over

80\%

, the total workload is

400\%

405\%

. When

2

instances are added, the load is distributed across

7

instances, reducing the average CPU usage to approximately

57\%

58\%

. Setting the scale-in threshold to

40\%

ensures that the scale-in rule does not trigger immediately after scaling out.

Step-by-Step Solution

Calculate the total CPU load when the scale-out is triggered.

5

instances with

80\%

average load, the total load is

5 \times 80\% = 400\%

CPU capacity.

This determines the total workload that needs to be distributed across the new instances.

Calculate the new average CPU usage after scale-out.

Adding

2

instances increases the total count to

7

. The new average CPU load is

400\% / 7 \approx 57.1\%

(or

405\% / 7 \approx 57.9\%

if just above

80\%

, e.g.,

81\%

, when triggered).

This identifies the new operational CPU percentage immediately after the scale-out occurs.

Select a scale-in threshold that is lower than the new average CPU usage.

The threshold must be set below

57\%

. Among the options,

40\%

is the only value below this limit.

Setting the threshold to

60\%

70\%

, or

75\%

would immediately trigger a scale-in, causing thrashing.

Key Concept

Autoscale thrashing prevention by keeping scale-in thresholds below the post-scale-out CPU utilization level.

Question 708Question →

You are configuring access to a blob container named `telemetry-upload` in an Azure Storage account named `iotmetrics2026` for a third-party application. The application requires permissions to upload files to the container under the following constraints:
- Access must be limited solely to the `telemetry-upload` container.
- The token must become invalid after 8 hours.
- Requests must be accepted only from the public IP address $198.51.100.88$ .
- You must have the ability to invalidate the token immediately if a leak occurs, without rotating the storage account's primary or secondary keys or impacting other applications.

Which two actions should you perform to meet these requirements? (Select two.)

Select all that apply

Create a stored access policy on the telemetry-upload container.

Generate a service SAS for the container that references the stored access policy and specifies the allowed IP address.

Generate an account SAS that specifies container permissions, the allowed IP address, and an 8-hour expiration.

Assign the Storage Blob Data Contributor role to the application's service principal and enable the storage firewall to allow the IP address.

Show answer & explanation

Answer: Create a stored access policy on the telemetry-upload container.; Generate a service SAS for the container that references the stored access policy and specifies the allowed IP address.

Answer

To meet the requirements, you must create a stored access policy on the target container and generate a service SAS that references this policy while specifying the allowed client IP address.

To fulfill the requirements of container-specific scope, IP restriction, and immediate revocation without affecting other tokens or rotating storage keys, you must use a service SAS associated with a stored access policy. Creating a stored access policy on the container provides a central management point for the token's lifetime and permissions. When you generate a service SAS that references this policy and includes the client's public IP address, the token inherits the constraints. If the token is compromised, deleting or modifying the stored access policy immediately invalidates the SAS without impacting storage keys or other independent SAS tokens.

Step-by-Step Solution

Create a stored access policy on the container level.

A stored access policy is established on the telemetry-upload container, specifying the write permissions and the 8-hour expiration timeline.

Stored access policies provide the ability to group constraints and revoke service SAS tokens immediately by deleting or altering the policy.

Generate a service SAS that references the policy and includes the client IP restriction.

A service SAS token is generated, bound to the stored access policy, and restricted to the client's public IP address.

The service SAS targets only the specific container (least privilege) and inherits the policy's lifetime, allowing revocation while enforcing IP-level security.

Key Concept

Using Stored Access Policies with Service SAS to enable revocation without rotating storage keys.

Estimated Time:2m 0s

Question 709Question →

You are configuring Azure resources to support a web application. You plan to deploy a public Azure Load Balancer to distribute incoming HTTP requests across three virtual machines named VM1, VM2, and VM3. The virtual machines are deployed in a single Virtual Network (VNet) but are located in different Availability Zones. VM1 and VM2 currently have Basic SKU public IP addresses assigned directly to their network interfaces. VM3 does not have a public IP address. You need to configure the load balancer and backend resources to ensure that the load balancer can successfully distribute traffic to all three virtual machines. Which two configuration actions should you perform? (Select two.)

Select all that apply

Create a Standard SKU public IP address for the load balancer frontend.

Upgrade the public IP addresses of VM1 and VM2 to the Standard SKU.

Create a Basic SKU public IP address for the load balancer frontend.

Deploy a Basic SKU Load Balancer to manage the backend pool.

Show answer & explanation

Answer: Create a Standard SKU public IP address for the load balancer frontend.; Upgrade the public IP addresses of VM1 and VM2 to the Standard SKU.

Answer

To support virtual machines in different Availability Zones, you must deploy a Standard SKU Load Balancer with a Standard SKU public IP address as its frontend. Additionally, you must upgrade the public IP addresses of the backend virtual machines (VM1 and VM2) to the Standard SKU.

To distribute traffic across virtual machines in different Availability Zones, a Standard SKU Load Balancer must be deployed. A Standard Load Balancer requires a Standard SKU public IP address for its frontend configuration. Additionally, any virtual machines in the backend pool of a Standard Load Balancer cannot use Basic SKU public IP addresses on their network interfaces, meaning the existing public IPs on the backend VMs must be upgraded to the Standard SKU.

Step-by-Step Solution

Determine the required Load Balancer SKU for zonal virtual machines.

Standard SKU Load Balancer is identified as the requirement.

Basic SKU Load Balancers do not support backend pools with virtual machines across multiple Availability Zones.

Determine the SKU requirement for the frontend IP address.

Standard SKU public IP address is selected for the frontend.

Standard Load Balancer frontends require Standard SKU public IP addresses and are incompatible with Basic SKU public IP addresses.

Align the public IP SKU of the backend virtual machines.

Upgrade VM1 and VM2 public IP addresses to Standard SKU.

Virtual machines in the backend pool of a Standard SKU Load Balancer cannot have Basic SKU public IP addresses attached to their network interfaces.

Key Concept

Azure Load Balancer SKU capability and compatibility rules

Question 710Question →

To enforce security standards, a company assigns an Azure Policy definition that blocks the deployment of public IP addresses to a management group named `MG-Corp`. A project team needs to deploy a public IP address inside a resource group named `RG-App1` within a subscription that is a child of `MG-Corp`. Which action should the administrator perform to allow this deployment while keeping the policy enforced for all other resources under the management group?

Assign a policy definition with the 'Audit' effect directly to the `RG-App1` resource group.

Assign a policy definition with the 'Disabled' effect directly to the `RG-App1` resource group.

Add the `RG-App1` resource group to the excluded scopes list of the policy assignment at the `MG-Corp` level.

Assign the Policy Contributor role to the project team's identity at the `RG-App1` scope.

Show answer & explanation

Answer: Add the `RG-App1` resource group to the excluded scopes list of the policy assignment at the `MG-Corp` level.

Answer

Add the resource group to the excluded scopes list of the policy assignment at the management group level.

The correct action is to add the resource group to the excluded scopes list of the policy assignment at the management group level. Azure Policy assignments support exclusions, which allow specific resource groups, subscriptions, or resources to be bypassed during policy evaluation. This permits the project team to deploy public IP addresses within the resource group without affecting the enforcement of the policy on other resources in the management group.

Step-by-Step Solution

Analyze the inheritance of Azure Policy assignments.

The policy assigned at the parent management group scope (`MG-Corp`) is inherited by all child subscriptions and resource groups, including `RG-App1`.

Azure Policies are inherited downward through the resource hierarchy.

Determine the impact of lower-level policy assignments.

Assigning a different policy effect (such as Audit or Disabled) at a lower scope does not override the Deny effect inherited from the parent scope.

Azure Policy evaluates all applicable assignments, and a Deny effect from any scope will block the deployment.

Apply policy exclusion to bypass enforcement.

Configuring the exclusion list on the assignment at `MG-Corp` to include `RG-App1` prevents the policy from evaluating resources in that specific resource group.

Exclusions are the standard mechanism to exempt specific scopes from parent policy assignments while maintaining enforcement elsewhere.

Key Concept

Azure Policy scope inheritance and exclusions

Question 711Question →

You plan to deploy an Azure virtual machine named VM1. You configure a network interface named NIC1 for VM1 and connect it to a subnet in a virtual network named VNet1. You need to create and attach a second network interface named NIC2 to VM1. Which configuration is required for NIC2?

NIC2 must be connected to VNet1.

NIC2 must be connected to a different virtual network that is peered with VNet1.

NIC2 must be deployed in a different Availability Zone than VM1 to ensure network redundancy.

NIC2 must be associated with a Basic SKU Load Balancer if NIC1 is associated with a Standard SKU Load Balancer.

Show answer & explanation

Answer: NIC2 must be connected to VNet1.

Answer

NIC2 must be connected to VNet1.

All network interfaces (NICs) attached to an Azure virtual machine must reside in the same location and subscription as the VM, and they must be connected to the same virtual network (VNet). While NIC2 can be in a different subnet than NIC1, it must be within the same virtual network (VNet1).

Step-by-Step Solution

Determine the network requirements for multi-NIC virtual machines in Azure.

Azure requires all network interfaces attached to a virtual machine to reside in the same virtual network.

This maintains the network boundary and routing scope for the single virtual machine instance.

Identify the virtual network hosting the first network interface (NIC1).

NIC1 is connected to a subnet in VNet1.

This establishes VNet1 as the virtual network boundary for VM1.

Apply the virtual network boundary rule to the second network interface (NIC2).

NIC2 must be connected to VNet1 (though it can be in a different subnet within VNet1).

Connecting NIC2 to any other virtual network, even a peered one, is not supported.

Key Concept

Azure Virtual Machine Multi-NIC Configuration Constraints

Question 712Question →

An administrator is configuring a hub-and-spoke network topology in Microsoft Azure. VNet-Hub has the address space $10.100.0.0/16$ , contains an Azure VPN Gateway, and has virtual machines deployed. VNet-Spoke has the address space $10.200.0.0/16$ , does not contain a gateway, and has virtual machines deployed. A virtual network peering is established between VNet-Hub and VNet-Spoke. The administrator wants virtual machines in VNet-Spoke to route their on-premises traffic through the VPN Gateway in VNet-Hub. Which setting must the administrator configure on the peering connection from VNet-Spoke to VNet-Hub to achieve this objective?

Enable 'Use remote gateways'

Enable 'Allow gateway transit'

Enable 'Allow forwarded traffic'

Enable 'Allow virtual network access'

Show answer & explanation

Answer: Enable 'Use remote gateways'

Answer

Enable 'Use remote gateways'

To allow virtual machines in VNet-Spoke to route their on-premises traffic through the VPN Gateway in VNet-Hub, the peering connection from VNet-Spoke to VNet-Hub must be configured to use the remote virtual network's gateway. This is achieved by enabling 'Use remote gateways'.

Step-by-Step Solution

Identify the VNet hosting the gateway and the spoke VNet requiring access.

VNet-Hub hosts the VPN Gateway, and VNet-Spoke needs to send on-premises traffic through it.

This establishes the roles of the two virtual networks in the hub-and-spoke relationship.

Determine the required setting on the hub side of the peering connection.

The peering link from VNet-Hub to VNet-Spoke must have 'Allow gateway transit' enabled.

This allows the hub VNet to share its VPN gateway with the peered spoke VNet.

Determine the required setting on the spoke side of the peering connection.

The peering link from VNet-Spoke to VNet-Hub must have 'Use remote gateways' enabled.

This instructs VMs in the spoke VNet to route traffic destined for on-premises networks through the hub's gateway.

Key Concept

Gateway Transit in Virtual Network Peering

Question 713Question →

An administrator is configuring network security for an Azure subscription containing a virtual network named `VNet1`. `VNet1` contains two subnets: `Subnet-Web` ( $10.0.1.0/24$ ) and `Subnet-DB` ( $10.0.2.0/24$ ).

The subnets contain the following virtual machines and network configurations:

Subnet	VM Name	Private IP	NIC Name	ASG Association
`Subnet-Web`	`VM-Web1`	` $10.0.1.4$ `	`nic-web1`	`ASG-Web`
`Subnet-Web`	`VM-Web2`	` $10.0.1.5$ `	`nic-web2`	`ASG-Web`
`Subnet-DB`	`VM-DB1`	` $10.0.2.4$ `	`nic-db1`	`ASG-DB`
`Subnet-DB`	`VM-DB2`	` $10.0.2.5$ `	`nic-db2`	None

A Network Security Group named `NSG-DB` is associated with `Subnet-DB`. No other Network Security Groups are associated with the subnets or network interfaces (NICs).

You must configure `NSG-DB` to meet the following requirements:
- Allow inbound SQL Database traffic (TCP port $1433$ ) from `VM-Web1` to `VM-DB1` only.
- Block all other TCP port $1433$ traffic from `Subnet-Web` to `Subnet-DB`.
- Minimize administrative effort and follow the principle of least privilege.

Which two of the following inbound security rules should you add to `NSG-DB` to meet these requirements? (Select two.)

Select all that apply

An inbound rule with Priority

120

, Source: IP Addresses (`10.0.1.4`), Destination: Application security group (`ASG-DB`), Port: 1433, Protocol: TCP, Action: Allow

An inbound rule with Priority

250

, Source: Service Tag (`VirtualNetwork`), Destination: Service Tag (`VirtualNetwork`), Port: 1433, Protocol: TCP, Action: Deny

An inbound rule with Priority

120

, Source: Application security group (`ASG-Web`), Destination: Application security group (`ASG-DB`), Port: 1433, Protocol: TCP, Action: Allow

An inbound rule with Priority

250

, Source: IP Addresses (`10.0.1.4`), Destination: Application security group (`ASG-DB`), Port: 1433, Protocol: TCP, Action: Allow

An inbound rule with Priority

120

, Source: Service Tag (`VirtualNetwork`), Destination: Service Tag (`VirtualNetwork`), Port: 1433, Protocol: TCP, Action: Deny

Show answer & explanation

Answer: An inbound rule with Priority $120$ , Source: IP Addresses (`10.0.1.4`), Destination: Application security group (`ASG-DB`), Port: 1433, Protocol: TCP, Action: Allow; An inbound rule with Priority $250$ , Source: Service Tag (`VirtualNetwork`), Destination: Service Tag (`VirtualNetwork`), Port: 1433, Protocol: TCP, Action: Deny

Answer

Configure an inbound rule in NSG-DB with Priority 120, Source IP 10.0.1.4, Destination ASG-DB, Port 1433, TCP, Allow; and a second inbound rule with Priority 250, Source Service Tag VirtualNetwork, Destination Service Tag VirtualNetwork, Port 1433, TCP, Deny.

The correct configuration consists of: 1) An inbound rule allowing traffic from VM-Web1's IP address (10.0.1.4) to the ASG-DB group with a higher precedence (Priority 120). 2) A broader inbound rule denying all TCP 1433 traffic within the VirtualNetwork service tag scope with a lower precedence (Priority 250). Since NSG rules are evaluated in order of priority (lowest number first), traffic from VM-Web1 to VM-DB1 matches the Allow rule at Priority 120 and is permitted. All other TCP 1433 traffic between Subnet-Web and Subnet-DB bypasses the first rule (due to mismatched source IP or destination ASG) and is blocked by the Deny rule at Priority 250.

Step-by-Step Solution

Determine the source identity for VM-Web1.

Since ASG-Web contains both VM-Web1 and VM-Web2, it cannot be used as the source in the allow rule because that would allow VM-Web2 traffic. Therefore, VM-Web1's IP address (10.0.1.4) must be used as the source to follow the principle of least privilege.

We must only allow VM-Web1, not VM-Web2.

Determine the destination identity for VM-DB1.

VM-DB1's network interface is associated with ASG-DB, whereas VM-DB2 has no ASG association. By using ASG-DB as the destination, we target only VM-DB1.

We must allow traffic to VM-DB1 while ensuring VM-DB2 remains blocked.

Select the correct action and priority for the allow rule.

An inbound Allow rule with a lower priority number (120) must be created to permit TCP port 1433 traffic from 10.0.1.4 to ASG-DB.

Lower priority numbers have higher precedence in NSG rule evaluation, ensuring the allow rule is processed before any generic block rules.

Design the block rule to restrict other SQL traffic.

An inbound Deny rule with a higher priority number (250) using the VirtualNetwork service tag for both source and destination must be created.

This blocks all other inter-subnet SQL traffic (VM-Web2 to VM-DB1, VM-Web1 to VM-DB2, and VM-Web2 to VM-DB2) while allowing the specific VM-Web1 to VM-DB1 traffic allowed by the higher precedence rule.

Key Concept

NSG rules are processed in priority order (lowest numbers first). Once a match is found, no further rules are processed. Application Security Groups allow grouping network interfaces for rule application, but if an ASG contains multiple hosts, individual IP address rules must be used to enforce granular access control.

Question 714Question →

Your company has an Azure environment with a virtual network named `vnet-hybrid-prod` that has an address space of $10.150.0.0/22$ . The virtual network contains an existing subnet named `snet-db` with an address range of $10.150.0.0/24$ .

You plan to deploy a VPN Gateway and a new application cluster to `vnet-hybrid-prod`. You must satisfy the following requirements:
- The VPN Gateway must be deployed to a subnet named `GatewaySubnet`.
- The application cluster will consist of 27 virtual machines that require individual private IP addresses.
- You must minimize IP address waste.

Which two subnets should you create to meet the requirements? (Choose two.)

Select all that apply

snet-application with the address range

10.150.2.0/27

GatewaySubnet with the address range

10.150.1.0/27

snet-application with the address range

10.150.0.128/27

snet-application with the address range

10.150.3.0/28

GatewaySubnet with the address range

10.150.1.0/30

Show answer & explanation

Answer: snet-application with the address range $10.150.2.0/27$ ; GatewaySubnet with the address range $10.150.1.0/27$

Answer

The correct subnets are 'snet-application with the address range

10.150.2.0/27

' and 'GatewaySubnet with the address range

10.150.1.0/27

To host 27 virtual machines, a subnet must support at least 27 usable IP addresses. Since Azure reserves 5 IP addresses per subnet, the total addresses needed is

27 + 5 = 32

, which corresponds to a /27 prefix. The option with 'snet-application with the address range

10.150.2.0/27

' satisfies this without overlapping with the existing subnet. Furthermore, the option with 'GatewaySubnet with the address range

10.150.1.0/27

' is correct because Azure requires the GatewaySubnet to use a prefix size of /29 or larger, and it does not overlap with the other subnets.

Step-by-Step Solution

Calculate the subnet size required for the 27 virtual machines.

A /27 subnet size is required.

A subnet of size /28 provides 16 IP addresses. Subtracting the 5 Azure-reserved IP addresses leaves only 11 usable IPs, which is insufficient. A subnet of size /27 provides 32 IP addresses; subtracting the 5 reserved IPs leaves exactly 27 usable IP addresses, satisfying the requirement with zero wasted host IPs.

Verify that the proposed application subnet does not overlap with existing subnets.

The range

10.150.2.0/27

is valid and non-overlapping.

The existing subnet `snet-db` occupies

10.150.0.0/24

(

10.150.0.0

10.150.0.255

). The subnet `snet-application` with the range

10.150.2.0/27

(

10.150.2.0

10.150.2.31

) does not overlap with `snet-db`.

Select a valid size and range for the GatewaySubnet.

The range

10.150.1.0/27

is valid.

Azure GatewaySubnet requires a prefix size of /29 or larger (e.g. /28, /27). A /30 prefix is invalid and will fail deployment. The range

10.150.1.0/27

does not overlap with `snet-db` (

10.150.0.0/24

) or the newly proposed `snet-application` (

10.150.2.0/27

Key Concept

Determining Azure subnet sizes based on usable host requirements (accounting for the 5 reserved IP addresses) and satisfying specialized subnet constraints (such as GatewaySubnet size limits) without IP overlaps.

Question 715Question →

Your company's security mandate requires all new AKS deployments to be private clusters, ensuring that the Kubernetes API server is accessible only within the internal network. You are preparing to deploy a private AKS cluster in a spoke virtual network named `VNet-Spoke` ( $10.240.0.0/16$ ). The Azure environment has a hub-and-spoke topology. The hub virtual network, `VNet-Hub` ( $10.100.0.0/16$ ), contains a custom DNS server running on a virtual machine at $10.100.1.4$ . `VNet-Spoke` is peered with `VNet-Hub` and is configured to use $10.100.1.4$ as its primary DNS server. You need to deploy the private AKS cluster and ensure that management clients in both `VNet-Spoke` and `VNet-Hub` can resolve the private FQDN of the AKS API server. What configuration should you implement?

Link the Azure Private DNS zone created for the AKS cluster to `VNet-Hub`, and configure a conditional forwarder on the custom DNS server to forward queries for `azmk8s.io` to

168.63.129.16

Link the Azure Private DNS zone created for the AKS cluster to `VNet-Spoke` only, and configure a conditional forwarder on the custom DNS server to forward queries for `azmk8s.io` to the default gateway IP address of `VNet-Spoke` (

10.240.0.1

Link the Azure Private DNS zone to `VNet-Spoke`, and configure a DNS forwarding rule on `VNet-Spoke` that points to the Kubernetes internal service IP address

10.0.0.10

Configure a custom DNS zone named `privatelink.eastus.azmk8s.io` directly on the custom DNS server in `VNet-Hub` and initiate a zone transfer from the Azure DNS IP address

168.63.129.16

Show answer & explanation

Answer: Link the Azure Private DNS zone created for the AKS cluster to `VNet-Hub`, and configure a conditional forwarder on the custom DNS server to forward queries for `azmk8s.io` to $168.63.129.16$ .

Answer

Link the Azure Private DNS zone created for the AKS cluster to `VNet-Hub`, and configure a conditional forwarder on the custom DNS server to forward queries for `azmk8s.io` to

168.63.129.16

For private AKS clusters, the API server is exposed via a private endpoint. The FQDN resolves to a private IP via an Azure Private DNS zone (e.g., `privatelink.<region>.azmk8s.io`). When virtual networks use custom DNS servers, these servers must forward queries for the cluster's DNS zone to the Azure recursive resolver at

168.63.129.16

. For this lookup to succeed, the Azure Private DNS zone must be linked to the virtual network hosting the custom DNS server (in this case, `VNet-Hub`).

Step-by-Step Solution

Identify the DNS path for client machines in both virtual networks.

Since `VNet-Spoke` uses

10.100.1.4

in `VNet-Hub` as its DNS server, all client queries are processed by the custom DNS server.

Correct DNS routing requires configuration at the resolver level (the custom DNS server).

Determine where the Azure Private DNS zone must be linked.

The Private DNS zone must be linked to `VNet-Hub` because the custom DNS server query originates from `VNet-Hub` when forwarding to the Azure recursive resolver.

Azure DNS only resolves private zone records for virtual networks that are explicitly linked to that zone.

Configure the forwarding target on the custom DNS server.

Add a conditional forwarder for the domain `azmk8s.io` pointing to

168.63.129.16

This routes the private API server name resolution queries to Azure's internal resolver, which returns the private IP mapped in the linked Private DNS zone.

Key Concept

Azure Private Link DNS integration with custom DNS in a hub-and-spoke network.

Question 716Question →

An organization's Azure environment is structured with the following resource hierarchy:

* Management Group: Tenant-Root-MG
* Subscription: Sub-Prod-App
* Resource Group: RG-Web-Services

You need to grant a security group named Web-Operators the permission to restart and start virtual machines within the RG-Web-Services resource group. The operators must be able to view the virtual machines in the Azure portal but must not be permitted to create, delete, or modify the virtual machines or any other resources in the subscription.

Which of the following configurations should you implement to meet this requirement while adhering to the principle of least privilege?

Assign the built-in Contributor Azure RBAC role to the Web-Operators group at the RG-Web-Services resource group level.

Assign the Microsoft Entra ID directory role named Cloud Device Administrator to the Web-Operators group at the Tenant-Root-MG management group level.

Create a custom Azure RBAC role with the Microsoft.Compute/virtualMachines/read, Microsoft.Compute/virtualMachines/start/action, and Microsoft.Compute/virtualMachines/restart/action permissions. Set the assignable scope to the RG-Web-Services resource group, and assign the role to the Web-Operators group at the resource group level.

Assign the built-in Virtual Machine Contributor Azure RBAC role to the Web-Operators group at the Sub-Prod-App subscription level.

Show answer & explanation

Answer: Create a custom Azure RBAC role with the Microsoft.Compute/virtualMachines/read, Microsoft.Compute/virtualMachines/start/action, and Microsoft.Compute/virtualMachines/restart/action permissions. Set the assignable scope to the RG-Web-Services resource group, and assign the role to the Web-Operators group at the resource group level.

Answer

Create a custom Azure RBAC role with the read, start, and restart actions, set its assignable scope to the resource group, and assign it to the security group at the resource group level.

The correct approach involves creating a custom Azure RBAC role containing only the necessary permissions (read, start, and restart actions) and assigning it at the resource group level. This ensures that the security group members can only perform the specified actions on virtual machines within the target resource group and nowhere else, fully satisfying the principle of least privilege.

Step-by-Step Solution

Determine the minimum permissions required for the operational tasks.

Identify that viewing requires Microsoft.Compute/virtualMachines/read, while starting and restarting require Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/restart/action.

By defining only these specific actions, you avoid granting generic write or delete privileges.

Determine the correct scope for the role assignment.

Select the RG-Web-Services resource group as the target scope for assignment.

Assigning at the resource group level prevents the permissions from being inherited across the entire subscription, satisfying the least privilege principle.

Define the custom role properties and complete the assignment.

Configure a custom role with the identified actions, set the assignable scope to the resource group, and assign it to the Web-Operators security group.

This implements the custom RBAC role with the precise permissions and scope required.

Key Concept

Enforcing the principle of least privilege using custom Azure RBAC roles at the resource group scope.

Estimated Time:1m 30s

Question 717Question →

You provision a public IP address named IP-Pub1 and select the Standard SKU. You now need to set up a new Azure Load Balancer that will utilize IP-Pub1 as its frontend configuration. Which load balancer SKU must you select to ensure compatibility with IP-Pub1?

Standard

Basic

Gateway

Premium

Show answer & explanation

Answer: Standard

Answer

Standard

The correct answer is Standard. In Azure, the SKU of the public IP address must match the SKU of the load balancer. Since the public IP address is created using the Standard SKU, the load balancer must also be deployed using the Standard SKU.

Step-by-Step Solution

Identify the SKU of the public IP address being used.

The public IP address IP-Pub1 is configured with the Standard SKU.

Compatibility requirements in Azure dictate that frontend IP configurations and the load balancer resource itself must use matching SKUs.

Determine the supported Load Balancer SKU for Standard IP addresses.

Standard public IP addresses can only be bound to a Standard Load Balancer.

Mixing a Basic SKU load balancer with a Standard SKU public IP is not supported by Azure.

Key Concept

Azure Load Balancer SKU compatibility requires that the frontend public IP address SKU matches the load balancer SKU (Standard public IPs require Standard Load Balancers).

Estimated Time:1m 0s

Question 718Question →

You have an Azure subscription containing a virtual network named `VNet1` ( $172.20.0.0/16$ ). `VNet1` contains the following three subnets:
* `Subnet-Web` ( $172.20.1.0/24$ )
* `Subnet-App` ( $172.20.2.0/24$ )
* `Subnet-Transit` ( $172.20.10.0/24$ )

You deploy a Network Virtual Appliance (NVA) named `NVA1` to `Subnet-Transit`. The primary network interface of `NVA1` is named `nic-nva` and has a private IP address of $172.20.10.4$ .

You need to implement a routing solution that meets the following requirements:
1. All outbound internet-bound traffic from `Subnet-Web` must be routed through `NVA1`.
2. All internal traffic from `Subnet-Web` destined for database servers in `Subnet-App` must bypass `NVA1` and route directly.
3. `NVA1` must be able to forward transit packets.

Which two configurations should you perform to meet these requirements? (Select two.)

Select all that apply

Enable IP forwarding on the network interface nic-nva.

Associate a route table with Subnet-Web that contains a route for 0.0.0.0/0 with a next hop type of Virtual appliance and a next hop IP address of 172.20.10.4.

Associate a route table with Subnet-Web that contains a route for 172.20.2.0/24 with a next hop type of Virtual appliance and a next hop IP address of 172.20.10.4.

Associate a route table with Subnet-Web that contains a route for 0.0.0.0/0 with a next hop type of Virtual network gateway.

Associate a route table with Subnet-Transit that contains a route for 0.0.0.0/0 with a next hop type of Virtual appliance and a next hop IP address of 172.20.10.4.

Show answer & explanation

Answer: Enable IP forwarding on the network interface nic-nva.; Associate a route table with Subnet-Web that contains a route for 0.0.0.0/0 with a next hop type of Virtual appliance and a next hop IP address of 172.20.10.4.

Answer

To route internet traffic from the web subnet through the NVA while bypassing it for database traffic, you must enable IP forwarding on the network interface of the NVA, and associate a route table with the web subnet that directs traffic destined for the internet to the appliance's IP address. Internal traffic will naturally bypass the NVA because the local virtual network system route has a longer prefix match than the default route.

The correct configuration requires two steps: enabling IP forwarding on the primary network interface of the NVA to permit the VM to forward packets it does not own, and associating a route table with the web subnet containing a route for the internet (

0.0.0.0/0

) pointing to the NVA's IP. Due to the Longest Prefix Match (LPM) rule, traffic destined for the application subnet (

172.20.2.0/24

) matches the virtual network system route (

172.20.0.0/16

) rather than the custom default route (

0.0.0.0/0

), successfully bypassing the NVA without needing additional local routes.

Step-by-Step Solution

Enable IP forwarding on the Network Virtual Appliance (NVA) network interface.

The network interface nic-nva is updated to allow IP forwarding.

By default, Azure security checks drop packets where the destination IP does not match the interface IP. Enabling IP forwarding allows the NVA to act as a router and forward transit traffic.

Create a route table and add a default route for internet-bound traffic.

A route with prefix

0.0.0.0/0

is created with a next hop type of Virtual appliance and a next hop IP of

172.20.10.4

This route intercepts default internet traffic (

0.0.0.0/0

) and redirects it to the firewall NVA.

Associate the route table with the source subnet.

The route table is associated with Subnet-Web.

UDRs must be associated with the subnet containing the source virtual machines to affect their outbound routing decisions.

Analyze route selection for internal database traffic.

Traffic destined for Subnet-App (

172.20.2.0/24

) uses the default system route for VNet1 (

172.20.0.0/16

Because of Longest Prefix Match (LPM), the system route prefix of

172.20.0.0/16

is preferred over the UDR prefix of

0.0.0.0/0

for any destination within the virtual network. Thus, internal traffic automatically bypasses the NVA.

Key Concept

Azure Route Selection rules, specifically Longest Prefix Match (LPM) and the requirement of IP forwarding on NVAs for packet transit.

Question 719Question →

Your company has an Azure subscription containing a virtual network named `VNet1`. `VNet1` contains two subnets named `Subnet-Web` and `Subnet-App`.

The virtual machines in the subnets are configured as follows:

Virtual Machine	Subnet	Application Security Group (ASG)	NIC-level NSG
`VM-Web1`	`Subnet-Web`	`ASG-Web`	None
`VM-Web2`	`Subnet-Web`	`ASG-Web`	None
`VM-App1`	`Subnet-App`	`ASG-App`	`NSG-App-NIC`

`Subnet-Web` is associated with a Network Security Group (NSG) named `NSG-Web-Subnet`. `Subnet-App` is associated with an NSG named `NSG-App-Subnet`.

The NSGs have the following custom inbound rules:
- `NSG-Web-Subnet`: Only default rules.
- `NSG-App-Subnet`: A rule with Priority 1000, Source: `VirtualNetwork`, Destination: `VirtualNetwork`, Port: `Any`, Protocol: `Any`, Action: `Deny`.
- `NSG-App-NIC`: A rule with Priority 1000, Source: `VirtualNetwork`, Destination: `VirtualNetwork`, Port: `Any`, Protocol: `Any`, Action: `Deny`.

You need to allow `VM-Web1` and `VM-Web2` to connect to `VM-App1` on TCP port 8443. All other traffic from `Subnet-Web` to `Subnet-App` must remain blocked.

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

Select all that apply

In NSG-App-Subnet, add an inbound rule: Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow

In NSG-App-Subnet, add an inbound rule: Priority 1500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow

In NSG-App-NIC, add an inbound rule: Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow

In NSG-App-NIC, add an inbound rule: Priority 1500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow

In NSG-Web-Subnet, add an outbound rule: Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow

Show answer & explanation

Answer: In NSG-App-Subnet, add an inbound rule: Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow; In NSG-App-NIC, add an inbound rule: Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow

Answer

In NSG-App-Subnet, add an inbound rule with Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow; and in NSG-App-NIC, add an inbound rule with Priority 500, Source: ASG-Web, Destination: ASG-App, Port: 8443, Protocol: TCP, Action: Allow.

To allow inbound traffic to VM-App1, the traffic must pass through both the subnet-level NSG (NSG-App-Subnet) and the NIC-level NSG (NSG-App-NIC). Since both NSGs currently block VNet traffic via custom rules with Priority 1000, you must add an Allow rule to both NSGs. These new rules must have a priority value lower than 1000 (such as 500) to be evaluated first and allow the traffic before the deny rules are reached.

Step-by-Step Solution

Analyze the network traffic direction and evaluation flow.

Traffic flows from Subnet-Web (source VMs in ASG-Web) to Subnet-App (destination VM-App1 in ASG-App) on TCP port 8443. For inbound traffic, Azure evaluates the subnet-level NSG (NSG-App-Subnet) first, followed by the NIC-level NSG (NSG-App-NIC). Both must allow the traffic.

Understanding the sequential evaluation of subnet-level and NIC-level NSGs is required to determine where to place the allow rules.

Determine the required rule priority.

The existing deny rules in both NSGs have a priority of 1000. To override these deny rules, the new allow rules must have a priority lower than 1000 (e.g., 500). Rules with a priority higher than 1000 (e.g., 1500) will be processed after the deny rule and will not take effect.

NSG rules are processed in priority order (lower numbers have higher precedence), so the allow rules must have a lower priority number than the deny rules.

Formulate the rules using Application Security Groups (ASGs).

The allow rules should target ASG-Web as the source and ASG-App as the destination. This allows specific VMs associated with those ASGs to communicate while blocking other traffic.

Using ASGs is the recommended approach to apply network security rules to groups of virtual machines without managing individual IP addresses.

Key Concept

Inbound NSG evaluation order (subnet-level then NIC-level) and rule priority precedence (lower numbers represent higher priority).

Question 720Question →

An administrator needs to configure name resolution for virtual machines in an Azure virtual network named VNet1. The administrator decides to use a custom private domain namespace. Arrange the steps in the correct order to configure private name resolution using an Azure Private DNS zone.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create the Azure Private DNS zone. Next, link the Private DNS zone to the target virtual network. Finally, add the required DNS records within the zone.

To set up private DNS name resolution, the Private DNS zone must first be created to define the domain space. Next, a virtual network link must be established to associate the zone with the VNet where the client VMs reside. Finally, DNS records (such as A records) are added to the zone so that VMs can resolve specific hostnames.

Step-by-Step Solution

Create the Private DNS zone named private.corp.local.

The DNS namespace is established in Azure, but it is not yet associated with any network or containing host records.

You must have the zone resource created in Azure before you can attach links or create records inside it.

Create a virtual network link between the Private DNS zone and VNet1.

VNet1 is associated with the zone, enabling name resolution for VMs in VNet1.

Without a virtual network link, VMs within VNet1 cannot resolve any DNS records defined in the Private DNS zone.

Add an A record to the Private DNS zone for a virtual machine.

The VM's hostname can now be resolved to its private IP address by resources in VNet1.

Once the virtual network link is in place, creating the A record completes the configuration by mapping the hostname to the IP address.

Key Concept

Azure Private DNS Zone Configuration and VNet Linking

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