Examkin

All practice questions

1252 questions

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

You manage an Azure environment containing a virtual network named `VNet-Prod`. The virtual network has a subnet named `Subnet-App` (10.0.1.0/2410.0.1.0/24).

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

A virtual machine named `VM-App1` is deployed in `Subnet-App` and has a network interface named `NIC-App1`. `NIC-App1` is associated with an NSG named `NSG-NIC`.

An Application Security Group (ASG) named `ASG-App` is created, and `NIC-App1` is associated with `ASG-App`.

`NSG-Subnet` contains the following inbound security rules:
* `Rule-Sub1`: Priority 120120, Source: `Internet`, Destination: `ASG-App`, Destination Port: 443443, Protocol: `TCP`, Action: `Allow`
* `Rule-Sub2`: Priority 150150, Source: `Any`, Destination: `Any`, Destination Port: `Any`, Protocol: `Any`, Action: `Deny`

`NSG-NIC` contains the following inbound security rules:
* `Rule-Nic1`: Priority 110110, Source: `203.0.113.50/32`, Destination: `Any`, Destination Port: 443443, Protocol: `TCP`, Action: `Deny`
* `Rule-Nic2`: Priority 200200, Source: `Internet`, Destination: `Any`, Destination Port: 443443, Protocol: `TCP`, Action: `Allow`

A user attempts to establish an HTTPS connection from a client device on the internet with the public IP address 203.0.113.50203.0.113.50 to `VM-App1`.

What is the status of the connection attempt, and why?

Show answer & explanation

Answer: The connection is blocked at the network interface level because the rule with priority 110 has precedence over the rule with priority 200, resulting in a deny action.

Answer

The connection is blocked at the network interface level because the rule with priority 110 has precedence over the rule with priority 200, resulting in a deny action.
For inbound traffic to an Azure virtual machine, the subnet-level NSG is evaluated first. The traffic is allowed by the rule with priority 120 because the source is 'Internet' (covering the client's public IP address) and the destination is the ASG associated with the virtual machine's NIC. Next, the NIC-level NSG is evaluated. In this NSG, the rule with priority 110 (Deny) is processed before the rule with priority 200 (Allow) because lower numbers have higher precedence. Since the client's IP matches the source IP of the priority 110 rule, the traffic is denied and blocked at the NIC level.

Step-by-Step Solution

1
Evaluate the inbound traffic at the subnet level (NSG-Subnet).
The traffic matches the rule with priority 120 (Rule-Sub1) because the source is 'Internet' (which includes the public IP address), the destination is the ASG associated with the virtual machine, and the port is 443. The action is 'Allow'.
For inbound traffic, subnet-level NSGs are evaluated before NIC-level NSGs. Traffic must be allowed by both levels.
2
Evaluate the inbound traffic at the network interface level (NSG-NIC).
The traffic is matched against rules in ascending order of priority. The rule with priority 110 (Rule-Nic1) is evaluated first because 110 is less than 200. The source IP matches the rule's specific source IP, the destination is 'Any', and the port is 443.
Azure NSG rules are processed in priority order; lower numbers have higher precedence. Once a match is found, further rule processing stops.
3
Determine the final connection state based on the evaluations.
The rule with priority 110 specifies a 'Deny' action. Consequently, the traffic is blocked at the NIC level.
Even though the subnet-level NSG allowed the traffic, the NIC-level NSG blocked it, preventing the connection from completing.

Key Concept

Azure Network Security Group inbound evaluation flow and rule priority precedence.
Question 742Question →

You are deploying an Azure virtual machine named VM1 in the East US region. You plan to configure VM1 using the Custom Script Extension. The script is stored in a private container in an Azure storage account named `storage1`. The firewall for `storage1` is configured to restrict access to selected networks only. You need to ensure that the VM Agent on VM1 can download and execute the script. Which configuration should you implement?

Show answer & explanation

Answer: Configure a service endpoint for `Microsoft.Storage` on the subnet of VM1, and add a virtual network rule to the firewall settings of `storage1` to allow traffic from that subnet.

Answer

Configure a service endpoint for `Microsoft.Storage` on the subnet of VM1, and add a virtual network rule to the firewall settings of `storage1` to allow traffic from that subnet.
Configuring a service endpoint for `Microsoft.Storage` on the virtual machine's subnet allows the virtual machine to securely connect to Azure storage. Adding a virtual network rule to the storage account's firewall to permit traffic from that subnet allows the VM Agent to download the script directly over the Azure backbone network, successfully bypassing the restricted firewall.

Step-by-Step Solution

1
Identify the source of network requests generated by the Custom Script Extension.
The requests originate from the virtual machine's network interface (NIC) inside its designated subnet.
VM extensions execute directly inside the VM's operating system environment.
2
Evaluate the storage firewall settings regarding virtual machine access.
Direct network access from the VM is blocked by default when the storage account restricts access to selected networks, and the VM traffic does not bypass the firewall via the 'trusted Microsoft services' exemption.
The 'trusted Microsoft services' bypass applies to backend service-to-service communications from Azure resource providers, not VM-initiated outbound traffic.
3
Configure secure private routing between the virtual machine and the storage account.
Enabling a service endpoint for `Microsoft.Storage` on the subnet and adding a virtual network rule to the storage account firewall permits traffic from the VM's subnet.
This establishes a direct, secure connection over the Azure backbone network and satisfies the storage firewall's subnet validation.

Key Concept

Virtual Machine extension configuration and secure storage integration
Question 743Question →

You are designing the monitoring and notification architecture for an Azure environment. Match each operational requirement to the most appropriate Azure Monitor alert or notification configuration.

Click a left item, then click its matching right item

Items

Trigger a secure automation workflow in response to a resource group deletion, ensuring that the webhook receiver validates the caller's identity using Microsoft Entra ID.
Deliver immediate, non-intrusive notifications to administrators' mobile devices for CPU spikes on virtual machines located in a region where Azure SMS support is unavailable.
Temporarily disable all Action Group notifications for a specific set of critical virtual machines during a scheduled weekly maintenance window.
Configure an alert on a custom Log Analytics query that runs every 5 minutes, ensuring that only one notification is sent even if the query returns multiple distinct virtual machine failures.

Matches

Show answer & explanation

Answer

Triggering a secure Entra ID authenticated workflow matches with an Action Group with a Webhook action secured by a Microsoft Entra ID App Registration. Delivering mobile alerts where SMS is unavailable matches with an Action Group with an Azure App Push notification. Temporarily disabling notifications matches with an Alert Processing Rule configured with notification suppression. Creating one alert notification for multiple VM failures matches with a Log Search Alert with 'Split by dimensions' disabled.
Matching each scenario to the proper feature ensures secure communication, global reach, simplified maintenance scheduling, and structured log search alert consolidation.

Step-by-Step Solution

1
Analyze webhook security requirements.
Azure Monitor Action Groups support securing webhooks using Entra ID. This requires registering an app in Microsoft Entra ID to allow token verification by the receiver.
Allows the receiver to authenticate incoming webhook requests securely.
2
Evaluate notification channel limits.
SMS alerts are restricted in certain regions and carrier networks. Azure App Push notifications use mobile application push services to deliver alerts globally to devices running the Azure mobile app.
Resolves geographic SMS carrier delivery limitations.
3
Identify suppression mechanisms.
Alert Processing Rules can suppress action groups during maintenance windows without altering the alert rules or the action group definitions.
Simplifies administrative overhead during scheduled downtime.
4
Analyze aggregation behavior in Log Search Alerts.
Disabling the 'Split by dimensions' setting prevents the creation of multiple alerts per dimension value, grouping all log entries into a single alert instance.
Generates a single notification instead of separate notifications per dimension value.

Key Concept

Orchestrating Azure Monitor alerts involves choosing correct delivery channels, managing notifications using Alert Processing Rules, securing webhook actions, and configuring aggregation properties.
Estimated Time:3m 0s
Question 744Question →

You have three virtual networks named VNet-Prod (address space 10.10.0.0/1610.10.0.0/16), VNet-Hub (address space 10.20.0.0/1610.20.0.0/16), and VNet-Shared (address space 10.30.0.0/1610.30.0.0/16). Virtual machines are deployed in the subnets of all three virtual networks to verify connectivity.

You configure virtual network peering between VNet-Prod and VNet-Hub. You also configure virtual network peering between VNet-Hub and VNet-Shared. For both peering connections, 'Allow virtual network access' is enabled, 'Allow forwarded traffic' is disabled, and 'Use remote gateways' and 'Allow gateway transit' are disabled.

An administrator attempts to establish direct network communication between a virtual machine in VNet-Prod and a virtual machine in VNet-Shared.

Which of the following describes the outcome of this network communication?

Show answer & explanation

Answer: The communication will fail because virtual network peering is non-transitive by default, and traffic cannot route from VNet-Prod to VNet-Shared through VNet-Hub.

Answer

The communication will fail because virtual network peering is non-transitive by default, and traffic cannot route from VNet-Prod to VNet-Shared through VNet-Hub.
The correct answer is that the communication will fail because virtual network peering is non-transitive by default. Traffic from VNet-Prod cannot transit through VNet-Hub to reach VNet-Shared unless gateway transit or a network virtual appliance (NVA) is configured.

Step-by-Step Solution

1
Analyze the peering topology.
Identify that VNet-Prod is peered with VNet-Hub, and VNet-Hub is peered with VNet-Shared, but VNet-Prod is not peered with VNet-Shared.
Understanding the direct point-to-point links is necessary to determine routing paths.
2
Check the default peering transitivity behavior.
Acknowledge that Azure virtual network peering is non-transitive, meaning traffic cannot pass through VNet-Hub to go between VNet-Prod and VNet-Shared.
This is the core architectural rule of Azure virtual network peering.
3
Evaluate configuration settings.
Confirm that transit features (gateways/NVA) are not enabled, verifying that no routing path exists between VNet-Prod and VNet-Shared.
To conclude that the VM-to-VM communication will fail.

Key Concept

Azure virtual network peering is non-transitive. Point-to-point connections do not automatically route transit traffic through a middle virtual network unless a gateway or network virtual appliance (NVA) is used along with appropriate routing rules.
Estimated Time:1m 0s
Question 745Question →

You are planning to configure a public Azure Load Balancer to distribute internet traffic to two Azure virtual machines named VM1 and VM2. VM1 is deployed in Availability Zone 1, and VM2 is deployed in Availability Zone 2.

You decide to deploy a Standard Load Balancer.

Which two configurations must you perform to successfully deploy the load balancer and allow traffic to the virtual machines? (Select two)

Select all that apply

Show answer & explanation

Answer: Create a Standard SKU public IP address for the frontend IP configuration.; Associate a Network Security Group (NSG) with the subnets or network interfaces of VM1 and VM2 and allow the inbound traffic.

Answer

To successfully deploy a Standard Load Balancer and allow traffic to the zonal virtual machines, you must create a Standard SKU public IP address for the frontend IP configuration and associate a Network Security Group (NSG) with the subnets or network interfaces of VM1 and VM2 with rules to allow inbound traffic.
The correct configurations require selecting a Standard SKU public IP address and associating a Network Security Group (NSG) to allow inbound traffic. Standard Load Balancer frontend configurations must match the Standard SKU. In addition, Standard Load Balancers are secure by default, meaning that traffic to the backend pool is blocked until explicitly allowed via NSG rules.

Step-by-Step Solution

1
Select the correct Public IP SKU.
Create a Standard SKU public IP address.
Standard Load Balancers require a Standard SKU public IP address for their frontend configuration. Basic SKU public IPs cannot be used.
2
Ensure the Public IP allocation method is compatible.
Configure static allocation for the public IP.
Standard SKU public IP addresses support only static allocation, not dynamic allocation.
3
Configure backend security access.
Associate an NSG with the VMs and add inbound rules to allow traffic.
Standard Load Balancers are secure by default. Unlike Basic Load Balancers which allow all traffic, Standard Load Balancers block all traffic to backend pool members unless explicitly permitted by a Network Security Group.

Key Concept

Azure Load Balancer SKU selection and configuration requirements
Question 746Question →

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

You deploy two virtual machines:
* `VM-Web` in `Subnet-Front`
* `VM-DB` in `Subnet-Back`

The network interface of `VM-Web` is associated with an Application Security Group (ASG) named `ASG-Web`.
The network interface of `VM-DB` is associated with an ASG named `ASG-DB` and a Network Security Group (NSG) named `NSG-NIC-DB`.
`Subnet-Front` is associated with an NSG named `NSG-Front`.
`Subnet-Back` is associated with an NSG named `NSG-Back`.

`NSG-Front` contains the following custom inbound rule:
* Priority: 150150
* Source: Any
* Port: Any
* Destination: Any
* Action: Deny

`NSG-Back` contains the following custom inbound rule:
* Priority: 250250
* Source: Any
* Port: Any
* Destination: Any
* Action: Deny

`NSG-NIC-DB` contains only default rules.

You must configure network security to meet the following requirements:
* Allow HTTPS traffic (TCP port 443443) from the Internet to `VM-Web`.
* Allow `VM-Web` to connect to `VM-DB` on TCP port 14331433.
* Minimize the number of rules and use ASGs where possible.
* Maintain the principle of least privilege.

Which two of the following rules must you add to meet the requirements?

Select all that apply

Show answer & explanation

Answer: In `NSG-Front`, add an inbound rule with priority 100100 that allows TCP port 443443 from Source: Internet to Destination: `ASG-Web`.; In `NSG-Back`, add an inbound rule with priority 200200 that allows TCP port 14331433 from Source: `ASG-Web` to Destination: `ASG-DB`.

Answer

Add an inbound rule in NSG-Front with priority 100 to allow port 443 from Internet to ASG-Web, and add an inbound rule in NSG-Back with priority 200 to allow port 1433 from ASG-Web to ASG-DB.
To satisfy the requirements, two rules must be added. First, a rule in the front-end subnet security group must allow inbound TCP port 443 from the Internet to the web application security group. Because of an existing custom deny rule at priority 150, the new allow rule must have a priority lower than 150 (such as 100) to take precedence. Second, a rule in the back-end subnet security group must allow inbound TCP port 1433 from the web application security group to the database application security group. Because the back-end subnet security group contains a custom deny rule at priority 250, this rule must have a priority lower than 250 (such as 200). Modifying the network interface security group is not required because its default rules already allow virtual network traffic.

Step-by-Step Solution

1
Determine the rule needed to allow inbound HTTPS traffic from the Internet to the web virtual machine.
Since Subnet-Front is associated with NSG-Front, which has a custom Deny rule at priority 150, any new Allow rule must have a priority lower than 150 (e.g., 100). The destination must target ASG-Web.
This ensures the HTTPS traffic is allowed at the subnet level before the custom Deny rule blocks it.
2
Determine the rule needed to allow the web virtual machine to connect to the database virtual machine on port 1433.
The traffic traverses from Subnet-Front to Subnet-Back. Outbound rules allow this by default, but inbound traffic to Subnet-Back is blocked by a custom Deny rule at priority 250 in NSG-Back. Therefore, an inbound rule must be added to NSG-Back with a priority lower than 250 (e.g., 200) that allows traffic from ASG-Web to ASG-DB.
This overrides the subnet-level Deny rule on the destination subnet, permitting the SQL traffic.
3
Evaluate whether any rules need to be added to the network interface security group NSG-NIC-DB.
NSG-NIC-DB only has default rules, which include the AllowVnetInbound rule (priority 65000). Since both subnets belong to the same virtual network, this rule automatically allows the traffic at the NIC level once it passes the subnet NSG.
No additional configuration is required at the NIC level because the default rules already permit intra-VNet communication.

Key Concept

Azure Network Security Group (NSG) rule evaluation order (subnet-level rules before network interface-level rules for inbound traffic) and rule precedence based on priority numbers.
Question 747Question →

An administrator is configuring a public Azure Load Balancer to distribute internet traffic to three standalone virtual machines deployed in the same virtual network. The virtual machines are not configured within an Availability Set. The administrator deploys a Basic SKU Load Balancer, but is unable to add the virtual machines to the backend pool. Which action should the administrator take to resolve this issue?

Show answer & explanation

Answer: Recreate the load balancer as a Standard SKU load balancer.

Answer

Recreate the load balancer as a Standard SKU load balancer.
Recreating the load balancer as a Standard SKU load balancer is the correct solution because the Standard SKU supports any virtual machine in a virtual network as a backend pool member, whereas the Basic SKU requires backend virtual machines to be within the same Availability Set or Virtual Machine Scale Set.

Step-by-Step Solution

1
Analyze the backend pool requirements for a Basic SKU load balancer.
Basic SKU load balancers restrict backend pool members to virtual machines that reside in the same Availability Set or Virtual Machine Scale Set.
To determine why the standalone virtual machines cannot be added to the backend pool.
2
Compare Basic SKU limitations with Standard SKU features.
Standard SKU load balancers support adding any virtual machine within a single virtual network to the backend pool, without requiring an Availability Set.
To identify the correct SKU that supports standalone virtual machines.
3
Select the option that matches the required SKU upgrade.
Recreating the load balancer as a Standard SKU load balancer resolves the issue.
To align the load balancer configuration with the virtual machine deployment architecture.

Key Concept

Azure Load Balancer SKU capabilities and backend pool constraints
Estimated Time:1m 0s
Question 748Question →

You have an Azure subscription that contains a virtual network named VNet1. VNet1 contains two virtual machines named VM1 and VM2. VM1 and VM2 are deployed as standalone virtual machines. VM1 has a public IP address named IP1 assigned directly to its network interface. IP1 is configured with the Basic SKU. VM2 does not have a public IP address. You provision a new public IP address named IP2 configured with the Standard SKU. You plan to create a public load balancer named LB1, use IP2 as the frontend IP configuration, and distribute inbound traffic to VM1 and VM2. You need to configure the load balancer and the virtual machines to support this configuration. Which two actions should you perform?

Select all that apply

Show answer & explanation

Answer: Create LB1 as a Standard load balancer.; Disassociate the public IP address IP1 from the network interface of VM1.

Answer

Create LB1 as a Standard load balancer and disassociate the public IP address IP1 from the network interface of VM1.
To deploy a public load balancer with a Standard SKU public IP frontend that distributes traffic to standalone virtual machines, you must create a Standard load balancer. Furthermore, because Standard load balancers require all instance-level public IP addresses in the backend pool to use the Standard SKU, the Basic SKU public IP address (IP1) currently assigned to the network interface of VM1 must be disassociated.

Step-by-Step Solution

1
Determine the required SKU for the load balancer based on the frontend IP address.
Since the frontend public IP address (IP2) is a Standard SKU, the load balancer (LB1) must also be a Standard SKU load balancer.
Standard SKU public IP addresses can only be associated with Standard SKU load balancers.
2
Determine the required SKU for the load balancer based on the backend pool configuration.
Since VM1 and VM2 are standalone virtual machines, a Standard SKU load balancer is required.
Basic SKU load balancers only support backend instances deployed within a single Availability Set or Virtual Machine Scale Set.
3
Verify and resolve SKU compatibility of public IP addresses on the backend virtual machines.
VM1 has a Basic SKU public IP (IP1) directly assigned. This IP1 must be disassociated from VM1.
Standard SKU load balancers require all public IPs associated with the backend instances to be Standard SKU. A Basic SKU public IP on a backend VM NIC is incompatible.

Key Concept

Standard SKU Load Balancer configuration and resource SKU compatibility constraints.
Question 749Question →

An administrator is configuring autoscale settings for an Azure Virtual Machine Scale Set named `vmss-orders` that uses Uniform orchestration. The scale set currently has a capacity of 44 instances. The upgrade policy is set to Manual.

The administrator configures a scale-out rule to add 22 instances when the average CPU utilization exceeds 75%75\%.

To prevent instance thrashing, where the scale set repeatedly scales out and then immediately scales in under a constant workload, what is the maximum CPU utilization threshold that should be configured for the scale-in rule (which removes 22 instances)?

Show answer & explanation

Answer: 45%45\%

Answer

The correct scale-in threshold is 45%45\%.
Under a constant workload, if 44 instances are running at 75%75\% CPU utilization, the total workload corresponds to 300%300\% CPU capacity. When scaling out to 66 instances, this 300%300\% workload is distributed across all 66 instances, resulting in an average CPU utilization of 50%50\% per instance. To prevent the scale set from immediately scaling back in, the scale-in threshold must be configured below 50%50\%. Therefore, a threshold of 45%45\% is the only option that prevents immediate scale-in and avoids thrashing.

Step-by-Step Solution

1
Calculate the total workload capacity at the scale-out trigger point.
Total workload capacity is 4×75%=300%4 \times 75\% = 300\% CPU equivalent.
This represents the total CPU load generated by the workload running on the initial scale set size.
2
Calculate the distributed average CPU utilization immediately after scaling out.
The new average CPU utilization is 300%÷6=50%300\% \div 6 = 50\%.
Adding 22 instances increases the capacity to 66 instances, which distributes the constant workload.
3
Determine the maximum threshold for scale-in to prevent thrashing.
The scale-in threshold must be strictly less than 50%50\%.
If the threshold is 50%50\% or higher, the scale-in rule triggers immediately, reverting capacity to 44 instances and creating a loop.

Key Concept

Avoiding VMSS instance thrashing by mathematically separating scale-out and scale-in thresholds based on resource utilization redistribution.
Question 750Question →

An administrator deploys two virtual machines named VM-West1 and VM-West2 to the same virtual network. VM-West1 is deployed in Availability Zone 1, and VM-West2 is deployed in Availability Zone 2.

The administrator deploys a public load balancer named LB-App and successfully configures a frontend IP address using a public IP address named IP-App1.

When attempting to configure the backend pool for LB-App, the administrator discovers that both VM-West1 and VM-West2 cannot be added to the same backend pool.

What is the cause of this issue?

Show answer & explanation

Answer: LB-App is configured as a Basic SKU load balancer.

Answer

LB-App is configured as a Basic SKU load balancer.
The correct answer is that the load balancer is configured as a Basic SKU. A Basic SKU load balancer does not support backend pools containing virtual machines distributed across different Availability Zones. To load balance across virtual machines in different Availability Zones, a Standard SKU load balancer must be deployed.

Step-by-Step Solution

1
Analyze the network configuration of the backend virtual machines.
VM-West1 is in Availability Zone 1 and VM-West2 is in Availability Zone 2, meaning they are distributed across different Availability Zones.
This establishes the zonal layout of the resources, which has specific SKU compatibility requirements in Azure.
2
Evaluate the backend pool constraints of Azure Load Balancer SKUs.
Basic SKU load balancers only support backend pools consisting of virtual machines in a single Availability Set or Virtual Machine Scale Set. Standard SKU load balancers support any virtual machines within a single virtual network, including those in different Availability Zones.
This identifies the SKU-specific capability mismatch regarding Availability Zones.
3
Determine the cause of the configuration failure based on the successful frontend setup.
Since IP-App1 was successfully associated with LB-App's frontend, the IP SKU and Load Balancer SKU must match (either both Basic or both Standard). Because zonal VMs cannot be added to the backend pool, the load balancer SKU must be Basic.
Connecting the failure to add zonal VMs to the backend pool confirms that the load balancer is configured with the Basic SKU, which does not support zonal backends.

Key Concept

Azure Load Balancer SKU differences and backend pool constraints regarding Availability Zones.
Question 751Question →

Your company is deploying a high-performance database server on an Azure virtual machine named VM1 in the East US region. The database workload requires sub-millisecond storage latency and up to 50,00050,000 IOPS. You plan to attach an Ultra Disk managed disk to VM1 to meet these requirements. Which configuration is required during the creation of VM1 to ensure you can attach an Ultra Disk to the virtual machine?

Show answer & explanation

Answer: Enable the Ultra Disk compatibility setting on VM1 during deployment.

Answer

Enable the Ultra Disk compatibility setting on VM1 during deployment.
To use Ultra Disks on an Azure virtual machine, you must explicitly enable the Ultra Disk compatibility setting (or the ultraSSDEnabled capability) during the VM creation process. This informs the Azure fabric to allocate the virtual machine on a host that supports the Ultra Disk storage subsystem.

Step-by-Step Solution

1
Select a supported VM size and region for the virtual machine deployment.
VM size and region are selected.
Ultra Disks are only supported in select regions and on specific VM sizes.
2
Enable the Ultra Disk compatibility capability on the virtual machine during configuration.
The additional capability is set to enabled (ultraSSDEnabled = true).
Azure requires this capability to be enabled on the host virtual machine before any Ultra Disks can be attached.
3
Create and attach the Ultra Disk to the virtual machine.
The high-performance Ultra Disk is attached to the VM.
Once the VM capability is enabled, the virtual machine can interface with the Ultra Disk storage subsystem.

Key Concept

Configuring Ultra Disk compatibility during Azure Virtual Machine creation
Estimated Time:1m 30s
Question 752Question →

An organization deploys three virtual networks in the East US region:

* VNet-Hub (10.200.0.0/1610.200.0.0/16): Contains a virtual machine named VM-NVA (10.200.1.410.200.1.4) in the firewall subnet.
* VNet-Spoke1 (10.201.0.0/1610.201.0.0/16): Contains a virtual machine named VM-Spoke1 in the web subnet.
* VNet-Spoke2 (10.202.0.0/1610.202.0.0/16): Contains a virtual machine named VM-Spoke2 in the database subnet.

Bidirectional virtual network peering is established between VNet-Hub and VNet-Spoke1, and between VNet-Hub and VNet-Spoke2. All peering connections currently use default settings:
* Traffic to remote virtual network: Allow
* Traffic forwarded from remote virtual network: Block
* Virtual network gateway: None

A route table is associated with the web subnet of VNet-Spoke1 with a route to `10.202.0.0/1610.202.0.0/16` via Next Hop Type `Virtual appliance` at IP address `10.200.1.410.200.1.4`. A route table is also associated with the database subnet of VNet-Spoke2 with a route to `10.201.0.0/1610.201.0.0/16` via Next Hop Type `Virtual appliance` at IP address `10.200.1.410.200.1.4`. IP forwarding is enabled on the Azure network interface (NIC) and within the operating system of VM-NVA.

You need to ensure that VM-Spoke1 can communicate with VM-Spoke2 through VM-NVA.

Which of the following configurations should you perform?

Show answer & explanation

Answer: Change the 'Traffic forwarded from remote virtual network' setting to Allow on the peering connections between VNet-Hub and both spoke virtual networks.

Answer

Change the 'Traffic forwarded from remote virtual network' setting to Allow on the peering connections between VNet-Hub and both spoke virtual networks.
The correct option is changing the 'Traffic forwarded from remote virtual network' setting to Allow on the peering connections. This is because packets sent from VM-Spoke1 to VM-Spoke2 via VM-NVA maintain their original source IP address. When these packets are forwarded by VM-NVA in VNet-Hub over the peering link to VNet-Spoke2, they are identified as forwarded traffic (since the source IP is in VNet-Spoke1, not VNet-Hub). By default, Azure virtual network peering blocks forwarded traffic. Enabling 'Traffic forwarded from remote virtual network' allows VNet-Hub to forward these packets and the spoke VNets to accept them.

Step-by-Step Solution

1
Analyze the flow of packets from the source to the destination virtual network.
Packets from VM-Spoke1 (10.201.0.0/1610.201.0.0/16) targeting VM-Spoke2 (10.202.0.0/1610.202.0.0/16) are routed to the NVA (10.200.1.410.200.1.4) in VNet-Hub.
Establishing the data path requires determining how packets transit the network topology.
2
Determine the role of VNet Peering in traffic forwarding.
When VM-NVA forwards the packets to VM-Spoke2, the source IP is still from VNet-Spoke1. Thus, the traffic arriving at VNet-Spoke2 from VNet-Hub has a source IP external to VNet-Hub.
Azure classifies any packet whose source IP does not match the virtual network it is arriving from as forwarded traffic.
3
Identify the required peering link settings.
Enable 'Traffic forwarded from remote virtual network' (Allow forwarded traffic) on the peering links to permit the transit of packets that did not originate from the direct peering partner.
By default, Azure blocks forwarded traffic, which stops the NVA from successfully passing traffic between the peered spokes.

Key Concept

Transit routing and forwarded traffic configurations in Azure Virtual Network Peering
Estimated Time:2m 0s
Question 753Question →

An administrator configures application logging for an Azure App Service web app named WebApp1. The administrator enables Application Logging (Filesystem) and sets the level to Information.

Two days later, the administrator notices that application logs are no longer being generated, even though the application is actively processing requests. Other web server logs continue to be written.

What is the most likely cause of this behavior?

Show answer & explanation

Answer: The Application Logging (Filesystem) setting was automatically disabled after 12 hours.

Answer

The Application Logging (Filesystem) setting was automatically disabled after 12 hours.
The correct answer is correct because Azure App Service Application Logging (Filesystem) is explicitly designed for temporary troubleshooting. To prevent local disk space exhaustion, Azure automatically disables this setting exactly 12 hours after it is enabled.

Step-by-Step Solution

1
Identify the type of logging configured for the App Service web app.
The administrator configured Application Logging (Filesystem).
Different logging methods have different retention and lifecycle behaviors.
2
Recall the lifecycle rules for Azure App Service filesystem application logs.
Azure automatically disables Application Logging (Filesystem) 12 hours after it is turned on.
This behavior prevents the local disk from filling up and is designed only for temporary live debugging.
3
Select the option that matches this lifecycle behavior.
The option stating the setting was automatically disabled after 12 hours is correct.
It explains why application logs stopped generating after two days while other logs (which do not have a 12-hour auto-disable feature) continue to write.

Key Concept

Azure App Service Application Logging Lifecycle
Estimated Time:1m 30s
Question 754Question →

You manage an Azure environment that contains a virtual network named `VNet1` (10.100.0.0/1610.100.0.0/16). `VNet1` contains three subnets named `Subnet-Front` (10.100.1.0/2410.100.1.0/24), `Subnet-Back` (10.100.2.0/2410.100.2.0/24), and `Subnet-Security` (10.100.3.0/2410.100.3.0/24).

A network virtual appliance named `NVA1` is deployed in `Subnet-Security` and is assigned the private IP address 10.100.3.1010.100.3.10.

A virtual machine named `VM-Front` (10.100.1.410.100.1.4) is deployed in `Subnet-Front`. Two virtual machines named `VM-Back1` (10.100.2.5010.100.2.50) and `VM-Back2` (10.100.2.20010.100.2.200) are deployed in `Subnet-Back`.

You create a route table named `RT-Front` and associate it with `Subnet-Front`.

You need to ensure that traffic sent from `VM-Front` to `VM-Back1` is routed through `NVA1` for security inspection, while traffic from `VM-Front` to `VM-Back2` bypasses `NVA1` and is routed directly to `Subnet-Back`.

Which routing configuration and VM setting should you implement?

Show answer & explanation

Answer: Configure Route1 in `RT-Front`: Address prefix 10.100.2.0/2410.100.2.0/24, Next hop type: Virtual Appliance, Next hop address: 10.100.3.1010.100.3.10. Configure Route2 in `RT-Front`: Address prefix 10.100.2.128/2510.100.2.128/25, Next hop type: Virtual Network. Enable IP forwarding on the network interface of `NVA1`.

Answer

Configure Route1 with prefix 10.100.2.0/2410.100.2.0/24 using next hop type Virtual Appliance (10.100.3.1010.100.3.10), Route2 with prefix 10.100.2.128/2510.100.2.128/25 using next hop type Virtual Network, and enable IP forwarding on the network interface of `NVA1`.
The correct configuration uses the Longest Prefix Match (LPM) principle. For `VM-Back2` (10.100.2.20010.100.2.200), the /25/25 route (10.100.2.128/2510.100.2.128/25) is a longer match than the /24/24 route, directing it directly to the Virtual Network. For `VM-Back1` (10.100.2.5010.100.2.50), only the /24/24 route (10.100.2.0/2410.100.2.0/24) matches, directing its traffic to `NVA1` (10.100.3.1010.100.3.10). Furthermore, since the NVA forwards traffic not addressed to it, IP forwarding must be enabled on its network interface in Azure.

Step-by-Step Solution

1
Determine the subnet matches for the destination VMs.
VM-Back1 (10.100.2.5010.100.2.50) matches only the 10.100.2.0/2410.100.2.0/24 prefix. VM-Back2 (10.100.2.20010.100.2.200) falls within both the 10.100.2.0/2410.100.2.0/24 and 10.100.2.128/2510.100.2.128/25 prefixes.
Applying CIDR math shows that 10.100.2.128/2510.100.2.128/25 covers IPs from 10.100.2.12810.100.2.128 to 10.100.2.25510.100.2.255, which includes VM-Back2 but excludes VM-Back1.
2
Apply the Longest Prefix Match (LPM) logic to select routes.
VM-Back2 traffic will match Route2 (prefix length 25) over Route1 (prefix length 24) because 25 is a longer subnet mask than 24.
Azure routers prioritize the route with the longest prefix match for any given destination IP.
3
Define next hop types based on requirements.
Set the next hop for Route1 to Virtual Appliance with NVA1's IP (10.100.3.1010.100.3.10), and Route2 to Virtual Network.
This sends VM-Back1 traffic to NVA1 for security inspection and allows VM-Back2 traffic to route directly within the virtual network.
4
Enable IP forwarding on the network virtual appliance.
Configure IP forwarding on the network interface of NVA1.
Azure drops packets by default if the destination IP address does not match the IP of the receiving virtual machine interface. Enabling IP forwarding allows the NVA to receive and forward these transit packets.

Key Concept

User-defined routes (UDR) override system routes. Routing paths are determined using the Longest Prefix Match (LPM) rule. Traffic forwarded through an NVA requires the next hop type to be Virtual Appliance and IP forwarding to be enabled on the NVA's network interface.
Estimated Time:2m 30s
Question 755Question →

An administrator is configuring network routing within a single Azure virtual network named `VNet-Prod` (10.80.0.0/1610.80.0.0/16). The virtual network is segmented into the following three subnets:
* `WebSubnet` (10.80.1.0/2410.80.1.0/24)
* `DatabaseSubnet` (10.80.2.0/2410.80.2.0/24)
* `SecuritySubnet` (10.80.100.0/2410.80.100.0/24)

A firewall virtual machine acting as a Network Virtual Appliance (NVA) is deployed in `SecuritySubnet` and has the private IP address 10.80.100.1010.80.100.10.

The administrator must redirect all network traffic sent from `WebSubnet` targeting the `DatabaseSubnet` through the firewall virtual machine.

Which of the following actions should the administrator perform to route the traffic? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure IP forwarding on the network interface (NIC) attached to the firewall virtual machine.; Associate a route table with WebSubnet that defines a route for 10.80.2.0/2410.80.2.0/24 using a next hop type of Virtual appliance and IP address 10.80.100.1010.80.100.10.

Answer

Configure IP forwarding on the network interface (NIC) attached to the firewall virtual machine, and associate a route table with WebSubnet that defines a route for 10.80.2.0/2410.80.2.0/24 using a next hop type of Virtual appliance and IP address 10.80.100.1010.80.100.10.
To route traffic from the web subnet to the database subnet through the firewall virtual machine, you must create a route table with a user-defined route pointing to the firewall's IP address. This route table must be associated with the subnet containing the source resources (WebSubnet). In the route table, the destination IP prefix must match the target subnet (10.80.2.0/2410.80.2.0/24), and the next hop type must be set to Virtual appliance with the firewall's private IP address as the next hop. Additionally, because the firewall virtual machine is receiving and forwarding network traffic that is not destined for its own IP, IP forwarding must be enabled on its network interface (NIC).

Step-by-Step Solution

1
Identify the source and destination subnets for the traffic redirection flow.
The source subnet is WebSubnet (10.80.1.0/2410.80.1.0/24) and the destination subnet is DatabaseSubnet (10.80.2.0/2410.80.2.0/24).
This establishes where the route table needs to be associated and what the destination prefix for the user-defined route must be.
2
Configure the next hop type and IP address in the user-defined route table.
Create a route targeting 10.80.2.0/2410.80.2.0/24 with a next hop type of Virtual appliance and IP address 10.80.100.1010.80.100.10, then associate the route table with WebSubnet.
A user-defined route overrides the default system route that routes traffic directly between subnets within the virtual network.
3
Enable IP forwarding on the Network Virtual Appliance (NVA).
Enable IP forwarding on the network interface (NIC) of the firewall virtual machine.
Azure virtual machines by default drop traffic that is not addressed to themselves. IP forwarding allows the NVA's NIC to receive and forward transit traffic.

Key Concept

To route traffic through a Network Virtual Appliance (NVA) in Azure, you must define a custom route with a next hop type of Virtual appliance pointing to the NVA's IP, associate it with the source subnet, and enable IP forwarding on the NVA's network interface.
Estimated Time:2m 0s
Question 756Question →

CloudScale Logistics has an Azure subscription named sub-cloudscale-prod. You are configuring customer-managed keys (CMK) for a storage account named sacloudscaleprod. You create a user-assigned managed identity named uami-storage-encrypt. You deploy an Azure Key Vault named kv-cloudscale-prod that uses Azure role-based access control (RBAC) authorization. You must ensure that sacloudscaleprod can encrypt data using a key in kv-cloudscale-prod while meeting security compliance policies. Which of the following actions must be performed to successfully complete the CMK configuration? (Select THREE.)

Select all that apply

Show answer & explanation

Answer: Enable soft-delete and purge protection on kv-cloudscale-prod.; Associate the uami-storage-encrypt managed identity with sacloudscaleprod.; Assign the Key Vault Crypto Service Encryption User role to uami-storage-encrypt at the kv-cloudscale-prod scope.

Answer

To configure customer-managed keys (CMK) using a user-assigned managed identity with Azure RBAC, you must enable soft-delete and purge protection on the key vault, associate the user-assigned managed identity with the storage account, and assign the Key Vault Crypto Service Encryption User role to the managed identity at the key vault scope.
To encrypt storage account data with customer-managed keys using a user-assigned managed identity, three main configurations must be met: first, the Key Vault must have soft-delete and purge protection enabled to safeguard the keys from accidental deletion; second, the user-assigned managed identity must be associated with the storage account to act on its behalf; and third, the identity must be granted the Key Vault Crypto Service Encryption User role on the Key Vault to perform key wrapping/unwrapping. Using these options satisfies the data-plane access requirements and security constraints.

Step-by-Step Solution

1
Configure the Azure Key Vault settings
Soft-delete and purge protection are enabled on kv-cloudscale-prod.
Customer-managed keys in Azure Storage require the Key Vault to have soft-delete and purge protection enabled to protect against accidental key deletion.
2
Configure the Storage Account identity
The user-assigned managed identity uami-storage-encrypt is associated with sacloudscaleprod.
The storage account needs a valid identity reference to authenticate and request access to the Key Vault.
3
Configure Key Vault permissions
The Key Vault Crypto Service Encryption User role is assigned to uami-storage-encrypt at the kv-cloudscale-prod scope.
The storage account's identity needs data plane permissions to read and perform wrap/unwrap key operations on the Key Vault.

Key Concept

Configure Storage Encryption and Customer-Managed Keys using User-Assigned Managed Identity and Azure RBAC
Question 757Question →

An administrator manages an Azure subscription with a virtual network named `VNet1`. `VNet1` contains two subnets:
- `Subnet-Web` (10.0.1.0/2410.0.1.0/24), associated with a Network Security Group (NSG) named `NSG-Web`.
- `Subnet-App` (10.0.2.0/2410.0.2.0/24), associated with an NSG named `NSG-App`.

The following virtual machines are deployed:
- `VM-Web1` (10.0.1.410.0.1.4) and `VM-Web2` (10.0.1.510.0.1.5) in `Subnet-Web`. The network interfaces (NICs) of both VMs are associated with an Application Security Group (ASG) named `ASG-Web`.
- `VM-App1` (10.0.2.410.0.2.4) in `Subnet-App`. Its NIC is associated with an ASG named `ASG-App`.
- `VM-App2` (10.0.2.510.0.2.5) in `Subnet-App`. Its NIC is associated with a dedicated NSG named `NSG-App2-NIC`.

Currently, the NSGs have the following custom rules:
- `NSG-Web` has no custom rules.
- `NSG-App` has a custom inbound rule named `Deny-Web` with priority 150150 that denies all protocols and ports from the `10.0.1.0/24` source to `Any` destination.
- `NSG-App2-NIC` has a custom inbound rule named `Deny-All-Inbound` with priority 120120 that denies all protocols and ports from `Any` source to `Any` destination.

You need to configure the network security to satisfy the following requirements:
1. Allow HTTPS traffic (TCP port 443443) from `VM-Web1` and `VM-Web2` to `VM-App1`.
2. Allow SSH traffic (TCP port 2222) from `VM-Web1` to `VM-App2`.
3. Block all other traffic from `Subnet-Web` to `Subnet-App`.

Which three of the following rules should you configure? (Select three.)

Select all that apply

Show answer & explanation

Answer: In `NSG-App`, add an inbound rule with a priority of 110110 that allows TCP port 2222 traffic from source `10.0.1.4` to destination `10.0.2.5`.; In `NSG-App2-NIC`, add an inbound rule with a priority of 100100 that allows TCP port 2222 traffic from source `10.0.1.4` to destination `10.0.2.5`.; In `NSG-App`, add an inbound rule with a priority of 130130 that allows TCP port 443443 traffic from source `ASG-Web` to destination `ASG-App`.

Answer

The correct configuration requires adding an inbound rule in NSG-App with a priority of 110 to allow TCP port 22 from 10.0.1.4 to 10.0.2.5, an inbound rule in NSG-App2-NIC with a priority of 100 to allow TCP port 22 from 10.0.1.4 to 10.0.2.5, and an inbound rule in NSG-App with a priority of 130 to allow TCP port 443 from ASG-Web to ASG-App.
To satisfy the requirements, the rules must allow the specified traffic before they hit the deny rules at each evaluation layer. HTTPS traffic must be allowed inbound at the subnet level (NSG-App) with a priority of 130 (which is lower/higher precedence than the deny rule at 150) using ASG-Web and ASG-App. SSH traffic from VM-Web1 must be allowed at both the subnet level (NSG-App with priority 110) and the NIC level (NSG-App2-NIC with priority 100) to bypass the respective deny rules at 150 and 120. These rules must target VM-Web1's specific IP address (10.0.1.4) to avoid permitting VM-Web2 to establish SSH connections.

Step-by-Step Solution

1
Evaluate the inbound flow requirements for HTTPS traffic targeting VM-App1.
Outbound traffic from Subnet-Web is allowed by default since NSG-Web has no custom rules. Inbound traffic must pass the subnet-level NSG (NSG-App). Because the Deny-Web rule (priority 150) blocks traffic from 10.0.1.0/24, we must add an inbound rule with a priority lower than 150 (such as 130) allowing TCP 443 from ASG-Web to ASG-App.
This bypasses the Deny-Web rule for the specific web server group and allows them to communicate with VM-App1.
2
Evaluate the subnet-level inbound requirements for SSH traffic targeting VM-App2.
Traffic must pass NSG-App. Since the Deny-Web rule (priority 150) blocks all traffic from Subnet-Web, we must add an inbound rule with a priority lower than 150 (such as 110) that allows TCP port 22 from VM-Web1's specific IP (10.0.1.4) to VM-App2's IP (10.0.2.5).
This allows VM-Web1's SSH traffic through the subnet boundary, while keeping VM-Web2 blocked by the default Deny-Web rule.
3
Evaluate the NIC-level inbound requirements for SSH traffic targeting VM-App2.
The traffic must clear the NIC-level NSG (NSG-App2-NIC). The existing Deny-All-Inbound rule (priority 120) blocks all inbound traffic. We must add an inbound rule with a priority lower than 120 (such as 100) allowing TCP port 22 from 10.0.1.4 to 10.0.2.5.
This allows VM-Web1's SSH traffic to reach the VM's network interface, while all other traffic is blocked by the Deny-All-Inbound rule.

Key Concept

Azure Network Security Groups (NSGs) evaluate rules sequentially using priority numbers, where smaller numbers have higher precedence. Inbound traffic must pass both subnet-level and NIC-level NSGs if both are present. Application Security Groups (ASGs) allow grouping virtual machines to simplify rule definition but cannot bypass priority order or scope evaluation layers.
Question 758Question →

Your company has an Azure subscription named Sub-Development that contains two resource groups named RG-CoreApp and RG-Testing. You need to implement a governance strategy that enforces the following requirements:
* All virtual machines deployed to Sub-Development must include a tag named Environment.
* The Environment tag value must be either Dev or Test.
* Any virtual machine deployment that does not meet these tagging requirements must be prevented.
* Virtual machines deployed to RG-Testing must be allowed to deploy without any tag requirements.

Which two of the following actions should you perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Assign an Azure Policy definition with the Deny effect to the Sub-Development subscription, configured to target resources that do not have the Environment tag set to Dev or Test.; Configure the resource group RG-Testing as an exclusion in the Sub-Development policy assignment.

Answer

To implement this governance strategy, you must assign a policy definition with the Deny effect to the Sub-Development subscription and configure the RG-Testing resource group as an exclusion in that policy assignment.
To block non-compliant resources, a policy definition utilizing the Deny effect must be assigned at the subscription scope. To exempt specific environments from this restriction, the targeted resource group must be added to the policy assignment's exclusion list.

Step-by-Step Solution

1
Select the appropriate policy effect to prevent non-compliant deployments.
The Deny effect is chosen because it actively blocks Resource Manager deployment requests that do not match the defined criteria.
Other effects like Audit or AuditIfNotExists only evaluate compliance and log results, failing to prevent the creation of non-compliant resources.
2
Identify the target assignment scope and bypass requirements.
The policy assignment scope is set to the Sub-Development subscription, and the RG-Testing resource group is specified in the exclusion list.
Exclusions at the policy assignment level stop policy evaluation for all resources within the excluded scope, allowing untagged deployments in the testing resource group.

Key Concept

Azure Policy effects and assignment scope exclusions
Question 759Question →

An organization has a virtual network configured with the address space 172.24.0.0/21172.24.0.0/21. An administrator needs to create a new subnet named `snet-appdev` to deploy exactly 2828 virtual machine instances. The administrator proposes assigning the address prefix 172.24.2.0/27172.24.2.0/27 to the new subnet. Does the proposed address prefix provide a sufficient number of usable IP addresses for the virtual machine instances?

Show answer & explanation

Answer: False

Answer

No, the proposed address prefix does not provide a sufficient number of usable IP addresses.
The correct response is false because a /27/27 subnet provides 3232 total IP addresses. Azure reserves 55 IP addresses in each subnet (the first four and the last one). This leaves 2727 usable IP addresses (32−5=2732 - 5 = 27). Since 2828 virtual machine instances need to be deployed, the subnet is too small.

Step-by-Step Solution

1
Determine the total number of IP addresses in the proposed subnet prefix.
A /27/27 subnet prefix contains 232−27=322^{32-27} = 32 total IP addresses.
To calculate the base pool of IP addresses before reservations.
2
Subtract the Azure-reserved IP addresses from the total.
There are 32−5=2732 - 5 = 27 usable IP addresses.
Azure reserves the first four IP addresses and the last IP address of every subnet for internal services, routing, and DNS.
3
Compare the usable IP addresses with the required host count.
The subnet provides 2727 usable IP addresses, which is less than the required 2828 virtual machines.
To verify if the proposed range satisfies the host deployment constraints.

Key Concept

Azure-specific subnet constraints including the five reserved IP addresses.
Question 760Question →

Your company has an Azure subscription containing a virtual network named `VNet1` (172.16.0.0/16172.16.0.0/16). `VNet1` contains a subnet named `AKS-Subnet` (172.16.1.0/24172.16.1.0/24). You plan to deploy an Azure Kubernetes Service (AKS) cluster named `aks-prod` into `AKS-Subnet`. The cluster configuration must satisfy the following requirements:
- The cluster must start with 33 nodes and support scaling up to 88 nodes.
- Each node must run up to 2828 pods.
- Pods must be assigned IP addresses directly from `AKS-Subnet` to allow direct routing without NAT to an on-premises network connected via ExpressRoute.
- You must prevent IP address allocation failures in the subnet during scaling.

Which configuration should you select to deploy the cluster?

Show answer & explanation

Answer: Deploy the cluster using the Azure CNI network model and set the maximum pods per node to 28.

Answer

Deploy the cluster using the Azure CNI network model and set the maximum pods per node to 28.
Deploying the cluster using Azure CNI and configuring the maximum pods per node to 28 ensures that pods get routable IP addresses directly from the subnet (meeting the no-NAT requirement) while keeping the total IP allocation to 237, which is within the 251 usable IP addresses in the /24 subnet.

Step-by-Step Solution

1
Calculate the number of usable IP addresses in the subnet.
A /24/24 subnet has 256256 total IP addresses. Since Azure reserves 55 IP addresses, the number of usable IP addresses is 256−5=251256 - 5 = 251.
This establishes the upper bound of IP addresses available for the entire AKS cluster deployment (nodes and pods).
2
Evaluate the IP requirements for the Azure CNI network model at maximum scale.
The formula for IP allocation in Azure CNI is: Total IPs Required=Nodes+(Nodes×Max Pods Per Node)+5\text{Total IPs Required} = \text{Nodes} + (\text{Nodes} \times \text{Max Pods Per Node}) + 5. For 88 nodes and 2828 pods per node, the required IPs are: 8+(8×28)+5=8+224+5=2378 + (8 \times 28) + 5 = 8 + 224 + 5 = 237 IP addresses.
To verify if the subnet can support the maximum scale-out scenario of 88 nodes with 2828 pods each.
3
Compare the required IP addresses against the usable IP addresses.
Since 237≤251237 \leq 251, the configuration fits within the subnet. If the default setting of 3030 pods per node were used, the requirement would be 8+(8×30)+5=2538 + (8 \times 30) + 5 = 253 IP addresses, exceeding the available space.
To determine the exact configuration parameter needed to prevent deployment and scaling failures.

Key Concept

Azure CNI IP Address Planning
Estimated Time:2m 30s
PreviousPage 38 / 63Next
All practice questions — Microsoft Azure Administrator (AZ-104) | Examkin