VPC Endpoint practice questions

Azure Cosmos DB

Why it fails: Cosmos DB is a multi-model NoSQL service built for globally distributed document, key-value, column-family, and graph workloads. It exposes SQL/MongoDB/Cassandra-compatible APIs and stores data in partitions, but it has no concept of static files, no web server endpoint, and cannot serve HTML/JS/CSS to browsers as a hosted website.

Azure NetApp Files

Why it fails: Azure NetApp Files is an enterprise-grade file service backed by NetApp ONTAP, providing high-performance NFS and SMB shares for HPC, SAP, and VDI workloads. It operates at the file-system protocol layer over the network and has no HTTP-based content serving, no `$web` container, and no static website hosting capability.

Azure Files

Why it fails: Azure Files provides managed SMB and NFS file shares for lift-and-shift migrations, shared application data, and Azure File Sync scenarios. It presents a standard file share path (e.g., UNC or mount point) and has no HTTP/S static content engine, so it cannot translate a directory of HTML files into a browsable, publicly accessible website.

Use an Azure Load Balancer and configure NSGs on each subnet.

Why it fails: Azure Load Balancer operates at Layer 4 (TCP/UDP) and only distributes traffic based on IP address and port rules. It cannot provide SSL termination, web application firewall (WAF) capabilities, or path-based routing, all of which are essential for protecting and properly routing HTTP(S) requests in a multi-tier web application. Configuring NSGs on each subnet adds basic network-level filtering, but NSGs alone cannot inspect or sanitize application-layer traffic, leaving the web tier vulnerable to SQL injection, XSS, and other OWASP threats. Therefore, this option is incorrect because it lacks the required Layer 7 features.

Use Azure Firewall to inspect all traffic and allow internet traffic to the web tier.

Why it fails: Azure Firewall is a stateful firewall that operates at layers 3-4 with some layer 7 capabilities, but it is not optimized for inbound web traffic with SSL offloading and URL routing like a WAF-enabled service.

Use Azure Front Door to expose the web tier and NSGs for internal isolation.

Why it fails: Azure Front Door is incorrect because it is a global service designed for distributing traffic across multiple regions or public endpoints, whereas this scenario describes a multi-tier application primarily within a single virtual network. While Front Door offers SSL termination, WAF, and URL-based routing, its global scope is not the primary requirement for exposing a web tier residing regionally within a VNet. It would be appropriate for a globally distributed application requiring cross-region traffic management and acceleration.

Set route tables on spoke subnets with a 0.0.0.0/0 route to the Internet

Why it fails: Setting a 0.0.0.0/0 user-defined route on spoke subnets with next hop Internet only affects default outbound traffic, sending it directly to the internet. It does nothing to route spoke-to-spoke traffic through the hub NVA, because inter-spoke traffic targets the peer address space, not the default route. Such a route would actually bypass the hub for any outbound internet traffic and still fail to inspect east-west traffic. Thus this configuration does not enforce centralized inspection for inter-spoke communications.

Configure Azure Firewall in the hub with forced tunneling to on-premises

Why it fails: Forced tunneling with Azure Firewall sends internet-bound traffic to on-premises via a VPN/ExpressRoute connection, typically by adding a default route to the hub's gateway. It does not influence routing between spoke virtual networks, which requires explicit routes to the hub NVA for the destination spoke prefix. Azure Firewall can inspect inter-spoke traffic only when UDRs are applied to spokes with the Firewall's private IP as next hop; forced tunneling alone doesn't set that up. This option confuses internet egress control with east-west traffic inspection.

Use VNet peering with gateway transit enabled

Why it fails: Enabling gateway transit on the hub peering only allows spoke virtual networks to use the hub's VPN/ExpressRoute gateway for connectivity to on-premises networks. It does not create any routes that send spoke-to-spoke traffic through the hub NVA, nor does it make peering transitive. Without UDRs on the spokes, traffic from one spoke to another is dropped at the hub because the spoke has no route to its peer's address space. Gateway transit is a distinct feature for remote gateway access, not a routing mechanism for east-west inspection.

Azure Traffic Manager

Why it fails: Traffic Manager is a DNS-based traffic router that only resolves domain names to endpoint IPs at the DNS level. It cannot terminate SSL, inspect HTTP content, or apply WAF rules, and it lacks URL path-based routing because it never sees the actual traffic. While it can route users globally, it cannot make application-layer decisions or protect the application, so it does not meet the full requirements.

Azure Application Gateway

Why it fails: Application Gateway is a regional Layer 7 load balancer that provides SSL offloading, WAF, and URL path-based routing, but its scope is limited to a single Azure region. It can route traffic among backends within that region but cannot distribute or intelligently route users across multiple geographic regions. For global e-commerce scale and redundancy, you need a multi-region front-end, which Application Gateway alone cannot provide.

Azure Load Balancer

Why it fails: Azure Load Balancer is a Layer 4 network load balancer that forwards TCP/UDP traffic without any awareness of HTTP content. It does not perform SSL termination, cannot inspect URLs for path-based routing, and does not integrate a WAF. Additionally, it is a regional service, so it lacks the global anycast-based edge routing that Front Door offers for worldwide traffic distribution.

Azure Load Balancer (Standard)

Why it fails: Azure Load Balancer (Standard) operates at layer 4 of the OSI model, forwarding TCP and UDP traffic to backend pool members without inspecting HTTP payloads. It cannot offload SSL/TLS termination, so encrypted traffic reaches the VMs unchanged, and it does not inject X-Forwarded-For headers or support URL-path-based routing. Health probes are limited to port availability and simple TCP/HTTP checks, not application-level status, making it inadequate for a modern web application that needs centralized certificate management and session affinity.

Azure Traffic Manager

Why it fails: Azure Traffic Manager is a DNS-based global traffic router, not a proxy; it resolves client requests to an endpoint IP but does not sit in the data path, so it cannot inspect or forward HTTP requests. Because it never handles the actual connection, it cannot perform SSL termination, insert X-Forwarded-For headers, or make routing decisions based on URL paths. It relies on DNS polling and health probes to choose among endpoints, but even an HTTP probe only verifies an endpoint is reachable from Azure's perspective, not the application's health—making it unsuitable for a migration where the gateway must manage HTTPS.

Azure Front Door

Why it fails: Azure Front Door is a global layer-7 load balancer and CDN that does offer SSL termination and a WAF, but it is architected for scenarios requiring edge acceleration across multiple Azure regions via anycast. For a single-region deployment, it introduces unnecessary latency and additional cost because traffic is routed through its global edge network even when all back-ends reside in one region. Front Door also has a different feature set and session-affinity model compared to Application Gateway, so choosing it over a regional gateway complicates troubleshooting and increases operational overhead without corresponding benefit.

Azure Virtual Network with a single subnet and application security groups.

Why it fails: A single subnet offers no Layer-3 separation between tiers; all virtual machines remain in the same broadcast domain and share the same route table and subnet-level policies. Application Security Groups (ASGs) only group VM NICs by workload attributes (for example, 'Web' or 'App') and require explicit NSG rules referencing those ASGs to filter traffic between them, which is essentially logical tag-based control rather than a physical or network boundary. Additionally, ASGs cannot replace subnet segregation for capabilities like service endpoints, route tables, or VNet peering filters, and misconfigurations can leave unexpected traffic flows. This makes the solution less secure and harder to manage at scale, which is why it is incorrect for a three-tier architecture.

Azure Virtual Network with subnets and Azure Firewall.

Why it fails: Azure Virtual Network with subnets provides logical segmentation, but Azure Firewall primarily offers centralised network security policy enforcement and traffic filtering for perimeter security or across virtual network boundaries. While it can filter inter-subnet traffic with User Defined Routes, it is not the most direct mechanism for granular network isolation *between tiers* within a single virtual network. This is typically achieved more precisely using Network Security Groups (NSGs) on each subnet to control ingress and egress traffic flows. Azure Firewall is highly effective for securing internet access and managing outbound traffic from the application.

Azure Virtual Network with subnets and a network virtual appliance (NVA).

Why it fails: While subnets provide basic isolation, an NVA requires complex routing and manual management to enforce granular traffic filtering between tiers. This approach is typically utilised when organisations require third-party security features or deep packet inspection that native Azure Network Security Groups do not offer. In this scenario, the requirement for tier isolation and internet access control is satisfied by using subnets combined with Network Security Groups (NSGs) rather than external appliances.

Deploy an Azure Front Door with WAF policy in front of the AKS cluster. Use Azure Private Link to connect Front Door to the internal load balancer of AKS.

Why it fails: Azure Front Door is a global, anycast-based load-balancing service designed to route traffic across multiple regions. For a single-region AKS deployment, sending traffic through Front Door's edge network adds an unnecessary network hop and introduces latency, while Private Link endpoints to the AKS internal load balancer incur extra cost and configuration complexity. Application Gateway v2, by contrast, is a regional L7 solution that keeps traffic within the region and integrates directly with AKS.

Deploy an Azure Load Balancer with a public IP and install an NGINX ingress controller on AKS. Configure SSL termination on NGINX and use a third-party WAF.

Why it fails: This approach delegates TLS termination, request routing, and web application firewall duties to an NGINX ingress controller and an external third-party WAF running on self-managed infrastructure. The Azure Load Balancer only provides Layer 4 transport rules and does not understand HTTP paths or host headers, so everything above L4 must be manually configured, scaled, and patched by your team. Compared to a managed L7 WAF ingress like Application Gateway, this significantly increases operational overhead and introduces more points of failure for security updates and routing rules.

Deploy an Azure API Management instance with WAF and expose the microservices through API endpoints. Use Azure Application Gateway as a reverse proxy.

Why it fails: Azure API Management is a full API gateway platform designed for publishing, versioning, securing, and monetizing APIs, which is unrelated to the stated requirement of simply exposing internal microservices behind a WAF. If you add it, you are also forced to route traffic through an extra Application Gateway reverse proxy, creating a multi-hop chain that adds latency and cost without business value. For this scenario, a single Application Gateway v2 configured with AGIC directly fronting the AKS services gives you the needed WAF protection and ingress control with far less complexity.

Both servers must be in the same Azure region.

Why it fails: Both servers must be in different regions for geo-replication, not the same region. This is incorrect.

The secondary server must have the same logical server name.

Why it fails: The secondary server must have a different logical server name from the primary. Having the same name is not allowed. This is incorrect.

The databases must be in different elastic pools.

Why it fails: Databases in a failover group can be in the same or different elastic pools; there is no requirement for different pools. This is incorrect.

Use Azure Policy to require storage account encryption with CMK, and use network security groups (NSGs) to restrict storage account access to specific subnets.

Why it fails: NSGs are stateful filtering rules applied to virtual network subnets or network interfaces, and they cannot be directly attached to an Azure Storage account to govern its inbound traffic. While a policy requiring CMK encryption satisfies the encryption requirement, the NSG mechanism does nothing to restrict which clients can reach the storage account's public endpoint; that requires storage firewall rules or service endpoints. As a result, the combination leaves network isolation unenforced and is therefore inadequate for the regulated landing zone.

Deploy Azure Firewall in the hub virtual network and configure application rules to allow only approved storage accounts.

Why it fails: Azure Firewall deployed in the hub virtual network filters traffic routed through it, such as outbound connections from virtual machines to storage account FQDNs, but it has no control-plane authority over resource creation or configuration. Application rules can limit which storage account endpoints VMs can access, yet they cannot deny the deployment of storage accounts or enforce encryption and network settings on the storage service itself. Regulated landing zones require Azure Policy to govern the entire resource lifecycle, not just the posture of workload traffic.

Use Azure Policy to require storage accounts to use private endpoints, and use Azure Private Link to restrict access from specific virtual networks.

Why it fails: This approach uses Azure Policy to require a private endpoint on every storage account, which gives the resource a private IP from a virtual network and removes public exposure, satisfying network isolation. However, the option never addresses encryption at rest; a regulated workload typically requires customer-managed key (CMK) encryption, and without a corresponding policy the storage account could be created with service-managed keys. Additionally, while private endpoints are a strong choice, they are not strictly mandatory when service endpoints plus firewall rules can provide equivalent network restriction, so this incomplete policy set fails to meet the full compliance bar.

Azure Application Gateway

Why it fails: Azure Application Gateway is a regional Layer 7 load balancer, so it can only balance traffic inside a single Azure region and cannot direct users to the healthiest endpoint in another region or continent. It does include WAF and URL path-based routing, but those capabilities are scoped to the gateway's own region, meaning each region would need its own separate gateway, introducing per-region management and DNS complexity. Because the company's requirement is a global AKS deployment, a single Application Gateway would fail to provide cross-region failover or latency-based routing.

Azure Traffic Manager

Why it fails: Azure Traffic Manager operates at the DNS level, answering a client's DNS query with one of the configured endpoints based on a routing method such as priority, weighted, or performance. It cannot terminate SSL, cannot inspect URL paths, and does not provide a WAF, so it is fundamentally incapable of making application-layer decisions or offloading certificate management to the edge. While it can route traffic globally, its reliance on DNS TTL and client caching makes it slower to react to endpoint failures, and it has no concept of path-based routing.

Azure Load Balancer

Why it fails: Azure Load Balancer is a Layer 4 construct that forwards raw TCP/UDP packets to backends based on five-tuple hashing, never looking at HTTP headers or URL paths. It is always scoped to the region where it is deployed and offers no SSL offloading, no WAF integration, and no content-based routing, making it unsuitable for a microservices gateway that needs to inspect requests. Even with multiple regional load balancers, they would not provide a single global control plane or route users to a different region based on latency.

Azure Disk Storage with shared disks

Why it fails: Azure Disk Storage with shared disks relies on SCSI-3 Persistent Reservations to let multiple VMs attach to the same managed disk, but this is intended for clustered workloads like SQL Server Failover Cluster Instances or Windows Server Failover Clustering, not for general-purpose file sharing. Shared disks do not provide an SMB/NFS protocol layer, require premium SSD tiers with specific caching and availability-zone constraints, and lack the access-control and auditing features of a file service. Even if attached to multiple VMs, the shared disk is a raw block device that each VM must format and manage independently, and it cannot be exposed securely to a network without additional infrastructure.

Azure NetApp Files with network security groups

Why it fails: Azure NetApp Files is a fully managed, high-performance NFS/SMB file service, but when paired only with network security groups, it does not guarantee protection from internet exposure because NSGs are applied to subnets or NICs, not to the managed service endpoint itself. The service's public endpoint may still be reachable unless you disable public access and implement a private endpoint or a service endpoint combined with a deny-all NSG rule. Additionally, Azure NetApp Files is significantly more expensive and operationally complex than Azure Files for typical multi-VM file sharing, making it a poor fit for this cost-sensitive migration scenario.

Azure Blob Storage with a service endpoint

Why it fails: Azure Blob Storage is object storage, not a file-sharing protocol; although it can be accessed from VMs via REST or SDKs, it does not natively provide SMB or NFS file semantics like file locking, hierarchical directories, or ACLs that legacy applications expect. A service endpoint routes traffic from a virtual network to the blob service over the Azure backbone, but it does not block internet access by default — the service's public endpoint remains active unless you also disable public access or implement a private endpoint. Even if access is restricted, the application would require extensive code changes to use blob storage instead of a file share, making it an impractical migration path.

Azure Logic Apps

Why it fails: Azure Logic Apps is a workflow orchestration service designed for event-driven integrations, not continuous, high-volume log ingestion. Each log item would require a separate trigger and action execution, introducing transaction costs and processing latency that cannot sustain Entra ID diagnostic log throughput. It also lacks native diagnostic settings integration as a direct streaming destination.

Azure Monitor

Why it fails: Azure Monitor stores logs in a Log Analytics workspace and provides querying, alerting, and visualization, but it does not natively stream outgoing data to an external SIEM. To forward Entra ID logs, you would need to configure diagnostic settings to another destination or use a separate connector/export process, making it an intermediary, not a direct streaming transport.

Azure Storage

Why it fails: Azure Storage (blob or Data Lake) is primarily for low-cost archiving and long-term retention of Entra ID audit logs, not for near real-time streaming. Diagnostic settings can write logs to storage, but there is no push mechanism to a SIEM; extracting data requires periodic polling or batch jobs, introducing significant latency that defeats the purpose of SIEM streaming.

Deploy Azure Firewall in each region and use Public IP prefix for egress.

Why it fails: Deploying Azure Firewall in each region with a Public IP prefix is flawed because Azure Firewall is a regional, stateful security service that inspects network traffic but does not perform global load balancing or geographic routing. While a Public IP prefix ensures predictable outbound egress IPs, it does not solve inbound traffic distribution across regions. This architecture would still require an external DNS or global load balancer to route users, and it lacks the anycast edge capabilities and integrated DDoS protection that a global entry point like Front Door provides.

Deploy Azure Application Gateway v2 with WAF in each region and Azure DDoS Standard protection.

Why it fails: Azure Application Gateway v2 with WAF is a regional Layer 7 load balancer, so even if you deploy one in each region, you must rely on separately configured DNS records or an additional global traffic manager to send users to the correct regional gateway. It does not offer anycast or a single global DNS name for the entire topology, and its geographic routing capabilities are limited to routing within a virtual network, not across regions. Azure DDoS Standard protection is also scoped to a specific public IP in a VNet, not global, so this option fails to provide a unified global edge with DDoS protection at the internet boundary.

Deploy Azure Traffic Manager with geographic routing and Azure DDoS Standard protection.

Why it fails: Azure Traffic Manager is a DNS-based global load balancer that does support geographic routing, but it lacks native DDoS protection because it only resolves DNS names and does not proxy traffic—the actual payload still flows directly to your origin IPs, which remain exposed to L3/L4 DDoS attacks. Additionally, because routing is DNS-dependent, failover is delayed by TTL caching and health probe intervals, and geographic routing policies are applied at DNS resolution time, not per-request, making it less responsive and less secure. This option does not meet the requirement for a secure, globally load-balanced edge with built-in DDoS mitigation, which Front Door provides.

Use only availability zones in one region.

Why it fails: Availability zones are isolated datacenter pods within one Azure region, each with independent power, cooling, and network; deploying across zones protects against a single datacenter failure. But a full regional outage takes down the entire region's shared control plane, network backbone, and utility dependencies, so all zone-redundant resources can become unavailable at once. Thus zone redundancy is a high-availability tactic for failure within a region, not disaster recovery for regional loss.

Use Azure Bastion for failover routing.

Why it fails: Azure Bastion is a PaaS admin-access gateway that provides secure, browser-based RDP/SSH sessions to Azure VMs via TLS; it does not inspect application traffic or make routing decisions. It lacks health probes, origin selection, priority rules, and any data-plane connection to user requests, so it cannot reroute user traffic when a region fails. Using it for failover routing confuses administrative plane connectivity with the application data plane and would leave users with no failover at all.

Use Microsoft Graph API to write a custom provisioning solution

Why it fails: Using Microsoft Graph API to write a custom provisioning solution would require you to build, test, host, and maintain a custom service to handle user sync. This is unnecessary because Microsoft Entra ID natively supports SCIM-based automatic provisioning for applications that expose a SCIM endpoint, including incremental updates, retry logic, and logging. A custom Graph integration would also need to implement handling for idempotency and conflict resolution, which are already built into the provisioning service.

Configure Microsoft Entra B2B collaboration for the application

Why it fails: Microsoft Entra B2B collaboration is designed for inviting external guest users from other organizations into your tenant for access to your applications and resources, not for creating or managing accounts inside a third-party SaaS application. It operates at the identity federation level between tenants, so it does not install or maintain any user records in the target application's own user store. Therefore, it cannot address the need to provision and synchronize user lifecycle events for an internal application user base.

Publish the application using Microsoft Entra Application Proxy

Why it fails: Microsoft Entra Application Proxy acts as a reverse proxy that provides remote access to on-premises web applications, applying pre-authentication and conditional access policies. It does not communicate with or mutate the user directory of an external SaaS application, and there is no mechanism for it to create or update user records. As such, it is entirely unrelated to identity lifecycle provisioning, which is a distinct workload handled by the provisioning service.

The storage account is configured to require HTTPS traffic only.

Why it fails: Requiring HTTPS traffic only is the storage account's secure transfer setting, which is enabled by default in newer accounts. It forces all data plane requests to use TLS, but the Azure portal always communicates over HTTPS to storage endpoints, so this setting does not prevent portal access. Instead, portal access would be blocked by network rules, not by transport encryption.

The minimum TLS version is set to TLS 1.2, which is not supported by the portal.

Why it fails: Setting the minimum TLS version to TLS 1.2 is a supported, recommended configuration for storage accounts. The Azure portal and all current browsers support TLS 1.2 (and often 1.3), so this does not block portal access. This setting only enforces the security protocol for client-to-storage data plane traffic after network access has been granted; it cannot be the cause of a denial at the ACL layer.

The encryption key source is set to Microsoft.Storage, which prevents portal access.

Why it fails: Choosing Microsoft.Storage as the encryption key source means Azure-managed keys automatically encrypt the storage account at rest. This setting has no effect on network reachability or the ability of the portal to perform either control-plane or data-plane operations. Portal access is governed by network ACLs, public endpoint settings, and authentication, not by who holds the encryption key.

Azure Front Door with WAF, Azure SQL Database point-in-time restore, Azure Key Vault Managed HSM, Azure App Service with private endpoint, AKS with HPA, Azure Log Analytics agent, Microsoft Entra ID

Why it fails: Point-in-time restore does not guarantee an RPO of 5 minutes or an RTO of 1 hour; it is a backup restore solution, not a high-availability failover. Although it uses private endpoint and HPA, the database requirement is not met.

Azure Front Door with WAF, Azure SQL Database geo-replication, Azure Key Vault (Standard), Azure App Service with private endpoint, AKS with HPA, Azure Diagnostics extension, Microsoft Entra ID

Why it fails: This design fails the requirement for customer-managed keys stored in a managed HSM because Azure Key Vault (Standard) only supports software-protected keys, not the FIPS 140-2 Level 3 validated hardware security modules provided by Azure Key Vault Managed HSM. While the option correctly uses AKS with HPA for CPU-based scaling and SQL Database geo-replication, the key vault type is the critical compliance blocker for a financial services workload. Azure Front Door with WAF and private endpoint are acceptable, but the key management deficiency cannot be mitigated by the other components.

Azure Application Gateway with WAF, Azure SQL Database active geo-replication, Azure Key Vault Managed HSM, Azure App Service with VNet integration, AKS with cluster autoscaler, Azure Monitor Agent, Microsoft Entra ID

Why it fails: Cluster autoscaler scales the number of node VMs, not pod replicas, and does not respond to CPU utilization of pods, failing the requirement for automatic scaling based on CPU utilization. Although it meets other requirements, the scaling requirement is critical.

Azure Front Door

Why it fails: Azure Front Door is tempting as it provides a single global DNS endpoint, automatically routes traffic to the nearest healthy region based on latency, and offers failover for high availability, which aligns with several requirements for a global web application. However, it fails to meet the specific requirement for routing traffic based on "available capacity". Front Door primarily uses latency-based routing and health probes, not dynamic load-based distribution across regions to account for current capacity constraints, which is a key distinction for this scenario.

Azure Load Balancer

Why it fails: Azure Load Balancer is a regional, layer-4 network load balancer that distributes traffic within a single Azure region and a single virtual network. It cannot route or redirect traffic across multiple regions because it has no DNS-based or global endpoint capability, and its health probes only monitor VMs in its own backend pool. Therefore, it fails to provide the cross-region capacity-based routing required for a multi-region VM deployment.

Azure Application Gateway

Why it fails: Azure Application Gateway operates at Layer 7 (HTTP/HTTPS) and is deployed within one region, providing SSL termination, path-based routing, and WAF capabilities for regional web traffic. While it can perform sophisticated request routing based on URL and host headers, it lacks a global DNS-based traffic management layer and cannot direct users to the nearest or most available regional deployment. Its backend pools are confined to a single region, so it cannot satisfy the requirement for routing across multiple regional VM deployments based on available capacity.

A public IP address with NSG rules

Why it fails: Assigning a public IP to the database and filtering access with NSG rules does not make the PaaS database private. Azure SQL Database and similar PaaS services expose their standard endpoint on a public IP that is controlled by Azure's firewall rules, while NSGs act only on VNet subnets and NICs, not on the PaaS service itself. Even if source IP restrictions narrow who can reach it, traffic still traverses the public internet to a public endpoint, so this design fails the requirement for private, VNet-only connectivity.

A route table to the internet gateway

Why it fails: A route table cannot privatize PaaS endpoints because Azure has no 'internet gateway' component to target, and user-defined routes simply influence the next hop for traffic leaving a subnet (such as to a virtual appliance or the internet). The database's public DNS name would still resolve to a public IP unless a private endpoint and a private DNS zone intercept it, and routing alone does not change name resolution or service exposure. In fact, with a private endpoint in place, routing is handled automatically by a system route for the private IP prefix, making this option both incorrect and irrelevant to true private access.

Azure CDN endpoint

Why it fails: An Azure CDN endpoint caches web content at edge locations to improve latency and offload origin servers; it does not provide a private address or route into a VNet for database connections. Database protocols such as TDS are transactional and stateful, not designed for edge caching, so CDN cannot pass through or optimize them. Consequently, deploying a CDN endpoint would not create private connectivity and could actually break database connectivity if traffic was redirected.

Use Azure Private Link for the web app and disable public access.

Why it fails: Private Link ensures traffic between Application Gateway and App Service remains within the Microsoft backbone, but it fails to restrict access solely through the Gateway because any resource within the same virtual network or a peered one can also reach the private endpoint directly, violating the requirement that the web app be accessible only via the Gateway. This option is tempting because Private Link is the standard method for privatising Azure PaaS services and eliminating public internet exposure, and would be correct if the goal were simply private connectivity without granular source restriction.

Deploy Azure Firewall in front of the Application Gateway.

Why it fails: Deploying Azure Firewall in front of the Application Gateway adds a stateful, centralized NVA that inspects and filters traffic, but it does nothing to secure the network path between the Application Gateway and the App Service. It also introduces significant operational overhead and hourly cost for a use case that can be handled with a simple subnet restriction. Azure Firewall is typically used for multi-tenant filtering or egress control, not to replace Service Endpoints for private PaaS connectivity from a specific gateway subnet.

Use a site-to-site VPN between the App Service and Application Gateway.

Why it fails: A site-to-site VPN is an IPsec tunnel designed to connect an on-premises network to a virtual network; it cannot be established from an App Service instance, which is a multi-tenant PaaS service and does not terminate VPN tunnels. The Application Gateway and App Service would already be in the same Azure region, so routing traffic through an on-premises VPN endpoint would add latency and complexity without any security benefit. This option conflates hybrid networking with intra-Azure connectivity and does not satisfy the access-restriction requirement.