All practice questions

1252 questions

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

You have an Azure storage account named stdatafiles44 that hosts an Azure file share named templates. You need to configure Microsoft Entra ID authentication over SMB for the file share. The solution must allow cloud-only user accounts in a Microsoft Entra ID group named Designers to read and write files in the share using their Microsoft Entra ID credentials. Which two configurations should you perform? (Select two.)

Select all that apply

Enable Microsoft Entra Kerberos authentication for the storage account.

Assign the Storage File Data SMB Share Contributor role to the Designers group.

Enable Microsoft Entra Domain Services (Domain Services) for the Microsoft Entra tenant.

Assign the Storage Blob Data Contributor role to the Designers group.

Generate a Shared Access Signature (SAS) token for the file share and distribute it to the members of the Designers group.

Show answer & explanation

Answer: Enable Microsoft Entra Kerberos authentication for the storage account.; Assign the Storage File Data SMB Share Contributor role to the Designers group.

Answer

To enable Microsoft Entra ID authentication over SMB for the file share, you should enable Microsoft Entra Kerberos authentication for the storage account and assign the Storage File Data SMB Share Contributor role to the Designers group.

To enable Microsoft Entra ID authentication over SMB for cloud-only user accounts to access an Azure file share, you must configure Microsoft Entra Kerberos authentication on the storage account. This allows Microsoft Entra ID to issue Kerberos tickets for accessing the file share. Additionally, you must assign an appropriate share-level Azure RBAC role, such as the Storage File Data SMB Share Contributor role, to the Microsoft Entra ID group to authorize read and write operations.

Step-by-Step Solution

Enable Microsoft Entra Kerberos authentication on the storage account.

The storage account is configured to issue and accept Kerberos tickets for Microsoft Entra ID cloud-only user accounts.

This allows native cloud-only user authentication over SMB without requiring on-premises Active Directory or Microsoft Entra Domain Services.

Assign the Storage File Data SMB Share Contributor role to the Designers group at the storage account or file share scope.

Members of the Designers group are authorized with read and write permissions at the share level.

Share-level Azure RBAC roles are required to grant access to the file share after successful authentication.

Key Concept

Configuring identity-based authentication for Azure Files over SMB using Microsoft Entra Kerberos and share-level Azure RBAC roles.

Estimated Time:1m 30s

Question 822Question →

An administrator deploys three virtual networks in an Azure subscription:

* VNet-Hub ( $172.16.0.0/16$ ), containing a VPN gateway and a virtual machine named VM-Hub ( $172.16.1.4$ ) deployed in Subnet-Hub.
* VNet-Spoke1 ( $172.17.0.0/16$ ), containing a virtual machine named VM-Spoke1 ( $172.17.1.4$ ) deployed in Subnet-Spoke1.
* VNet-Spoke2 ( $172.18.0.0/16$ ), containing a virtual machine named VM-Spoke2 ( $172.18.1.4$ ) deployed in Subnet-Spoke2.

The administrator configures virtual network peering between VNet-Hub and VNet-Spoke1 with 'Allow gateway transit' enabled on VNet-Hub and 'Use remote gateways' enabled on VNet-Spoke1. The administrator also configures virtual network peering between VNet-Hub and VNet-Spoke2 with 'Allow gateway transit' enabled on VNet-Hub and 'Use remote gateways' enabled on VNet-Spoke2. 'Allow forwarded traffic' is enabled on all peering connections. No User-Defined Routes (UDRs) or Network Virtual Appliances (NVAs) are deployed.

To enable VM-Spoke1 to communicate with VM-Spoke2, no additional peering connections or routing resources are required because the existing gateway transit configurations automatically route traffic between the spokes through the hub.

True

False

Show answer & explanation

Answer: False

Answer

False

The statement is false because virtual network peering in Azure is strictly non-transitive. Enabling 'Allow gateway transit' on the hub and 'Use remote gateways' on the spokes allows the spokes to use the hub's VPN gateway to communicate with on-premises networks, but it does not enable routing between the spokes. For VM-Spoke1 to communicate with VM-Spoke2, you must configure either direct peering between the spokes, or route the traffic through a network virtual appliance (NVA) or Azure Firewall in the hub using User-Defined Routes.

Step-by-Step Solution

Analyze the virtual network peering topology and configuration settings.

Two spokes (VNet-Spoke1 and VNet-Spoke2) are peered with a central hub (VNet-Hub). Gateway transit is enabled for both connections.

Understanding the layout is necessary to determine routing behavior.

Evaluate the transitivity of virtual network peering in Azure.

Virtual network peering is non-transitive. Traffic from VNet-Spoke1 cannot transit through VNet-Hub to reach VNet-Spoke2 by default.

To verify if direct spoke-to-spoke connectivity exists via the hub without additional routing configuration.

Determine the effect of 'Allow gateway transit' and 'Use remote gateways' configurations.

These configurations only permit spoke virtual networks to share the hub's VPN or ExpressRoute gateway to access on-premises networks. They do not establish spoke-to-spoke routing.

To assess if the gateway transit settings facilitate the required spoke-to-spoke data plane connectivity.

Conclude the required configuration to enable communication between VM-Spoke1 and VM-Spoke2.

Either a direct peering must be configured between the spokes, or an NVA/Azure Firewall must be deployed in the hub VNet with User-Defined Routes (UDRs) on the spokes to forward traffic.

To verify that additional resources/configurations are indeed required, making the original statement false.

Key Concept

Azure Virtual Network Peering is non-transitive, and gateway transit only applies to VPN/ExpressRoute gateways, not spoke-to-spoke routing.

Estimated Time:2m 0s

Question 823Question →

You are deploying a containerized application to Azure Container Instances (ACI) by using an Azure Resource Manager (ARM) template. You do not define the `restartPolicy` property in the container group definition. The application is designed to execute a one-time data synchronization script and then exit.

What will be the behavior of the container group after the application successfully completes the script and exits with an exit code of 0?

The container group will continuously restart the container, resulting in repeated execution of the script.

The container group will transition to a Succeeded state and terminate without restarting.

The container group will transition to a Failed state because the default policy expects a running process.

The container group will pause the container and remain in a Running state without consuming compute charges.

Show answer & explanation

Answer: The container group will continuously restart the container, resulting in repeated execution of the script.

Answer

The container group will continuously restart the container, resulting in repeated execution of the script.

The correct answer is correct because Azure Container Instances defaults to the 'Always' restart policy when the `restartPolicy` configuration is omitted from the deployment definition. This policy causes the container to restart indefinitely, even after a successful exit (exit code 0), causing the synchronization script to execute repeatedly.

Step-by-Step Solution

Identify the default configuration behavior for ACI restart policies.

When the `restartPolicy` property is not specified in the container group definition, Azure Container Instances defaults to 'Always'.

Understanding default values is crucial for predicting ACI behavior during deployments.

Determine the container's lifecycle outcome based on the default policy.

Under the 'Always' policy, ACI restarts the container whenever it terminates, regardless of the exit code (0 or non-zero).

This determines how ACI responds to the successful completion of the one-time script.

Analyze the operational impact of this restart loop.

The container will loop through execution, termination, and restarting, running the data synchronization script repeatedly and consuming continuous compute resources.

To complete the scenario analysis and select the option describing this continuous restart behavior.

Key Concept

The default restart policy for Azure Container Instances is 'Always', which causes tasks designed to run once and exit to restart continuously if not explicitly configured with 'Never' or 'OnFailure'.

Estimated Time:1m 30s

Question 824Question →

An administrator is configuring network security for a database application in Microsoft Azure. The environment contains the following resources:

* A virtual network named `VNet-Production` with a subnet named `Subnet-Data` ( $10.50.2.0/24$ ).
* A virtual machine named `VM-Database` with a network interface named `nic-db-01` connected to `Subnet-Data` and associated with an Application Security Group named `ASG-Database`.
* A virtual machine named `VM-WebFrontend` associated with an Application Security Group named `ASG-WebFrontend`.

A Network Security Group named `NSG-Subnet` is associated with `Subnet-Data` and contains the following inbound rules:

Priority	Name	Source	Destination	Port	Protocol	Action
100	Allow-Web-to-DB-Subnet	ASG-WebFrontend	ASG-Database	1433	TCP	Allow
1000	Deny-All-Inbound-Subnet	Any	Any	*	*	Deny

A Network Security Group named `NSG-NIC` is associated with `nic-db-01` and contains the following inbound rules:

Priority	Name	Source	Destination	Port	Protocol	Action
150	Deny-Web-to-DB-NIC	ASG-WebFrontend	ASG-Database	1433	TCP	Deny
200	Allow-Web-to-DB-NIC	ASG-WebFrontend	ASG-Database	1433	TCP	Allow

You need to ensure that `VM-WebFrontend` can establish a database connection to `VM-Database` on TCP port 1433. The solution must minimize security risks and administrative effort.

Which of the following actions should you perform?

Change the priority of the Allow-Web-to-DB-NIC rule in NSG-NIC to 120.

Change the priority of the Allow-Web-to-DB-Subnet rule in NSG-Subnet to 250.

Change the priority of the Deny-Web-to-DB-NIC rule in NSG-NIC to 100.

Remove the association between NSG-Subnet and the Subnet-Data subnet.

Show answer & explanation

Answer: Change the priority of the Allow-Web-to-DB-NIC rule in NSG-NIC to 120.

Answer

Change the priority of the Allow-Web-to-DB-NIC rule in NSG-NIC to 120.

The correct action is to change the priority of the Allow-Web-to-DB-NIC rule in NSG-NIC to 120. In Azure, Network Security Group (NSG) rules are processed in priority order: lower numbers have higher precedence. Currently, the Deny rule has a priority of 150 and the Allow rule has a priority of 200. Since 150 is lower than 200, the Deny rule is evaluated first and blocks the traffic. Changing the Allow rule's priority to 120 makes it take precedence over the Deny rule (120 < 150), allowing the traffic to pass the NIC-level NSG.

Step-by-Step Solution

Analyze how inbound NSG rules are evaluated when both subnet and network interface (NIC) associations exist.

Inbound traffic is first evaluated by the subnet-level NSG (NSG-Subnet) and then by the NIC-level NSG (NSG-NIC). Both NSGs must allow the traffic for the connection to succeed.

This determines which NSG is currently blocking the connection.

Evaluate the rules in NSG-Subnet.

The Allow-Web-to-DB-Subnet rule (Priority 100) matches traffic from ASG-WebFrontend to ASG-Database on port 1433 TCP and permits it. The traffic successfully passes the subnet layer.

To verify if the subnet layer is blocking the traffic.

Evaluate the rules in NSG-NIC.

NSG-NIC has two rules for the same traffic: Deny-Web-to-DB-NIC (Priority 150) and Allow-Web-to-DB-NIC (Priority 200). Since 150 is lower than 200, the Deny rule has higher precedence and is processed first, blocking the traffic.

To identify why the traffic is blocked at the NIC layer.

Select the correct action to allow the traffic.

Changing the priority of the Allow rule in NSG-NIC to 120 places it before the Deny rule (Priority 150) in processing order. Thus, the traffic is allowed at the NIC layer.

This resolves the conflict by making the Allow rule take precedence over the Deny rule.

Key Concept

Inbound Network Security Group (NSG) rule processing order and priority evaluation across subnet and network interface levels.

Question 825Question →

An administrator plans to copy files from an on-premises Linux server to a blob container named archives in an Azure storage account named stmigration2026. The storage account has its firewall configured to 'Enabled from selected virtual networks and IP addresses'. The administrator intends to use AzCopy and authenticate using a Microsoft Entra ID user account. Which two configuration steps must you perform to ensure the transfer succeeds? (Select two.)

Select all that apply

Add the public IP address of the on-premises Linux server to the firewall settings of the storage account.

Assign the Storage Blob Data Contributor role to the Microsoft Entra ID user account.

Assign the Contributor role to the Microsoft Entra ID user account at the storage account scope.

Enable the 'Allow trusted Microsoft services to access this storage account' firewall bypass option.

Show answer & explanation

Answer: Add the public IP address of the on-premises Linux server to the firewall settings of the storage account.; Assign the Storage Blob Data Contributor role to the Microsoft Entra ID user account.

Answer

To successfully transfer data using AzCopy with Microsoft Entra ID authentication to a firewall-secured storage account, you must add the public IP address of the on-premises Linux server to the storage firewall and assign the Storage Blob Data Contributor role to the Microsoft Entra ID user account.

To complete the upload, both network connectivity and data authorization must be resolved. Adding the public IP address of the on-premises Linux server to the storage firewall allows the AzCopy client to connect. Assigning the Storage Blob Data Contributor role to the Microsoft Entra ID user account provides the necessary data plane permissions to upload blobs.

Step-by-Step Solution

Configure Network Access

The public IP address of the on-premises Linux server is added to the storage firewall configuration.

Since the storage account has its firewall set to selected networks, network access must be allowed for the client machine running AzCopy.

Configure Data Plane Permissions

The Storage Blob Data Contributor role is assigned to the Microsoft Entra ID account used to authenticate the AzCopy session.

Control plane roles like Contributor or Owner are insufficient for reading or writing data blobs. An explicit data plane role like Storage Blob Data Contributor is needed for authorization.

Key Concept

Authorizing AzCopy data transfers using Microsoft Entra ID and Storage Firewalls

Question 826Question →

You are configuring routing and security for a hub-and-spoke virtual network topology in Microsoft Azure. The topology contains the following networks:

- A hub virtual network (VNet-Hub) with an address space of $10.100.0.0/16$ .
- A spoke virtual network (VNet-Spoke1) with an address space of $10.101.0.0/16$ .
- A spoke virtual network (VNet-Spoke2) with an address space of $10.102.0.0/16$ .

VNet-Spoke1 and VNet-Spoke2 are peered with VNet-Hub. There is no direct peering between VNet-Spoke1 and VNet-Spoke2. You deploy an Azure Firewall in VNet-Hub, which is assigned the private IP address $10.100.4.4$ .

You must meet the following requirements:
- All traffic between VNet-Spoke1 and VNet-Spoke2 must be routed through and inspected by the Azure Firewall.
- All outbound internet traffic from both spoke virtual networks must be routed through and inspected by the Azure Firewall.
- The firewall subnet must be configured according to Microsoft recommendations and support future scalability.

Which three configurations must you perform to meet these requirements? (Select three.)

Select all that apply

Create a subnet in VNet-Hub named AzureFirewallSubnet with an address range of

10.100.4.0/26

or larger, and ensure no Network Security Group (NSG) is associated with this subnet.

In the route table associated with VNet-Spoke1, configure a route for

10.102.0.0/16

and a route for

0.0.0.0/0

, both with the next hop type set to 'Virtual Appliance' and the next hop IP address set to

10.100.4.4

In the route table associated with VNet-Spoke2, configure a route for

10.101.0.0/16

and a route for

0.0.0.0/0

, both with the next hop type set to 'Virtual Appliance' and the next hop IP address set to

10.100.4.4

In the route tables for VNet-Spoke1 and VNet-Spoke2, configure the next hop type as 'Virtual Network Gateway' and specify

10.100.4.4

as the next hop IP address.

In VNet-Spoke1 and VNet-Spoke2, associate a route table containing only a single route for

0.0.0.0/0

with a next hop type of 'Virtual Appliance' and the next hop IP address set to

10.100.4.4

Create a subnet in VNet-Hub named AzureFirewallSubnet with an address range of

10.100.4.0/28

, and associate a Network Security Group (NSG) configured with a high-priority rule to allow all inbound traffic from the spoke networks.

Show answer & explanation

Answer: Create a subnet in VNet-Hub named AzureFirewallSubnet with an address range of $10.100.4.0/26$ or larger, and ensure no Network Security Group (NSG) is associated with this subnet.; In the route table associated with VNet-Spoke1, configure a route for $10.102.0.0/16$ and a route for $0.0.0.0/0$ , both with the next hop type set to 'Virtual Appliance' and the next hop IP address set to $10.100.4.4$ .; In the route table associated with VNet-Spoke2, configure a route for $10.101.0.0/16$ and a route for $0.0.0.0/0$ , both with the next hop type set to 'Virtual Appliance' and the next hop IP address set to $10.100.4.4$ .

Answer

The correct configurations are: creating a subnet in the hub virtual network named AzureFirewallSubnet with a prefix size of at least

/26

and no associated Network Security Group; configuring a route table in VNet-Spoke1 with routes for

10.102.0.0/16

and

0.0.0.0/0

pointing to the firewall's IP as a Virtual Appliance; and configuring a route table in VNet-Spoke2 with routes for

10.101.0.0/16

and

0.0.0.0/0

pointing to the firewall's IP as a Virtual Appliance.

The correct configurations involve creating a subnet named 'AzureFirewallSubnet' in the hub virtual network with a prefix of at least

/26

and no associated NSG, which meets the platform and scalability requirements. To inspect spoke-to-spoke traffic, you must configure UDRs in both VNet-Spoke1 and VNet-Spoke2 that explicitly route the peered spokes' CIDR blocks (e.g., VNet-Spoke1 routing

10.102.0.0/16

and VNet-Spoke2 routing

10.101.0.0/16

) and outbound internet traffic (

0.0.0.0/0

) to the firewall's private IP (

10.100.4.4

) using the 'Virtual Appliance' next hop type.

Step-by-Step Solution

Evaluate the subnet requirements for deploying Azure Firewall.

The firewall must be placed in a dedicated subnet named AzureFirewallSubnet with a prefix size of at least

/26

. It must not have any associated NSGs.

This is a Microsoft platform requirement to ensure scalability, allow updates, and prevent management traffic blockages.

Analyze spoke-to-spoke routing with direct peering and Longest Prefix Match (LPM).

Identify that the system route created by peering (e.g.,

10.102.0.0/16

in VNet-Spoke1) is more specific than a default route (

0.0.0.0/0

In Azure routing, User-Defined Routes (UDRs) are required to override system routes. Because system routes are specific, a simple default route (

0.0.0.0/0

) pointing to the firewall would be ignored for peered VNet traffic. An explicit UDR matching the peered spoke's address space is required.

Configure the route table for VNet-Spoke1.

Add a route for

10.102.0.0/16

and a route for

0.0.0.0/0

, setting the next hop type to 'Virtual Appliance' and next hop IP to

10.100.4.4

This ensures both spoke-to-spoke traffic (destined for VNet-Spoke2) and internet-bound traffic from VNet-Spoke1 are redirected to the firewall.

Configure the route table for VNet-Spoke2.

Add a route for

10.101.0.0/16

and a route for

0.0.0.0/0

, setting the next hop type to 'Virtual Appliance' and next hop IP to

10.100.4.4

This ensures both spoke-to-spoke traffic (destined for VNet-Spoke1) and internet-bound traffic from VNet-Spoke2 are redirected to the firewall.

Key Concept

Azure Firewall routing configuration in a hub-and-spoke topology requires setting up specific UDRs for peered address spaces to override the default system peering routes due to Longest Prefix Match (LPM) rules, alongside configuring the AzureFirewallSubnet with correct naming, sizing, and security constraints.

Estimated Time:3m 0s

Question 827Question →

You plan to deploy Azure Bastion to a virtual network named VNet1. You need to create the dedicated subnet required for the Azure Bastion host. Which subnet configuration should you use?

Name: BastionSubnet; address prefix: /26

Name: AzureBastionSubnet; address prefix: /26

Name: AzureBastionSubnet; address prefix: /27

Name: GatewaySubnet; address prefix: /26

Show answer & explanation

Answer: Name: AzureBastionSubnet; address prefix: /26

Answer

Name: AzureBastionSubnet; address prefix: /26

The correct subnet configuration specifies the name 'AzureBastionSubnet' and has an address space size of /26 or larger. This matches Azure's strict provisioning requirements for the Bastion service.

Step-by-Step Solution

Identify the naming requirement for the Azure Bastion subnet.

The subnet name must be exactly AzureBastionSubnet.

Azure Bastion looks for a subnet with this exact name during deployment; any other name will cause the deployment to fail.

Determine the minimum subnet prefix size requirement.

The minimum prefix size is /26 (which provides 64 IP addresses).

Azure Bastion requires a /26 or larger subnet to accommodate the scaling and internal infrastructure needs of the service.

Select the configuration that satisfies both requirements.

Name: AzureBastionSubnet; address prefix: /26 is the correct choice.

It matches the exact required name and the minimum subnet size requirement.

Key Concept

Azure Bastion subnet configuration requirements

Estimated Time:45s

Question 828Question →

An organization deploys a three-tier architecture in a single Azure virtual network named `VNet-Secure` ( $10.40.0.0/16$ ). The virtual network contains the following subnets:

* `Subnet-Web` ( $10.40.1.0/24$ )
* `Subnet-DB` ( $10.40.2.0/24$ )
* `Subnet-DMZ` ( $10.40.3.0/24$ )

A third-party security firewall operates as a Network Virtual Appliance (NVA) in `Subnet-DMZ` with the private IP address $10.40.3.10$ . By default, Azure system routes allow direct IP communication between all subnets.

You must configure the environment to force all outbound traffic from `Subnet-Web` destined for `Subnet-DB` to traverse the firewall NVA.

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

Select all that apply

Associate a route table with `Subnet-Web` that contains a user-defined route for

10.40.2.0/24

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

10.40.3.10

Enable IP forwarding on the Azure network interface of the firewall Network Virtual Appliance.

Associate a route table with `Subnet-Web` that contains a user-defined route for

10.40.2.0/24

with a next hop type of Virtual Network Gateway and a next hop IP address of

10.40.3.10

Enable IP forwarding on the Azure network interfaces of all virtual machines residing in `Subnet-Web`.

Associate a route table with `Subnet-DMZ` that contains a user-defined route for

10.40.1.0/24

with a next hop type of Virtual Network.

Show answer & explanation

Answer: Associate a route table with `Subnet-Web` that contains a user-defined route for $10.40.2.0/24$ with a next hop type of Virtual appliance and a next hop IP address of $10.40.3.10$ .; Enable IP forwarding on the Azure network interface of the firewall Network Virtual Appliance.

Answer

To force traffic from the Web subnet to the database subnet through the firewall, you must create a route table with a route targeting the database subnet (

10.40.2.0/24

) using the Virtual appliance next hop type with the NVA's IP address (

10.40.3.10

), associate this route table with the Web subnet, and enable IP forwarding on the NVA's network interface.

To successfully route traffic through an NVA, a user-defined route must be configured and associated with the source subnet where traffic originates. The route must specify the destination prefix (in this case, the database subnet

10.40.2.0/24

), set the next hop type to Virtual appliance, and specify the NVA's private IP address (

10.40.3.10

). In addition, the NVA's network interface in Azure must have IP forwarding enabled so that it can forward traffic that is not natively addressed to it.

Step-by-Step Solution

Configure the User-Defined Route (UDR) for the source subnet.

A route table is created and associated with the Web subnet containing a route to the database subnet (

10.40.2.0/24

) via the NVA's IP address (

10.40.3.10

) using the 'Virtual appliance' next hop type.

This overrides the default system route (

10.40.0.0/16

-> Virtual Network) for traffic heading from the Web subnet to the database subnet.

Enable IP forwarding on the NVA's network interface (NIC).

The network interface of the firewall NVA is configured to allow transit traffic.

By default, Azure drops traffic sent to a virtual machine's NIC if the destination IP does not match the IP configured on the NIC. Enabling IP forwarding allows the NVA to receive and forward transit traffic.

Key Concept

Routing traffic through a Network Virtual Appliance (NVA) requires configuring a user-defined route with the 'Virtual appliance' next hop type and enabling IP forwarding on the NVA's network interface.

Question 829Question →

An administrator is configuring network security in an Azure subscription. A virtual network named `VNet1` contains two subnets: `Subnet1` ( $10.200.1.0/24$ ) and `Subnet2` ( $10.200.2.0/24$ ).

* `VM1` (IP address $10.200.1.10$ ) is deployed in `Subnet1`. Its network interface is associated with an Application Security Group named `ASG-App` and a Network Security Group named `NSG-VM1`.
* `VM2` (IP address $10.200.2.20$ ) is deployed in `Subnet2`. Its network interface is associated with an Application Security Group named `ASG-DB` and a Network Security Group named `NSG-VM2`.
* `Subnet1` is associated with a Network Security Group named `NSG-Subnet1`.
* `Subnet2` is associated with a Network Security Group named `NSG-Subnet2`.

The NSG rules are configured as shown in the following tables:

### NSG-VM1 (Outbound Rules)

Priority	Source	Destination	Port	Protocol	Action
$250$	`ASG-App`	`ASG-DB`	$1433$	TCP	Allow

### NSG-Subnet1 (Outbound Rules)

Priority	Source	Destination	Port	Protocol	Action
$200$	`*`	`ASG-DB`	$1433$	TCP	Allow
$300$	`*`	$10.200.2.0/24$	$1433$	TCP	Deny

### NSG-Subnet2 (Inbound Rules)

Priority	Source	Destination	Port	Protocol	Action
$150$	$10.200.1.0/24$	`*`	$1433$	TCP	Deny
$250$	`ASG-App`	`ASG-DB`	$1433$	TCP	Allow

### NSG-VM2 (Inbound Rules)

Priority	Source	Destination	Port	Protocol	Action
$100$	`ASG-App`	`ASG-DB`	$1433$	TCP	Allow

An administrator attempts to establish a TCP connection from `VM1` to `VM2` on port $1433$ .

What is the outcome of this connection attempt?

The connection is blocked by `NSG-Subnet1` because the outbound subnet-level NSG is evaluated before the NIC-level NSG, and the Deny rule with priority

300

takes precedence over the Allow rule in `NSG-VM1`.

The connection is successful because the Allow rule in `NSG-VM2` with priority

100

is evaluated first and overrides the Deny rule in `NSG-Subnet2`.

The connection is blocked by `NSG-Subnet2` because the inbound subnet-level NSG is evaluated before the NIC-level NSG, and the Deny rule with priority

150

takes precedence over the Allow rule with priority

250

The connection is successful because the outbound Allow rule in `NSG-Subnet1` (priority

200

) and the inbound Allow rule in `NSG-VM2` (priority

100

) override all Deny rules.

Show answer & explanation

Answer: The connection is blocked by `NSG-Subnet2` because the inbound subnet-level NSG is evaluated before the NIC-level NSG, and the Deny rule with priority $150$ takes precedence over the Allow rule with priority $250$ .

Answer

The connection is blocked by the subnet-level NSG associated with the destination subnet (`NSG-Subnet2`) because inbound traffic is processed at the subnet layer first, where a matching Deny rule (priority

150

) has higher precedence than the matching Allow rule (priority

250

For inbound traffic, Azure evaluates the subnet-level NSG (`NSG-Subnet2`) before the NIC-level NSG (`NSG-VM2`). Within `NSG-Subnet2`, the inbound rules are processed by priority. The rule with priority

150

(Deny) matches the source IP prefix of `VM1` (

10.200.1.10

) and is evaluated before the rule with priority

250

(Allow). Consequently, the traffic is blocked at the subnet layer and never reaches `VM2`.

Step-by-Step Solution

Evaluate the outbound connection from `VM1` at the network interface (NIC) level.

The traffic is allowed by the NIC-level NSG (`NSG-VM1`) because the outbound rule with priority

250

explicitly matches the source group `ASG-App` and the destination group `ASG-DB` on port

1433

For outbound traffic, Azure evaluates the NIC-level NSG before evaluating the subnet-level NSG.

Evaluate the outbound connection from `VM1` at the subnet level.

The traffic is allowed by the subnet-level NSG (`NSG-Subnet1`) because the outbound rule with priority

200

matches first and allows port

1433

traffic to `ASG-DB`. The lower-priority rule (priority

300

, Deny) is not processed.

Rules are evaluated in order of priority (lower numbers first). Once a match is found, further rules are not processed.

Evaluate the inbound connection to `VM2` at the subnet level.

The traffic is blocked by the subnet-level NSG (`NSG-Subnet2`). The rule with priority

150

matches the source IP range

10.200.1.0/24

on port

1433

and denies the traffic. The rule with priority

250

(Allow) is not evaluated.

For inbound traffic, Azure evaluates the subnet-level NSG first. Since the priority

150

Deny rule has a lower priority number (higher precedence) than the priority

250

Allow rule, the traffic is dropped.

Key Concept

Understanding the sequential evaluation order of Network Security Groups (NIC-level vs. Subnet-level) and the significance of rule priority numbers (where lower numbers have higher precedence) for both inbound and outbound traffic flows.

Question 830Question →

An organization has an Azure environment structured with the following hierarchy:

* Management Group: `MG-Logistics`
* Subscription: `Sub-Shipments`
* Resource Group: `RG-CoreServices`
* Storage Account: `stashipdata`
* Resource Group: `RG-ComputeVets`

You need to configure access for a security group named `Group-LogisticsAdmins` to meet the following requirements:
1. Members of the group must be able to view all resources in the `Sub-Shipments` subscription.
2. Members of the group must be able to upload, download, and delete blobs inside the `stashipdata` storage account.
3. The configuration must follow the principle of least privilege.

Which two role assignments should you configure? (Select two.)

Select all that apply

Assign the Reader role to Group-LogisticsAdmins at the Sub-Shipments subscription scope.

Assign the Storage Blob Data Contributor role to Group-LogisticsAdmins at the stashipdata storage account scope.

Assign the Contributor role to Group-LogisticsAdmins at the RG-CoreServices resource group scope.

Assign the Global Reader role to Group-LogisticsAdmins in Microsoft Entra ID.

Assign the Reader role to Group-LogisticsAdmins at the MG-Logistics management group scope and configure an Azure RBAC deny assignment for the RG-ComputeVets resource group.

Show answer & explanation

Answer: Assign the Reader role to Group-LogisticsAdmins at the Sub-Shipments subscription scope.; Assign the Storage Blob Data Contributor role to Group-LogisticsAdmins at the stashipdata storage account scope.

Answer

The correct assignments are Reader at the Sub-Shipments subscription scope and Storage Blob Data Contributor at the stashipdata storage account scope.

Assigning the Reader role at the subscription scope allows members to view all resources in that subscription, satisfying the first requirement under the principle of least privilege. Assigning the Storage Blob Data Contributor role at the storage account scope provides the necessary read, write, and delete permissions to the storage blob data plane under the principle of least privilege.

Step-by-Step Solution

Identify the role needed to view all resources in the subscription.

The Reader role allows users to view resources but not make changes.

This satisfies the requirement to view all resources in the Sub-Shipments subscription under the principle of least privilege.

Identify the role and scope required to manage blob data in the storage account.

The Storage Blob Data Contributor role at the storage account scope provides read, write, and delete permissions to blob data.

Standard Azure control-plane roles (like Contributor or Reader) do not grant data-plane access to blobs. Scoping this role specifically to the stashipdata storage account adheres to the principle of least privilege.

Verify that all requirements are met and no invalid configurations are used.

Combining Reader at the subscription level and Storage Blob Data Contributor at the storage account level meets all access goals and follows least privilege.

This avoids granting excessive control-plane permissions (like Contributor) and ensures that security settings are scoped correctly.

Key Concept

Azure RBAC differentiates between control-plane and data-plane access. For data-plane operations in Azure Storage, specific roles (like Storage Blob Data Contributor) must be assigned, as control-plane roles (like Reader or Contributor) do not inherit data-plane access. Furthermore, permissions inherit down the scope hierarchy, and custom deny assignments are not supported in user-defined RBAC.

Estimated Time:1m 30s

Question 831Question →

An administrator manages an Azure subscription and configures resource governance. The subscription contains a resource group named `rg-billing-app`. Inside `rg-billing-app`, there are two resources: a Key Vault named `kv-billing-keys` and a Storage Account named `sa-billing-data`.

The administrator configures the following settings:
- A tag named `CostCenter: Finance` and a `ReadOnly` resource lock are applied to `rg-billing-app`.
- A tag named `Environment: Production` and a `CanNotDelete` resource lock are applied directly to `kv-billing-keys`.

Which of the following statements correctly describe the resulting governance state? (Select two.)

Select all that apply

The Storage Account `sa-billing-data` has no tags applied and is protected by an inherited `ReadOnly` resource lock.

Authorized users are prevented from creating new secrets in `kv-billing-keys` because the inherited `ReadOnly` lock combined with the direct `CanNotDelete` lock results in the most restrictive lock applying.

The Key Vault `kv-billing-keys` allows the creation of new secrets because the directly applied `CanNotDelete` lock overrides the inherited `ReadOnly` lock.

To prevent deletion of `sa-billing-data` while allowing configuration updates, you must configure a custom RBAC role with an explicit Deny action at the resource group level.

Show answer & explanation

Answer: The Storage Account `sa-billing-data` has no tags applied and is protected by an inherited `ReadOnly` resource lock.; Authorized users are prevented from creating new secrets in `kv-billing-keys` because the inherited `ReadOnly` lock combined with the direct `CanNotDelete` lock results in the most restrictive lock applying.

Answer

The Storage Account has no tags applied and is protected by an inherited ReadOnly resource lock, and users are prevented from creating new secrets in the Key Vault because the inherited ReadOnly lock combined with the direct CanNotDelete lock results in the most restrictive lock applying.

The correct statements describe that the storage account inherits the ReadOnly lock but does not inherit the CostCenter tag, and that the Key Vault is subject to the ReadOnly lock because locks are cumulative and the most restrictive lock takes precedence over the less restrictive one.

Step-by-Step Solution

Evaluate tag inheritance for the resources.

The Storage Account has no tags applied, and the Key Vault only has the Environment: Production tag applied directly.

Tags applied to a resource group are not inherited by resources within that group.

Evaluate lock inheritance for the Storage Account.

The Storage Account inherits the ReadOnly lock from the resource group, preventing deletion and modification.

Resource locks applied at the resource group level automatically inherit to all resources inside the resource group.

Evaluate the cumulative lock behavior for the Key Vault.

The Key Vault has both a direct CanNotDelete lock and an inherited ReadOnly lock. The effective lock is ReadOnly.

When multiple locks are applied to a resource (directly or inherited), the most restrictive lock takes precedence. ReadOnly is more restrictive than CanNotDelete.

Key Concept

Resource lock inheritance is cumulative where the most restrictive lock applies, whereas tags applied to resource groups do not inherit to child resources.

Question 832Question →

Your organization is planning to deploy an Azure Application Gateway to load balance traffic across multiple backend web servers. You need to prepare the environment and configure the gateway. Organize the configuration steps in the correct sequential order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps to configure the Application Gateway is: first, create a dedicated subnet; second, deploy the gateway instance and its frontend IP; third, define the backend pool; and fourth, configure the routing rule to link the listener to the backend pool.

The correct sequence starts with preparing the network environment by creating a dedicated subnet. Once the network is ready, the Application Gateway resource is provisioned with a frontend IP. Next, the backend pool must be defined to establish the destination targets. Finally, the routing rule is created to link the listener (frontend) to the backend pool (backend).

Step-by-Step Solution

Create a dedicated subnet.

An empty subnet is successfully created in the virtual network.

Azure Application Gateway must reside in its own dedicated subnet that contains no other resources.

Deploy the Application Gateway and configure the frontend IP.

The Application Gateway instance is provisioned and associated with a public or private IP address.

This sets up the gateway resource and defines the IP address where clients will connect.

Configure the backend pool.

A backend pool is created and populated with target virtual machines, scale sets, or IP addresses.

The backend pool defines the destination web servers that will process the incoming requests.

Create the routing rule.

A routing rule binds the frontend listener to the backend pool using backend HTTP settings.

This finalizes the configuration by linking the incoming traffic listener to the target backend servers.

Key Concept

Azure Application Gateway deployment workflow

Estimated Time:1m 0s

Question 833Question →

An administrator is configuring a public Azure Load Balancer named LB1 by using the Standard SKU. LB1 will distribute inbound traffic to two virtual machines named VM1 and VM2. VM1 is a standalone virtual machine that has a Standard SKU public IP address associated with its network interface (NIC). VM2 is a standalone virtual machine that has a Basic SKU public IP address associated with its network interface (NIC). When the administrator attempts to add VM2 to the backend pool of LB1, the operation fails. You need to resolve the issue while ensuring that both virtual machines retain their respective public IP addresses. What should you do?

Upgrade the public IP address of VM2 to the Standard SKU.

Change the SKU of LB1 to Basic.

Move VM1 and VM2 to a new Availability Set.

Associate the Basic SKU public IP of VM2 with the frontend IP configuration of LB1.

Show answer & explanation

Answer: Upgrade the public IP address of VM2 to the Standard SKU.

Answer

Upgrade the public IP address of VM2 to the Standard SKU.

The correct answer is to upgrade the public IP address of the second virtual machine to the Standard SKU. In Azure, a Standard SKU public load balancer requires all network interfaces in its backend pool to be associated with Standard SKU resources. If any of the backend virtual machines have instance-level public IPs assigned directly to their network interfaces, those public IPs must be upgraded to the Standard SKU to avoid a SKU mismatch error.

Step-by-Step Solution

Identify the cause of the configuration failure.

The failure occurs because VM2 has a Basic SKU public IP associated with its NIC, while the load balancer (LB1) is configured as a Standard SKU load balancer.

Azure Standard Load Balancer backend pool members must use Standard SKU public IPs if they have instance-level public IPs assigned directly to their network interfaces. Mixing Basic SKU and Standard SKU resources within the same backend pool configuration is not supported.

Select the resolution that preserves the public IP addresses on both virtual machines.

Determine that upgrading VM2's public IP address from Basic to Standard SKU is the correct method.

Upgrading VM2's public IP SKU resolves the compatibility conflict with the Standard SKU Load Balancer without requiring the deletion of the virtual machine or removal of its public IP interface.

Key Concept

Azure Standard Load Balancer requires all backend pool network interfaces with instance-level public IP addresses to use the Standard SKU.

Estimated Time:2m 0s

Question 834Question →

You are designing the IP addressing scheme for a new Azure virtual network named `vnet-retail-prod` that has an address space of $10.10.0.0/22$ .

You must configure the following subnets:
- A subnet named `AzureBastionSubnet` to deploy an Azure Bastion host.
- A subnet named `snet-app` to deploy exactly $28$ virtual machines.

You need to minimize the address space allocated to each subnet.

Which subnet mask sizes should you assign to `AzureBastionSubnet` and `snet-app`?

`AzureBastionSubnet` with a

/26

prefix; `snet-app` with a

/26

prefix

`AzureBastionSubnet` with a

/26

prefix; `snet-app` with a

/27

prefix

`AzureBastionSubnet` with a

/27

prefix; `snet-app` with a

/26

prefix

`AzureBastionSubnet` with a

/27

prefix; `snet-app` with a

/27

prefix

Show answer & explanation

Answer: `AzureBastionSubnet` with a $/26$ prefix; `snet-app` with a $/26$ prefix

Answer

Assign a

/26

prefix to `AzureBastionSubnet` and a

/26

prefix to `snet-app`.

The correct answer assigns a

/26

prefix to both `AzureBastionSubnet` and `snet-app`. Azure Bastion requires a dedicated subnet named `AzureBastionSubnet` with a minimum prefix size of

/26

. For the application subnet, since we need to support

28

VMs, we must account for the

5

reserved IP addresses that Azure allocates in every subnet. This brings the total minimum IP requirement to

28 + 5 = 33

. A

/27

subnet provides only

32

IP addresses, yielding

27

usable host IPs. Therefore, a

/26

subnet (which provides

64

total IPs and

59

usable host IPs) is the smallest subnet size that can support

28

virtual machines.

Step-by-Step Solution

Determine the minimum subnet size for Azure Bastion.

The subnet must be named exactly `AzureBastionSubnet` and must have a prefix of

/26

or larger.

Microsoft Azure mandates a minimum prefix size of

/26

for the Bastion host subnet to ensure adequate IP availability for scaling.

Calculate the total IP address requirement for `snet-app` including Azure's reserved IPs.

The total required IP addresses is

28 \text{ VMs} + 5 \text{ reserved IPs} = 33

IP addresses.

Azure reserves

5

IP addresses in every subnet: the network address (first IP), the default gateway (second IP), two DNS server IPs (third and fourth IPs), and the broadcast address (last IP).

Select the smallest subnet mask that accommodates the calculated IP requirement for `snet-app`.

/27

subnet provides

32

IP addresses (

27

usable), which is not enough. A

/26

subnet provides

64

IP addresses (

59

usable), which is sufficient.

To minimize the consumed IP address space, we must select the smallest possible CIDR block that fits

33

IP addresses, which is

/26

Key Concept

Azure subnet IP reservation rules and Azure Bastion subnet sizing requirements.

Estimated Time:1m 30s

Question 835Question →

You are configuring a public-facing Azure Load Balancer named `LB1` using the Standard SKU. The load balancer will distribute inbound internet traffic to three standalone virtual machines: `VM1`, `VM2`, and `VM3` located in the same Virtual Network `VNet1`.

The virtual machines are configured as follows:
- `VM1` is deployed in Availability Zone 1. Its primary network interface is associated with a Standard SKU public IP address named `Pip1`.
- `VM2` is deployed in Availability Zone 2. Its primary network interface is associated with a Basic SKU public IP address named `Pip2`.
- `VM3` is deployed in Availability Zone 2 and does not have any public IP address assigned to its network interface.

You need to ensure that `VM1`, `VM2`, and `VM3` can be successfully added to the backend pool of `LB1` and are able to receive load-balanced traffic.

Which two actions should you perform?

Select all that apply

Upgrade Pip2 to a Standard SKU public IP address, or disassociate Pip2 from the network interface of VM2.

Associate a Network Security Group (NSG) with the network interfaces or subnets of the virtual machines, and configure an inbound security rule to allow the load-balanced traffic.

Change the SKU of LB1 from Standard to Basic.

Create and associate a Basic SKU public IP address with the network interface of VM3.

Show answer & explanation

Answer: Upgrade Pip2 to a Standard SKU public IP address, or disassociate Pip2 from the network interface of VM2.; Associate a Network Security Group (NSG) with the network interfaces or subnets of the virtual machines, and configure an inbound security rule to allow the load-balanced traffic.

Answer

The correct configurations are to upgrade the public IP of the second virtual machine to a Standard SKU public IP (or disassociate it), and to associate a Network Security Group (NSG) with the virtual machines' network interfaces or subnets containing an inbound rule that allows the load-balanced traffic.

To successfully deploy virtual machines in the backend pool of a Standard Load Balancer, any public IP addresses directly associated with their network interfaces must match the Standard SKU of the load balancer. Therefore, the Basic SKU public IP on the second virtual machine must be upgraded or disassociated. Additionally, because Standard SKU public IP addresses and Standard Load Balancers are secure by default, a Network Security Group (NSG) must be associated and configured with an inbound rule to allow the load-balanced traffic to reach the virtual machines.

Step-by-Step Solution

Evaluate SKU compatibility for the public IP addresses on the virtual machines.

Identify that the second virtual machine has a Basic SKU public IP assigned to its network interface, which is incompatible with the Standard Load Balancer backend pool.

Azure Standard Load Balancer requires all assigned public IP addresses on backend NICs to use the Standard SKU.

Select the correct action to resolve the public IP SKU mismatch.

Disassociate the Basic SKU public IP from the second virtual machine, or upgrade it to the Standard SKU.

This removes the SKU mismatch restriction and allows the virtual machine to join the Standard Load Balancer backend pool.

Evaluate network security requirements for Standard SKU load balancing.

Acknowledge that Standard Load Balancer frontends and backend pools are secure by default and reject traffic without explicit permissions.

Network Security Groups (NSGs) must be attached to the subnets or network interfaces of the backend VMs, with inbound rules configured to permit the load-balanced traffic.

Analyze why changing the load balancer SKU to Basic is invalid.

Confirm that Basic Load Balancers do not support Availability Zones (which the first virtual machine uses) or backend pools consisting of multiple standalone virtual machines.

Basic Load Balancer backend pools are restricted to a single Availability Set or Virtual Machine Scale Set.

Key Concept

Azure Standard Load Balancer backend pool and IP SKU compatibility, zone redundancy, and default security behaviors.

Question 836Question →

You manage an Azure subscription that contains a private DNS zone named private.contoso.local and three virtual networks named VNet-East, VNet-West, and VNet-Central. Currently, VNet-East has a virtual network link to private.contoso.local with auto-registration enabled. You receive a new requirement to configure the networks to meet the following criteria:
- Virtual machines in VNet-West must be able to resolve names in private.contoso.local and must have their DNS records automatically registered in the zone.
- Virtual machines in VNet-Central must be able to resolve names in private.contoso.local but must not have their DNS records automatically registered.
- Virtual machines in VNet-East must still be able to resolve names in private.contoso.local, but automatic registration of their DNS records is no longer required.

Which administrative action should you perform?

Create a virtual network link from private.contoso.local to VNet-West with auto-registration enabled, and create a virtual network link from private.contoso.local to VNet-Central with auto-registration disabled.

Configure virtual network peering between VNet-East and VNet-West, and create a virtual network link from private.contoso.local to VNet-Central with auto-registration disabled.

Disable auto-registration on the virtual network link for VNet-East, create a virtual network link for VNet-West with auto-registration enabled, and create a virtual network link for VNet-Central with auto-registration disabled.

Configure virtual network peering between VNet-East and VNet-West, and configure virtual network peering between VNet-East and VNet-Central.

Show answer & explanation

Answer: Disable auto-registration on the virtual network link for VNet-East, create a virtual network link for VNet-West with auto-registration enabled, and create a virtual network link for VNet-Central with auto-registration disabled.

Answer

The correct action is to disable auto-registration on the virtual network link for VNet-East, create a virtual network link for VNet-West with auto-registration enabled, and create a virtual network link for VNet-Central with auto-registration disabled. This configuration respects the limit of one auto-registration link per private DNS zone, while ensuring all three networks maintain name resolution access via their individual virtual network links.

Step-by-Step Solution

Modify the existing virtual network link for VNet-East to disable auto-registration.

VNet-East remains linked to private.contoso.local for name resolution, but the auto-registration slot for the private DNS zone is freed up.

An Azure Private DNS zone enforces a strict limit of exactly one virtual network link with auto-registration enabled at any given time.

Create a new virtual network link between private.contoso.local and VNet-West, enabling the auto-registration setting.

VMs in VNet-West can resolve names in the private DNS zone, and their DNS records are automatically created in the zone.

This satisfies the requirement for VNet-West to have both name resolution and automatic record registration.

Create a new virtual network link between private.contoso.local and VNet-Central, leaving the auto-registration setting disabled.

VMs in VNet-Central can resolve names in the private DNS zone, but their records are not automatically registered.

This satisfies the resolution-only requirement for VNet-Central while staying within Azure limits.

Key Concept

Azure Private DNS Zone Virtual Network Links and Auto-Registration Limits

Estimated Time:2m 30s

Question 837Question →

An administrator is configuring a public load balancer named `LB1` to distribute incoming Internet traffic to four virtual machines in a virtual network named `VNet1`.

The virtual machines are deployed as follows:
* `VM1` and `VM2` are in `AvailabilitySet1` and located in `Zone 1`.
* `VM3` and `VM4` are standalone virtual machines and located in `Zone 2`.

The administrator has already created a Standard SKU public IP address named `Pub-IP1` to be used by the load balancer.

You need to configure `LB1` to load balance traffic across all four virtual machines.

Which configuration should you use?

Deploy a Standard SKU load balancer, associate `Pub-IP1` with the frontend IP configuration, and configure the backend pool using the IP address configuration type.

Deploy a Basic SKU load balancer, associate `Pub-IP1` with the frontend IP configuration, and configure the backend pool using the Network interface configuration type.

Deploy a Standard SKU load balancer, associate a new Basic SKU public IP address with the frontend IP configuration, and configure the backend pool using the Network interface configuration type.

Deploy a Basic SKU load balancer, associate a new Basic SKU public IP address with the frontend IP configuration, and configure the backend pool using the IP address configuration type.

Show answer & explanation

Answer: Deploy a Standard SKU load balancer, associate `Pub-IP1` with the frontend IP configuration, and configure the backend pool using the IP address configuration type.

Answer

Deploy a Standard SKU load balancer, associate `Pub-IP1` with the frontend IP configuration, and configure the backend pool using the IP address configuration type.

Deploying a Standard SKU load balancer and associating it with the Standard SKU public IP address `Pub-IP1` satisfies the SKU compatibility requirement. Configuring the backend pool using the IP address configuration type allows the load balancer to target virtual machines across different deployment patterns (standalone and availability sets) within the same virtual network.

Step-by-Step Solution

Determine the required SKU for the load balancer based on the frontend IP address.

Since `Pub-IP1` is a Standard SKU public IP, the load balancer `LB1` must also be a Standard SKU load balancer.

Standard SKU frontend resources (such as public IPs) can only be associated with Standard SKU load balancers.

Analyze the backend pool requirements for mixing standalone virtual machines and virtual machines in an availability set.

The backend pool must contain `VM1` and `VM2` (in `AvailabilitySet1`) along with `VM3` and `VM4` (standalone). This requires the IP address configuration type.

The Network interface configuration type restricts backend pool membership to a single availability set, scale set, or standalone virtual machine. To mix these different resource configurations within the same backend pool, the IP address configuration type must be used, which is supported only on Standard SKU load balancers.

Key Concept

Azure Load Balancer SKU compatibility and backend pool configuration types

Estimated Time:1m 30s

Question 838Question →

An organization has an Azure subscription containing a resource group named rg-hr. Within rg-hr, there is an Azure Storage account named sthrdocs99 that contains a blob container named salaries. A security group named HR-Auditors must be allowed to read the blobs in the salaries container. An administrator assigns the Reader role to the HR-Auditors group at the storage account level. Members of the group report that they can view the storage account properties in the Azure portal but receive an authorization error when they attempt to list or read the blobs. What role assignment should the administrator configure to allow the HR-Auditors group to read the blobs while adhering to the principle of least privilege?

Assign the Storage Blob Data Reader role to the HR-Auditors group at the scope of the salaries container.

Assign the Contributor role to the HR-Auditors group at the scope of the sthrdocs99 storage account.

Assign the Directory Readers Microsoft Entra ID role to the HR-Auditors group.

Assign the Reader role to the HR-Auditors group at the scope of the salaries container.

Show answer & explanation

Answer: Assign the Storage Blob Data Reader role to the HR-Auditors group at the scope of the salaries container.

Answer

Assign the Storage Blob Data Reader role to the HR-Auditors group at the scope of the salaries container.

To read blobs using Microsoft Entra ID authentication, a security principal must be assigned a data plane role such as Storage Blob Data Reader. To enforce least privilege, this role should be scoped to the specific blob container (salaries) rather than the entire storage account.

Step-by-Step Solution

Analyze the access requirements.

The security group requires data plane access (reading blobs) within a specific container.

This establishes that data-plane permissions are needed rather than control-plane management permissions.

Identify the correct role for reading blobs using Microsoft Entra ID.

The Storage Blob Data Reader role is the built-in role designed for read-only data plane access to Azure Blobs.

Standard roles like Reader or Contributor only operate on the control plane and do not grant access to blob data.

Apply the principle of least privilege.

Scope the Storage Blob Data Reader assignment directly to the salaries container rather than the storage account level.

This limits the scope of data access to only the necessary container, satisfying the security requirements.

Key Concept

Separation of control plane and data plane roles in Azure Storage RBAC assignments using Microsoft Entra ID.

Question 839Question →

You are configuring a virtual network named `vnet-iot-ingress` in an Azure subscription. The virtual network is assigned the address space of $10.120.0.0/22$ . You need to create a subnet named `snet-devices` that will host 60 virtual machines. You assign the address range $10.120.2.128/26$ to the `snet-devices` subnet. Is the statement that the `snet-devices` subnet has a sufficient number of usable IP addresses to support the 60 virtual machines true?

True

False

Show answer & explanation

Answer: False

Answer

The statement is false because the subnet only provides 59 usable IP addresses due to Azure reserving 5 IP addresses, which is insufficient for the 60 virtual machines.

The correct evaluation is false because Azure's specific reservation of 5 IP addresses per subnet reduces the usable IP count of a /26 subnet from 64 to 59, which is one address short of the required 60.

Step-by-Step Solution

Calculate the total number of IP addresses in a /26 subnet.

A /26 subnet has

2^{32 - 26} = 2^6 = 64

total IP addresses.

To determine the maximum number of potential addresses before applying reservations.

Subtract the Azure-reserved IP addresses from the total number of addresses.

64 - 5 = 59

usable IP addresses.

Azure reserves 5 IP addresses in every subnet: the first four IP addresses (.128, .129, .130, .131) and the last IP address (.191).

Compare the number of usable IP addresses to the virtual machine requirement.

59 usable IPs is less than the 60 required virtual machines.

To evaluate if the configuration meets the deployment requirement.

Key Concept

Azure Virtual Network Subnet IP Reservations

Estimated Time:1m 30s

Question 840Question →

To support a web application, you plan to configure a public Azure Load Balancer named App-LB. You have three virtual machines: Web-VM1, Web-VM2, and Web-VM3. Web-VM1 is deployed in Availability Zone 1. Web-VM2 is deployed in Availability Zone 2. Web-VM3 is a standalone virtual machine with no zone redundancy. All three virtual machines are located in the same virtual network and subnet. Each virtual machine has a Basic SKU public IP address assigned to its primary network interface. You need to configure App-LB to distribute incoming internet traffic to the three virtual machines. The solution must ensure that traffic can be distributed across all three virtual machines. Which two actions should you perform? (Select two.)

Select all that apply

Deploy the load balancer using the Standard SKU.

Associate Standard SKU public IP addresses with the virtual machines' network interfaces.

Deploy the load balancer using the Basic SKU and group the virtual machines within an Availability Set.

Configure the backend pool of a Basic SKU load balancer by targeting the virtual network and subnet directly.

Show answer & explanation

Answer: Deploy the load balancer using the Standard SKU.; Associate Standard SKU public IP addresses with the virtual machines' network interfaces.

Answer

Deploy the load balancer using the Standard SKU, and associate Standard SKU public IP addresses with the virtual machines' network interfaces.

To support virtual machines deployed across different Availability Zones (Zone 1 and Zone 2) and a standalone virtual machine, you must deploy a Standard SKU Load Balancer. Basic Load Balancers only support virtual machines within a single Availability Set or Scale Set. Furthermore, all public IP addresses associated with the network interfaces of virtual machines in a Standard Load Balancer's backend pool must also be of the Standard SKU; Basic SKU public IP addresses are incompatible and will block standard load balancing configuration.

Step-by-Step Solution

Analyze the virtual machine locations and requirements.

Web-VM1 is in Zone 1, Web-VM2 is in Zone 2, and Web-VM3 is standalone. Because they span multiple Availability Zones and include a standalone VM, a Basic Load Balancer cannot be used since it only supports VMs in a single Availability Set or Scale Set.

This determines that a Standard SKU Load Balancer is required for the deployment.

Verify the compatibility of the public IP addresses on the virtual machines.

The virtual machines currently have Basic SKU public IP addresses. When using a Standard Load Balancer, all network interfaces in the backend pool must use Standard SKU public IP addresses or have no public IP addresses assigned.

Mismatched SKUs between the load balancer and backend resources will cause validation or connectivity errors.

Determine the necessary configuration changes.

The administrator must deploy a Standard SKU Load Balancer and replace or upgrade the virtual machines' Basic public IP addresses to the Standard SKU.

This aligns the configuration with Azure's SKU compatibility rules for Standard Load Balancers.

Key Concept

Azure Load Balancer SKU compatibility and backend pool constraints

Estimated Time:2m 0s

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