Merge branch 'MicrosoftDocs:main' into main

Author: MJyot

articles/api-management/breaking-changes/trusted-service-connectivity-retirement-march-2026.md

@@ -92,7 +92,7 @@ You can configure the networking of target resources to one of the following opt
 
 After ensuring that your API Management gateway doesn't access other Azure services using trusted service connectivity, you must explicitly disable trusted connectivity in your gateway to acknowledge you have verified that the service no longer depends on trusted connectivity.
 
-To do so, set a custom property `Microsoft.WindowsAzure.ApiManagement.Gateway.ManagedIdentity.DisableOverPrivilegedAccess` to `"True"` on the [API Management service](/rest/api/apimanagement/api-management-service/create-or-update?view=rest-apimanagement-2025-03-01-preview&tabs=HTTP). For example: 
+To do so, set a custom property `Microsoft.WindowsAzure.ApiManagement.Gateway.ManagedIdentity.DisableOverPrivilegedAccess` to `"True"` on the [API Management service](/rest/api/apimanagement/api-management-service/update?view=rest-apimanagement-2025-03-01-preview&tabs=HTTP). For example: 
 
 
 ```json

articles/app-service/overview.md

@@ -25,7 +25,7 @@ Whether you're a student, a small business, a startup, or an enterprise, App Ser
 
 ### Students
 
-- **Free access**: In addition to the widely available [free tier](https://azure.microsoft.com/pricing/details/app-service/), students can take advantage of the [Azure for Students Starter](https://azure.microsoft.com/pricing/offers/ms-azr-0144p) program.
+- **Free access**: In addition to the widely available [free tier](https://azure.microsoft.com/pricing/purchase-options/azure-account), students can take advantage of the [Azure for Students Starter](https://azure.microsoft.com/pricing/offers/ms-azr-0144p) program.
 - **IDE support**: Purpose-built deployment tools are available for Visual Studio, Visual Studio Code, IntelliJ, and Eclipse.
 - **Easy to use**: Run your apps without needing experience in infrastructure management.
 - **Learning Resources**: Plenty of tutorials and guides to help you get started.

articles/application-gateway/application-gateway-backend-health-troubleshooting.md

@@ -108,10 +108,11 @@ To increase the timeout value, follow these steps:
 **Resolution:**
 
 1. Verify that the FQDN entered in the backend pool is correct and that it's a public domain, then try to resolve it from your local machine.
-1. If you can resolve the IP address, there might be something wrong with the DNS configuration in the virtual network.
-1. Check whether the virtual network is configured with a custom DNS server. If it is, check the DNS server about why it can't resolve to the IP address of the specified FQDN.
-1. If you're using Azure default DNS, verify with your domain name registrar that proper A record or CNAME record mapping is complete.
-1. If the domain is private or internal, try to resolve it from a VM in the same virtual network. If you can resolve it, restart Application Gateway and check again. To restart Application Gateway, you need to [stop](/powershell/module/az.network/stop-azapplicationgateway) and [start](/powershell/module/az.network/start-azapplicationgateway) by using the PowerShell commands described in these linked resources.
+2. If you can resolve the IP address, there might be something wrong with the DNS configuration in the virtual network.
+3. Check whether the virtual network is configured with a custom DNS server. If it is, check the DNS server about why it can't resolve to the IP address of the specified FQDN.
+4. If you're using Azure default DNS, verify with your domain name registrar that proper A record or CNAME record mapping is complete.
+5. If the domain is private or internal, try to resolve it from a VM in the same virtual network. If you cannnot resolve it, restart Application Gateway and check again. To restart Application Gateway, you need to [stop](/powershell/module/az.network/stop-azapplicationgateway) and [start](/powershell/module/az.network/start-azapplicationgateway) by using the PowerShell commands described in these linked resources.
+6. If you're using short names (single-label domain names like `server1` instead of a fully-qualified domain name `server1.contoso.com`), verify that your DNS server can resolve the short name. Azure's built-in DNS (168.63.129.16) only resolves short names for resources within the same virtual network. For on-premises short names, use a custom DNS server configured with the appropriate search domains.
 
 ### TCP connect error
 

articles/application-gateway/application-gateway-components.md

@@ -130,7 +130,7 @@ A backend pool routes request to backend servers, which serve the request. Backe
 - Virtual machine scale sets
 - Public IP addresses
 - Internal IP addresses
-- FQDN
+- FQDN (fully qualified domain names) or short names (single-label domain names), provided your DNS server can resolve them
 - Multitenant backends (such as App Service)
 
 Application Gateway backend pool members aren't tied to an availability set. An application gateway can communicate with instances outside of the virtual network that it's in. As a result, the members of the backend pools can be across clusters, across datacenters, or outside Azure, as long as there's IP connectivity.

articles/azure-app-configuration/TOC.yml

@@ -119,8 +119,6 @@
     items:
     - name: App Service & Azure Functions
       href: /azure/app-service/app-service-configuration-references
-    - name: Azure Front Door
-      href: how-to-connect-azure-front-door.md
   - name: Deployment
     items:
     - name: Overview
@@ -260,6 +258,15 @@
       href: howto-telemetry-python.md
     - name: JavaScript
       href: howto-telemetry-javascript.md
+
+- name: Hyperscale configuration
+  items:
+  - name: Overview
+    href: concept-hyperscale-client-configuration.md
+  - name: Connect to Azure Front Door
+    href: how-to-connect-azure-front-door.md
+  - name: Load Configuration from Azure Front Door
+    href: how-to-load-azure-front-door-configuration-provider.md
 - name: CI/CD integration
   items:
   - name: Use configuration files
@@ -308,6 +315,8 @@
       href: howto-set-up-private-access.md
     - name: Disable public network access
       href: howto-disable-public-access.md
+    - name: Network access errors
+      href: network-access-errors.md
   - name: Data encryption
     items:
     - name: Add Managed Identities

articles/azure-app-configuration/concept-hyperscale-client-configuration.md

@@ -0,0 +1,97 @@
+---
+title: Hyperscale configuration delivery for client applications with Azure App Configuration (Preview) 
+description: Learn how to use hyperscale configuration delivery to your applications via Azure Front Door.
+author: avanigupta
+ms.author: avgupta
+ms.service: azure-app-configuration
+ms.topic: concept-article 
+ms.date: 12/02/2025
+---
+
+# Hyperscale configuration delivery for client applications (preview) 
+
+When it comes to consuming configuration, client applications have different requirements than server applications. They can't store secrets, they operate on a much larger scale, and users expect instant startup times from anywhere in the world. To meet the requirements of client-side application configuration, Azure App Configuration provides integration with Azure Front Door. Azure Front Door's edge-based content delivery network combined with Azure App Configuration's centralized configuration management enables client applications anywhere to get configuration fast, reliably and anonymously.
+
+## CDN-accelerated configuration delivery with Azure Front Door
+
+App Configuration gives developers a single, consistent place to define configuration settings and feature flags. By integrating Azure App Configuration with Azure Front Door, your configuration data is centrally managed through Azure App Configuration while being cached and distributed through Azure's content delivery network. This architecture is valuable for client-facing applications including mobile, desktop, and browser-based applications.
+
+## System architecture
+
+:::image type="content" source="media/hyperscale-configuration-architecture.png" alt-text="Architecture diagram for integration of Azure Front Door with Azure App Configuration."
+
+How it works
+- Client applications retrieve configuration through Azure Front Door endpoints without authentication, eliminating the security risk of embedding credentials in client-side code.
+- Azure Front Door uses Managed Identity to authenticate with Azure App Configuration securely.
+- A configurable subset of key-values, feature flags, or snapshots are exposed through Azure Front Door.
+- Edge caching enables high throughput and low latency configuration delivery.
+
+This architecture eliminates the need for custom proxies or gateways while providing secure, efficient configuration delivery to client applications.
+
+## Developer scenarios
+
+CDN-delivered configuration unlocks a range of client application scenarios:
+
+- Client-side feature rollouts for UI components
+- A/B testing or targeted experiences using feature flags
+- Control AI/LLM model parameters and UI behaviors through configuration
+- Dynamically control client-side agent behavior, safety modes, and guardrail settings through configuration
+- Consistent behavior for clients using snapshot-based configuration
+
+> [!NOTE]
+> This feature is currently available only in the Azure public cloud. 
+
+## Recommendations and considerations
+
+### Security
+
+Configuration exposed through Azure Front Door is publicly accessible without authentication, making proper security controls essential. Implement the following strategies to protect your configuration data from unintended exposure.
+
+#### Use a dedicated App Configuration store
+
+Consider using a dedicated App Configuration store for client-facing configuration delivered through Azure Front Door. This store should contain only nonsensitive settings that are safe for public consumption. This isolation strategy limits potential impact if configuration is inadvertently exposed, ensuring that sensitive data remains protected.
+
+#### Role Based Access Control using Managed Identity
+
+Azure Front Door accesses App Configuration data using either a system-assigned managed identity or a user-assigned managed identity. The selected identity must be assigned the `App Configuration Data Reader` role to retrieve configuration data. When you create the Azure Front Door endpoint through the App Configuration portal, this role assignment is created automatically. The portal displays a warning if the role assignment creation process encounters any issues. Restrict the managed identity to the `App Configuration Data Reader` role only and avoid assigning any roles with write permissions.
+
+### Request scoping
+
+Configure one or more filters to control which requests are allowed to pass through Azure Front Door. This prevents anonymous clients from bypassing the CDN cache through excessive or malformed requests that could overwhelm App Configuration and trigger service throttling.
+
+#### Request scoping through key-value filters
+
+- Configure Azure Front Door filters to precisely match your application's configuration requirements. Only expose the exact key patterns your application uses. For example, if your application loads keys with the `"App1:"` prefix, configure the Azure Front Door rule to allow only `"App1:"` keys, not broader patterns like `"App"`.
+
+- If your application loads feature flags, provide `".appconfig.featureflag/{YOUR-FEATURE-FLAG-PREFIX}"` filter for the Key with *Starts with* operator.
+
+- If you're using App Configuration provider libraries and your application loads ONLY feature flags, you should add two key filters in the Azure Front Door rules - one for `ALL` keys with no label and second for all keys starting with `".appconfig.featureflag/{YOUR-FEATURE-FLAG-PREFIX}"`. This is because App Configuration provider libraries load all key-values with no label by default when no key-value selector is specified. 
+
+#### Request scoping through multiple Azure Front Door endpoints
+
+Create separate Azure Front Door endpoints for applications with different configuration requirements. Rather than combining multiple filter rules in a single endpoint, each application connects to its dedicated endpoint with precisely scoped filters. This approach prevents applications from accessing each other's configuration data and simplifies filter management.
+
+### Failover and load balancing
+
+Client applications rely on Azure Front Door for failover and load balancing, as they don't connect directly to App Configuration. To enable automatic failover and geo-redundant configuration delivery, configure your App Configuration replicas as origins in the Azure Front Door endpoint. For details on how origin groups improve availability and performance, see [Azure Front Door routing methods](/azure/frontdoor/routing-methods)
+
+### Caching
+
+Configure Azure Front Door cache duration to balance configuration freshness and origin load. Azure Front Door controls the caching behavior, which means updates from App Configuration can only be seen by your application after the Front Door cache expires. This cache expiration time effectively becomes the minimum time before your app can observe new configuration values, regardless of how frequently the app checks for changes. 
+
+We recommend setting Azure Front Door cache TTL to at least 10 minutes and application refresh interval to at least 1 minute. With these settings, configuration updates may take up to 11 minutes to propagate: Azure Front Door 10 minute cache TTL plus up to 1 minute until the next application refresh. 
+
+You can choose appropriate refresh interval values that fit your application. Shorter cache durations will increase the number of requests routed through Azure Front Door. This model provides eventual consistency, not real-time propagation, which is expected for CDN-based delivery. Learn more about [Caching with Azure Front Door](/azure/frontdoor/front-door-caching).
+
+> [!NOTE]
+> Azure Front Door makes no guarantees about the amount of time that the content is stored in the cache. Cached content may be removed from the edge cache before the content expiration if the content isn't frequently used. Additionally, if App Configuration is unreachable, Azure Front Door may continue serving stale data from cache to maintain application availability. 
+
+## Next steps
+
+> [!div class="nextstepaction"]
+> [Set up Azure Front Door with App Config](./how-to-connect-azure-front-door.md)
+
+## Related content
+
+- [Load Configuration from Azure Front Door in Client Applications](./how-to-load-azure-front-door-configuration-provider.md)
+

articles/azure-app-configuration/configuration-provider-overview.md

@@ -73,6 +73,8 @@ Distributed Tracing | [GA](./reference-dotnet-provider.md#distributed-tracing) |
 Health Check | [GA](./reference-dotnet-provider.md#health-check) | GA | WIP | WIP | WIP | N/A 
 Select by Tag Filters | [GA](./reference-dotnet-provider.md#load-specific-key-values-using-selectors) | WIP | GA | GA | [GA](./reference-javascript-provider.md#tag-filters) | [GA](./reference-go-provider.md#tag-filters)
 Snapshot Reference | [GA](./reference-dotnet-provider.md#snapshot-reference) | WIP | WIP | WIP | WIP | WIP
+Load from Azure Front Door | [Preview](./reference-dotnet-provider.md#connect-to-azure-front-door) | WIP | WIP | WIP | [Preview](./reference-javascript-provider.md#connect-to-azure-front-door)  | WIP
+
 
 ## Support policy
 

articles/azure-app-configuration/faq.yml

@@ -182,6 +182,10 @@ sections:
           - **Reduce key-value revision retention** if you perform frequent key-value updates and you don't need to retain revisions for the maximum duration allowed by your App Configuration store. Revisions count toward your store's total storage usage. If the storage quota is exceeded, you'll no longer be able to create or modify key-values or feature flags.
           - **Improve your application resiliency**: Consider integrating geo-replication to allow failover and load balancing. Check the best practices for [building highly resilient applications](./howto-best-practices.md#building-applications-with-high-resiliency).
 
+      - question: How can I use App Configuration in client applications with hyperscale configuration?
+        answer: |
+          See [best practices for client applications in App Configuration](./howto-best-practices.md#client-applications-in-app-configuration)
+
       - question: Why can't I create an App Configuration store with the same name as one that I just deleted?
         answer: |
           All App Configuration stores in the Standard and Premium tiers have automatically enabled the [soft-delete](concept-soft-delete.md) feature. When a Standard or Premium tier App Configuration store is deleted, its name is reserved for the retention period. To recreate a store with the same name before the retention period expires, you need to [purge the soft-deleted store](howto-recover-deleted-stores-in-azure-app-configuration.md#list-recover-or-purge-a-soft-deleted-app-configuration-store) first, provided the store doesn't have purge protection enabled. If the purge protection is enabled, you must wait for the retention period to elapse. Use the purge function or set a shorter retention period if you often need to recreate a store with the same name. Workflows that require recreating a store with the same name should allow for one hour between purging a configuration store and performing the subsequent create. This recommendation is in place because once a purge is requested the actual cleanup of configuration store resources is performed asynchronously, requiring a bit of extra time to finalize. To avoid any need to wait, workflows that create ephemeral configuration stores are recommended to use unique names.