Skip to main content

Technical Lab: Configure Public IP Addresses

Questions​

Question 1 — Multiple Choice​

An operations team needs to ensure that a critical service published in Azure always maintains the same IP address, even after VM reboots and recreations of the associated resource. When creating the Public IP Address resource, which combination of settings meets this requirement?

A) Basic SKU, Dynamic assignment B) Basic SKU, Static assignment C) Standard SKU, Dynamic assignment D) Standard SKU, Static assignment

Question 2 — Technical Scenario​

An administrator created a VM in Azure and associated a Basic SKU Public IP Address to it. Later, the team decided to migrate to a Standard SKU Azure Load Balancer to improve resilience. When trying to associate the same Public IP to the Standard Load Balancer, the operation fails with an incompatibility error.

What is the root cause of the problem and what should be done to resolve it?

A) The Basic IP needs to have its assignment changed from Dynamic to Static before being associated to a Standard resource. B) Basic SKU IPs and Standard SKU resources are incompatible; it's necessary to create a new Standard SKU Public IP. C) The Standard Load Balancer requires the IP to be in a different availability zone from the VM. D) The Basic IP must be disassociated from the VM for at least 30 minutes before being reused on another resource.

Question 3 — True or False​

A Standard SKU Public IP Address, when created without association to any resource, already blocks all inbound traffic by default, requiring an explicit Network Security Group (NSG) rule to allow any communication.

True or False?

Question 4 — Technical Scenario​

An administrator executes the following command to create a Public IP and associate it to an existing network interface:

az network public-ip create \
  --resource-group rg-prod \
  --name pip-webapp \
  --sku Standard \
  --allocation-method Dynamic \
  --zone 1 2 3

az network nic ip-config update \
  --resource-group rg-prod \
  --nic-name nic-webapp \
  --name ipconfig1 \
  --public-ip-address pip-webapp

The command is accepted without errors, but the IP behavior in production is not as expected: the address changes after maintenance events. What is the problem?

A) The --zone parameter is not compatible with Standard SKU and was ignored by Azure. B) Standard SKU with Dynamic assignment is not a valid combination; Azure silently applies Static assignment only in some scenarios. C) Standard SKU requires Static assignment; the combination with Dynamic in the command results in behavior equivalent to Basic SKU. D) Azure accepts the --allocation-method Dynamic parameter during creation, but Standard SKU only supports Static assignment; the IP behaves as dynamic until explicitly reassigned as static.

Question 5 — Multiple Choice​

When planning a zone-failure resilient architecture in Azure, an architect needs to decide how to configure public IP addresses for resources. Which statement correctly describes Availability Zones support for Public IP Addresses?

A) Only Standard SKU IPs created with zone redundancy ensure that the IP address persists even if an entire zone fails. B) Basic SKU IPs support zone redundancy when associated to a resource that is already configured as zone-redundant. C) Standard SKU IPs with specific zone (zonal) offer greater resilience than IPs with zone redundancy (zone-redundant). D) Zone configuration in Public IP Addresses is optional in Standard SKU and mandatory in Basic SKU to ensure high availability.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: D

Standard SKU with Static assignment is the only combination that guarantees the IP address remains permanently fixed, regardless of the lifecycle of the associated resource. Basic SKU with Static assignment also preserves the IP while the resource exists, but Standard SKU is the requirement for production scenarios with Load Balancer, availability zones, and other modern resources. Dynamic assignment, in any SKU, does not guarantee IP persistence after deallocations or recreations. The most common error here is confusing "static" with "Standard SKU": these are independent dimensions, but both are necessary for the complete guarantee described in the statement.

Answer Key — Question 2​

Answer: B

Azure enforces a strict SKU compatibility restriction: Standard SKU resources (Load Balancer, VM, Gateway) only accept Standard SKU Public IP Addresses. There is no in-place migration from Basic SKU to Standard; the resource needs to be recreated. Alternative A is plausible, but incorrect: changing assignment does not resolve SKU incompatibility. Alternative D is false: there is no waiting period for reuse. This restriction is a frequent source of errors in environments that grew with Basic IPs and began adopting Standard resources.

Answer Key — Question 3​

Answer: True

Standard SKU IPs are secure by default: all inbound traffic is blocked until an NSG is explicitly configured to allow the desired flow. This behavior differs from Basic SKU, which allows inbound traffic by default. Understanding this difference is critical in migrations: a service that worked with Basic IP may stop responding after migration to Standard IP if the NSG is not adjusted. The default isolation of Standard SKU is a security posture decision, not a technical limitation.

Answer Key — Question 4​

Answer: D

Standard SKU supports only Static assignment. When the --allocation-method Dynamic parameter is passed along with --sku Standard, Azure CLI accepts the command without explicit error in some versions, but the address behaves inconsistently until corrected. The correct and documented combination for Standard SKU is always --allocation-method Static. Alternative C is the most dangerous distractor: although it describes erratic behavior, the cause is not "equivalence with Basic SKU", but rather the silently ignored invalid configuration. In production, this causes IP address rotation exactly in the maintenance scenarios described in the statement.

Answer Key — Question 5​

Answer: A

Only Standard SKU supports integration with Availability Zones. An IP configured as zone-redundant is replicated across the three zones in the region and persists even if an entire zone fails. An IP configured as zonal (anchored to a specific zone) offers less resilience than zone-redundant, as it fails along with the zone. Basic SKU does not support availability zones in any form, regardless of the associated resource. Distractor B is technically impossible. Distractor C inverts the logic: zone-redundant is always more resilient than zonal for total zone failure scenarios.