Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into mdb-customizations-agentic-workflow

Author: RoseHJM

articles/application-gateway/media/rewrite-http-headers-url/url-rewrite-overview.png

@@ -6,7 +6,7 @@ ms.custom:
   - devx-track-dotnet
   - ignite-2023
 ms.topic: conceptual
-ms.date: 08/03/2023
+ms.date: 05/06/2025
 recommendations: false
 #Customer intent: As a developer, I need to understand the differences between running in-process and running in an isolated worker process so that I can choose the best process model for my functions.
 ---
@@ -37,7 +37,7 @@ Use the following table to compare feature and functional differences between th
 | Imperative bindings<sup>1</sup>  | Not supported - instead [work with SDK types directly](./dotnet-isolated-process-guide.md#register-azure-clients) | [Supported](functions-dotnet-class-library.md#binding-at-runtime) |
 | Dependency injection | [Supported](dotnet-isolated-process-guide.md#dependency-injection) (improved model consistent with .NET ecosystem) | [Supported](functions-dotnet-dependency-injection.md)  |
 | Middleware | [Supported](dotnet-isolated-process-guide.md#middleware) | Not supported |
-| Logging | [`ILogger<T>`]/[`ILogger`] obtained from [FunctionContext](/dotnet/api/microsoft.azure.functions.worker.functioncontext) or via [dependency injection](dotnet-isolated-process-guide.md#dependency-injection)| [`ILogger`] passed to the function<br/>[`ILogger<T>`] via [dependency injection](functions-dotnet-dependency-injection.md) |
+| Logging | [`ILogger<T>`]/[`ILogger`] obtained from [FunctionContext](/dotnet/api/microsoft.azure.functions.worker.functioncontext) or by using [dependency injection](dotnet-isolated-process-guide.md#dependency-injection)| [`ILogger`] passed to the function<br/>[`ILogger<T>`] by using [dependency injection](functions-dotnet-dependency-injection.md) |
 | Application Insights dependencies | [Supported](./dotnet-isolated-process-guide.md#application-insights) | [Supported](functions-monitoring.md#dependencies) |
 | Cancellation tokens | [Supported](dotnet-isolated-process-guide.md#cancellation-tokens) | [Supported](functions-dotnet-class-library.md#cancellation-tokens) |
 | Cold start times<sup>2</sup> | [Configurable optimizations](./dotnet-isolated-process-guide.md#performance-optimizations) | Optimized |
@@ -47,13 +47,13 @@ Use the following table to compare feature and functional differences between th
 
 <sup>1</sup> When you need to interact with a service using parameters determined at runtime, using the corresponding service SDKs directly is recommended over using imperative bindings. The SDKs are less verbose, cover more scenarios, and have advantages for error handling and debugging purposes. This recommendation applies to both models.
 
-<sup>2</sup> Cold start times could be additionally impacted on Windows when using some preview versions of .NET due to just-in-time loading of preview frameworks. This impact applies to both the in-process and out-of-process models but can be noticeable when comparing across different versions. This delay for preview versions isn't present on Linux plans.
+<sup>2</sup> Cold start times could be additionally affected on Windows when using some preview versions of .NET due to just-in-time loading of preview frameworks. This impact applies to both the in-process and out-of-process models but can be noticeable when comparing across different versions. This delay for preview versions isn't present on Linux plans.
 
 <sup>3</sup> C# Script functions also run in-process and use the same libraries as in-process class library functions. For more information, see the [Azure Functions C# script (.csx) developer reference](functions-reference-csharp.md). 
 
 <sup>4</sup> Service SDK types include types from the [Azure SDK for .NET](/dotnet/azure/sdk/azure-sdk-for-dotnet) such as [BlobClient](/dotnet/api/azure.storage.blobs.blobclient).
 
-<sup>5</sup> ASP.NET Core types are not supported for .NET Framework.
+<sup>5</sup> ASP.NET Core types aren't supported for .NET Framework.
 
 [HttpRequest]: /dotnet/api/microsoft.aspnetcore.http.httprequest
 [IActionResult]: /dotnet/api/microsoft.aspnetcore.mvc.iactionresult

articles/azure-functions/dotnet-isolated-in-process-differences.md

@@ -1,37 +1,50 @@
 ---
-title: Use key vault secrets in customization files
-description: Learn how to use Azure Key Vault secrets in team and user customization files to clone private repositories.
+title: Fetch Azure Key Vault Secrets from Dev Box Customizations Files
+description: Discover how to fetch Azure Key Vault secrets by using team and user customization files to enhance security and simplify workflows.
+#customer intent: As a platform engineer, I want to configure Azure Key Vault secrets so that my development teams can securely access private repositories during Dev Box customization.
 author: RoseHJM
 ms.author: rosemalcolm
 ms.service: dev-box
 ms.custom:
   - ignite-2024
+  - ai-gen-docs-bap
+  - ai-gen-title
+  - ai-seo-date:05/10/2025
+  - ai-gen-description
 ms.topic: how-to
-ms.date: 04/20/2025
-
-#customer intent: As a Dev Center Admin or Project Admin, I want to create image definition files so that my development teams can create customized dev boxes.
+ms.date: 05/10/2025
 ---
 
-# Clone a private repository by using a customization file
+# Use Azure Key Vault secrets in customization files
 
 [!INCLUDE [note-build-2025](includes/note-build-2025.md)]
 
 
-You can use secrets from your Azure key vault in your YAML customizations to clone private repositories, or with any custom task you author that requires an access token. In a team customization file, you can use a personal access token (PAT) stored in a key vault to access a private repository.
+You can use secrets from your Azure key vault in your YAML customizations to clone private repositories, or with any task you author that requires an access token. For example, in a team customization file, you can use a personal access token (PAT) stored in a key vault to access a private repository.
+
+## Use key vault secrets in customization files
 
-## Use key vault secrets in team customization files
+To use a secret, like a PAT, in your customization files, store your PAT as a key vault secret. 
 
-To clone a private repository, store your PAT as a key vault secret. See [Grant the managed identity access to the key vault secret](../deployment-environments/how-to-configure-managed-identity.md#grant-the-managed-identity-access-to-the-key-vault-secret), and use it when you invoke the `git-clone` task in your customization.
+Both team and user customizations support fetching secrets from a key vault. Team customizations, also known as image definition files, define the base image for the dev box with the `image` parameter, and list the tasks that run when a dev box is created. User customizations list the tasks that run when a dev box is created. The following examples show how to use a key vault secret in both types of customizations.
 
-To configure your key vault secrets for use in your YAML customizations:
+To configure key vault secrets for use in your YAML customizations:
 
 1. Ensure that your dev center project's managed identity has the Key Vault Reader role and the Key Vault Secrets User role on your key vault.
 2. Grant the Key Vault Secrets User role for the key vault secret to each user or user group that should be able to consume the secret during the customization of a dev box. The user or group granted the role must include the managed identity for the dev center, the admin's user account, and any user or group that needs the secret during dev box customization.
 
-For more information, see:
+You can use a key vault secret in-line with the built-in PowerShell task: 
 
-- [Configure a managed identity for a dev center](../deployment-environments/how-to-configure-managed-identity.md#configure-a-managed-identity-for-a-dev-center)
-- [Grant the managed identity access to the key vault secret](../deployment-environments/how-to-configure-managed-identity.md#grant-the-managed-identity-access-to-the-key-vault-secret)
+```yml
+$schema: "1.0" 
+image: microsoftwindowsdesktop_windows-ent-cpc_win11-24H2-ent-cpc 
+tasks:  
+- name: git-clone
+    description: Clone this repository into C:\Workspaces 
+    parameters: 
+    command: MyCommand –MyParam '{{KEY_VAULT_SECRET_URI}}' 
+```
+This example shows an image definition file. The `KEY_VAULT_SECRET_URI` is the URI of the secret in your key vault. 
 
 You can reference the secret in your YAML customization in the following format, which uses the `git-clone` task as an example:
 
@@ -45,37 +58,34 @@ tasks:
       directory: C:\Workspaces
       pat: '{{KEY_VAULT_SECRET_URI}}'
 ```
+This example shows a user customization file. There is no `image` specified.
 
-## Use key vault secrets in user customization files
-
-To clone a private Azure Repos repository from a user customization file, you don't need to configure a secret in Azure Key Vault. If you want to clone a private Azure Repos repository from a user customization file, you don't need to configure a secret in Azure Key Vault. Instead, you can use `{{ado}}` or `{{ado://your-ado-organization-name}}` as a parameter. This parameter fetches an access token on your behalf when you're creating a dev box. The access token has read-only permission to your repository.
-
-The `git-clone` task in the quickstart catalog uses the access token to clone your repository. Here's an example:
+User customizations let you obtain an Azure DevOps token to clone private repositories without explicitly specifying a PAT from the key vault. The service automatically exchanges your Azure token for an Azure DevOps token at run time.  
 
 ```yml
-tasks:
-  - name: git-clone
-    description: Clone this repository into C:\Workspaces
-    parameters:
-      repositoryUrl: https://myazdo.visualstudio.com/MyProject/_git/myrepo
-      directory: C:\Workspaces
-      pat: '{{ado://YOUR_ADO_ORG}}'
-```
+$schema: "1.0" 
+tasks: 
+  - name: git-clone 
+    description: Clone this repository into C:\Workspaces 
+    parameters: 
+      repositoryUrl: https://myazdo.visualstudio.com/MyProject/_git/myrepo 
+      directory: C:\Workspaces 
+      pat: '{{ado://YOUR_ORG_NAME}}' 
+``` 
 
-The dev center needs access to your key vault. Dev centers don't support service tags, so if your key vault is private, allow trusted Microsoft services to bypass the firewall.
+The Dev Box VS Code extension and Dev Box CLI don't support hydrating secrets in the inner-loop testing workflow for customizations. 
 
-Dev centers don't support service tags, so if the key vault is private, allow trusted Microsoft services to bypass the firewall.
+## Configure key vault access
 
-:::image type="content" source="media/how-to-use-secrets-customization-files/trusted-services-bypass-firewall.png" alt-text="Screenshot that shows the option to allow trusted Microsoft services to bypass the firewall in Azure Key Vault settings." lightbox="media/how-to-use-secrets-customization-files/trusted-services-bypass-firewall.png":::
+The dev center needs access to your key vault. Because dev centers don't support service tags, if your key vault is private, let trusted Microsoft services bypass the firewall.
 
-To learn how to allow trusted Microsoft services to bypass the firewall, see [Configure Azure Key Vault networking settings](/azure/key-vault/general/how-to-azure-key-vault-network-security).
+:::image type="content" source="media/how-to-use-secrets-customization-files/trusted-services-bypass-firewall.png" alt-text="Screenshot that shows the option to allow trusted Microsoft services to bypass the firewall in Azure Key Vault settings." lightbox="media/how-to-use-secrets-customization-files/trusted-services-bypass-firewall.png":::
 
-## Share a customization file from a code repository
+To learn how to let trusted Microsoft services bypass the firewall, see [Configure Azure Key Vault networking settings](/azure/key-vault/general/how-to-azure-key-vault-network-security).
 
-Make the customization file available to dev box pools by naming it *imagedefinition.yaml* and uploading it to the repository that hosts the catalog. When you create a dev box pool, you can select the customization file from the catalog to apply to the dev boxes in the pool.
 
 ## Related content
 
 - [Microsoft Dev Box team customizations](concept-what-are-team-customizations.md)
 - [Configure imaging for Dev Box team customizations](how-to-configure-customization-imaging.md)
-- [Add and configure a catalog from GitHub or Azure Repos](../deployment-environments/how-to-configure-catalog.md)
+- Learn how to [add and configure a catalog from GitHub or Azure Repos](../deployment-environments/how-to-configure-catalog.md).

articles/dev-box/how-to-use-secrets-customization-files.md

@@ -10,6 +10,8 @@ ms.date: 03/31/2024
 
 # Apex domains in Azure Front Door
 
+**Applies to:** :heavy_check_mark: Front Door Standard :heavy_check_mark: Front Door Premium
+
 Apex domains, also called *root domains*, or *naked domains*, are at the root of a Domain Name System (DNS) zone and don't contain subdomains. For example, `contoso.com` is an apex domain.
 
 Azure Front Door supports apex domains, but requires special considerations. This article describes how apex domains work in Azure Front Door.

articles/frontdoor/apex-domain.md

@@ -10,6 +10,8 @@ ms.date: 12/28/2023
 
 # Understand Azure Front Door billing
 
+**Applies to:** :heavy_check_mark: Front Door Standard :heavy_check_mark: Front Door Premium
+
 Azure Front Door provides a rich set of features for your internet-facing workloads. Front Door helps you to accelerate your application's performance, improves your security, and provides you with tools to inspect and modify your HTTP traffic.
 
 Front Door's billing model includes several components. Front Door charges a base fee for each profile that you deploy. You're also charged for requests and data transfer based on your usage. *Billing meters* collect information about your Front Door usage. Your monthly Azure bill aggregates the billing information across the month and applies the pricing to determine the amount you need to pay.

articles/frontdoor/billing.md

@@ -10,6 +10,8 @@ ms.author: jodowns
 
 # Domains in Azure Front Door
 
+**Applies to:** :heavy_check_mark: Front Door Standard :heavy_check_mark: Front Door Premium
+
 A *domain* represents a custom domain name that Azure Front Door uses to receive your application's traffic. Azure Front Door supports adding three types of domain names:
 
 - **Subdomains** are the most common type of custom domain name. An example subdomain is `myapplication.contoso.com`.

articles/frontdoor/domain.md

@@ -14,6 +14,8 @@ In Azure Front Door, an *endpoint* is a logical grouping of one or more routes a
 
 ## How many endpoints should I create?
 
+**Applies to:** :heavy_check_mark: Front Door Standard :heavy_check_mark: Front Door Premium
+
 A Front Door profile can contain multiple endpoints, but in many cases, a single endpoint might suffice.
 
 Consider the following factors when planning your endpoints:

articles/frontdoor/endpoint.md

@@ -13,6 +13,8 @@ zone_pivot_groups: front-door-dev-exp-portal-ps-cli
 
 # Connect Azure Front Door Premium to an Azure Application Gateway with Private Link
 
+**Applies to:** :heavy_check_mark: Front Door Premium
+
 This article guides you through the steps to configure an Azure Front Door Premium to connect privately to your Azure Application Gateway using Azure Private Link.
 
 ::: zone pivot="front-door-portal"

articles/frontdoor/how-to-enable-private-link-application-gateway.md

@@ -12,6 +12,8 @@ zone_pivot_groups: front-door-dev-exp-portal-cli
 
 # Connect Azure Front Door Premium to a storage static website with Private Link
 
+**Applies to:** :heavy_check_mark: Front Door Premium
+
 ::: zone pivot="front-door-portal"
 
 This article guides you through how to configure Azure Front Door Premium tier to connect to your storage static website privately using the Azure Private Link service.

articles/frontdoor/how-to-enable-private-link-storage-static-website.md

@@ -10,6 +10,8 @@ ms.date: 11/13/2024
 
 # What is Azure Front Door Manager?
 
+**Applies to:** :heavy_check_mark: Front Door Standard :heavy_check_mark: Front Door Premium
+
 Azure Front Door Manager in Azure Front Door Standard and Premium provides an overview of the endpoints configured for your Azure Front Door profile. With Front Door Manager, you can manage your collection of endpoints, configure routing rules, domains, origin groups, and apply security policies to protect your web application.
 
 :::image type="content" source="./media/manager/manager.png" alt-text="Screenshot of the Azure Front Door Manager page." lightbox="./media/manager/manager-expanded.png":::