Merge pull request #311841 from Harikrishnan-M-B/newfaqs

Newfaqs

Author: prmerger-automator[bot]

articles/frontdoor/front-door-faq.yml

@@ -127,6 +127,10 @@ sections:
           Can AFD provide protection from ‘HTTP/2 Rapid Reset’ DDoS attacks?
         answer:  |
           Yes. For more information, see [Microsoft response to DDoS attacks against HTTP/2](front-door-ddos.md).
+      - question: |
+          Can I force traffic from one country/region to use a specific Azure Front Door POP in another country/region?
+        answer:  |
+          No. Azure Front Door can't force client traffic to a specific POP. Requests are routed to the nearest available edge location for performance and reliability. If you need to restrict access by geography, use Azure Web Application Firewall (WAF) custom rules with `GeoMatch` conditions. This approach allows or blocks requests based on client country/region, but it doesn't reroute those clients to a different POP in another country/region. For example, if you block country/region A, requests from clients in country/region A are blocked regardless of which POP would have served them. For more information, see [Geo-filtering in Azure WAF for Azure Front Door](../web-application-firewall/afds/waf-front-door-geo-filtering.md).
       - question: |
           Does Azure Front Door preserve `x-forwarded-for` headers?
         answer: |
@@ -138,6 +142,21 @@ sections:
         answer:  |
           To use Azure Front Door Standard, or (classic) tier, you need a public IP or a DNS name that can be resolved publicly. This requirement of a public IP or a DNS name that can be resolved publicly allows Azure Front Door to route traffic to your backend resources. You can use Azure resources like Application Gateways or Azure Load Balancers to route traffic to resources in a virtual network. If you use Front Door Premium tier, you can use Private Link to connect to origins behind an internal load balancer with a private endpoint. For more information, see [Secure origins with Private Link](private-link.md).
 
+      - question: |
+          Can I use Private Link to connect Azure Front Door to Azure Key Vault?
+        answer: |
+          No. For security, Azure Front Door supports only managed identity-based authentication when accessing certificates in Key Vault. For more information, see [Use managed identities in Azure Front Door](managed-identity.md).
+
+      - question: |
+          Does Azure Front Door support managed identity with Azure Event Hub?
+        answer: |
+          No. Azure Front Door doesn't currently support managed identity integration with Azure Event Hub.
+
+      - question: |
+          Does Azure Front Door support custom error pages?
+        answer: |
+          No. Azure Front Door doesn't currently support custom error pages.
+
   - name: Deploying Front Door with other services
     questions:
       - question: |
@@ -244,7 +263,7 @@ sections:
       - question: |
            Azure Front Door Privatelink integration is not supported in the region where my origin is located. What do I do?
         answer:  |   
-           Azure Front Door Private Link feature is region agnostic and will work even if you choose a region that is different from the region where your origin is located. In such cases, to ensure lower latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. We are in the process of enabling support for more regions. Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
+          The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region isn't supported in the list of regions Front Door Private Link supports, pick the next nearest region. Traffic flows from the client to the Azure Front Door Private Link endpoint in the supported region, then traverses the Microsoft backbone network to your origin, maintaining private connectivity. Be aware that this configuration introduces additional latency due to the extra network hop between regions. You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the additional latency due to choosing the next nearest region.  Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
 
   - name: Performance
     questions:

articles/frontdoor/private-link.md

@@ -72,7 +72,12 @@ Azure Front Door private link is available in the following regions:
 | US Sec East | | | | |
 | US Sec West | | | | |
 
-The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region isn't supported in the list of regions Front Door Private Link supports, pick the next nearest region. You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the next nearest region in terms of latency. We are in the process of enabling support for more regions. Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
+> [!NOTE]
+> Azure Front Door Private Link is only available in regions with Availability Zone support. This is to ensure zonal resiliency for region based feature like Private link.
+
+The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region isn't supported in the list of regions Front Door Private Link supports, pick the next nearest region. Traffic flows from the client to the Azure Front Door Private Link endpoint in the supported region, then traverses the Microsoft backbone network to your origin, maintaining private connectivity. Be aware that this configuration introduces additional latency due to the extra network hop between regions.
+
+You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the additional latency due to choosing the next nearest region.  Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
 
 ## Association of a private endpoint with an Azure Front Door profile