Design and implement IP addressing for Azure resources

Bexley Insurance runs a spoke virtual network named vnet-claims (10.61.0.0/20). The claims application uses an Azure App Service plan that needs regional VNet integration to reach a SQL database, the database will be reached through a private endpoint, and the storage account used by the app must be reachable only from the application subnet by using a service endpoint. The team has three subnets planned: snet-app (10.61.1.0/24) for the App Service integration, snet-pe (10.61.2.0/26) for private endpoints, and snet-vm (10.61.3.0/24) for virtual machines.

Which three statements correctly describe how the subnets must be configured? Each correct answer presents part of the solution.

1. Asnet-app must be delegated to Microsoft.Web/serverFarms and must not contain any other resources.Regional VNet integration for App Service requires a subnet delegated to Microsoft.Web/serverFarms, and that delegated subnet is reserved exclusively for the integration.
2. Bsnet-pe must be delegated to Microsoft.Network/privateEndpoints before private endpoints can be created in it.Private endpoints do not use subnet delegation. They can be created in any subnet, including one that also hosts virtual machines.
3. CThe Microsoft.Storage service endpoint must be enabled on snet-app, and the storage account firewall must allow that subnet.A service endpoint is enabled on the source subnet, after which the storage account network rules can allow traffic from that subnet. Both steps are needed.
4. Dsnet-pe can host private endpoints alongside virtual machines; a dedicated subnet is a design preference, not a requirement.A private endpoint consumes one private IP from any subnet in the virtual network. Dedicating a subnet makes NSG management simpler but is optional.
5. Esnet-vm must enable the Microsoft.Sql service endpoint so that the private endpoint in snet-pe can resolve.Private endpoints and service endpoints are independent mechanisms. The private endpoint is reached by its private IP address and does not depend on a service endpoint in any subnet.

Greywater Payments processes card transactions through an acquiring bank that allow-lists source IP addresses in its firewall and charges a change fee for every update. Greywater's Azure environment in Central US adds and removes Standard load balancer frontends and NAT gateway outbound IPs several times a quarter. The company wants to stop sending new IP addresses to the bank while keeping each Azure resource's address static.

What should you implement?

1. ACreate a public IP prefix, create all new public IP addresses from the prefix, and give the bank the prefix range once.Every address allocated from the prefix falls inside a known, contiguous range, so the bank allow-lists the range a single time and later allocations need no change.
2. BCreate Standard public IP addresses with the static allocation method and send each new address to the bank.Standard public IPs are always static, but each is allocated from the regional Azure pool, so each new address is unpredictable and triggers another change at the bank.
3. CUse a custom IP prefix to bring Greywater's own address range into Azure.Bring-your-own-IP solves the problem only if Greywater already owns a routable /24 or larger that it is willing to onboard; the scenario describes a predictability problem, not a requirement to keep an owned range.
4. DPlace all outbound traffic behind a single NAT gateway with one public IP address.A NAT gateway covers outbound flows only; it does not provide addresses for inbound load balancer frontends, and a single IP limits SNAT port capacity.

Marrow Pharmaceuticals is deploying an Azure SQL Managed Instance into a subnet named snet-sqlmi (10.30.8.0/27) in vnet-research. The deployment fails with a validation error referencing the subnet. snet-sqlmi currently has no delegation and already hosts two virtual machines used for testing. The team wants to fix the issue with the least change to the virtual network.

What should you do?

1. AMove the two virtual machines to another subnet, then delegate snet-sqlmi to Microsoft.Sql/managedInstances.SQL Managed Instance requires a subnet delegated to Microsoft.Sql/managedInstances, and a delegated subnet cannot contain resources of other types, so the VMs must be moved first.
2. BDelegate snet-sqlmi to Microsoft.Sql/servers and retry the deployment.Microsoft.Sql/servers is not the delegation the managed instance service requires. The correct delegation value is Microsoft.Sql/managedInstances.
3. CDelegate snet-sqlmi to Microsoft.Sql/managedInstances while the two virtual machines remain in the subnet.SQL Managed Instance needs a subnet reserved for its own use. Delegating it is blocked, or the deployment fails validation, while virtual machine NICs from a different resource type remain in the subnet.
4. DEnable the Microsoft.Sql service endpoint on snet-sqlmi.A service endpoint gives the subnet an optimized route to the public Azure SQL service. It does not satisfy the subnet delegation requirement for deploying a managed instance into the subnet.

Vostrand Telecom owns the public range 203.0.113.0/24, registered with its Regional Internet Registry, and uses it for a customer-facing API that many customers hard-code in firewall rules. The company is migrating the API to Azure in North Europe and must keep the same addresses. The team has created a custom IP prefix resource for 203.0.113.0/24 in North Europe, but public IP addresses cannot yet be created from it, and the range is not reachable from the internet.

Which steps are still required before the range is usable for the API?

1. ACreate a public IP prefix derived from the custom IP prefix, then create public IP addresses from that public IP prefix; advertisement starts automatically when the first address is associated.A derived public IP prefix is needed, but Azure does not advertise a custom IP prefix until you explicitly commission it. Creating addresses alone leaves the range unreachable.
2. BWait for the provisioning state to become Provisioned, then commission the custom IP prefix so Azure advertises the range, and derive a public IP prefix from it to allocate addresses.After validation (ROA pointing at Microsoft ASN 8075 and the signed authorization message) the prefix is Provisioned but not advertised. Commissioning triggers BGP advertisement, and public IP prefixes derived from the custom prefix supply the individual addresses.
3. CSubmit a support request to Microsoft asking them to advertise 203.0.113.0/24 from the North Europe region, then create Standard public IP addresses directly from the custom IP prefix.Commissioning is self-service through the custom IP prefix resource, not a support ticket, and individual public IPs are created from a derived public IP prefix, not directly from the custom IP prefix.
4. DCreate a Route Origin Authorization naming the Azure region, then create a public IP prefix that overlaps the custom prefix in a second region to make it zone-redundant.The ROA names Microsoft's ASN 8075, not a region, and it is a prerequisite for provisioning that has already succeeded here. Prefixes cannot overlap across regions.