Merge pull request #313801 from v-thpra/tjp-fresh-azcontapps-009

Q&M Freshness - Azure Container Apps - TJP009

Author: prmerger-automator[bot]

articles/container-apps/dapr-authentication-token.md

@@ -7,7 +7,7 @@ author: greenie-msft
 ms.service: azure-container-apps
 ms.subservice: dapr
 ms.topic: how-to 
-ms.date: 02/03/2026
+ms.date: 03/27/2026
 ---
 
 # Enable token authentication for Dapr requests
@@ -30,17 +30,17 @@ You can use this token to authenticate that calls coming into your application a
 
 ## Authenticate requests from Dapr
 
-# [With Dapr SDKs](#tab/sdk)
+# [With a Dapr SDK](#tab/sdk)
 
-If you're using a [Dapr SDK](https://docs.dapr.io/developing-applications/sdks/), you can use the Dapr authentication methods provided in the open-source SDK repositories. 
+If you're using a [Dapr Software Development Kit (SDK)](https://docs.dapr.io/developing-applications/sdks/), you can use the Dapr authentication methods provided in the open-source SDK repositories. 
 
-Once added to your project, the Dapr SDKs validates the token in all incoming requests from Dapr, rejecting calls that don't include the correct token. You don't need to perform any other action.
+Once added to your project, the Dapr SDK validates the token in all incoming requests from Dapr, rejecting calls that don't include the correct token. You don't need to perform any other action.
 
 Incoming requests that don't include the token, or include an incorrect token, are rejected automatically.
 
 # [Without an SDK](#tab/nosdk)
 
-If you're not using a Dapr SDK, you need to check the HTTP header or gRPC metadata property in all incoming requests in order to validate that they're created by the Dapr sidecar.
+If you're not using a Dapr SDK, you need to check the HTTP header or gRPC metadata property in all incoming requests and validate that the Dapr sidecar created the request.
 
 ### HTTP
 

articles/container-apps/dapr-component-connect-services.md

@@ -8,7 +8,7 @@ ms.service: azure-container-apps
 ms.subservice: dapr
 ms.custom: build-2023
 ms.topic: concept-article
-ms.date: 02/03/2026
+ms.date: 03/27/2026
 ---
 
 # Connect to other Azure or partner services by using Dapr components
@@ -19,15 +19,14 @@ Before getting started, learn more about the [offered support for Dapr component
 
 ## Recommendations
 
-Whenever possible, it's recommended that you use Azure components that provide managed identity support for the most secure connection. Use Azure Key Vault secret stores *only* when managed identity authentication isn't supported. 
+For the most secure connection, we recommended that you use Azure components that provide managed identity support whenever possible. Use Azure Key Vault secret stores *only* when managed identity authentication isn't supported. 
 
 | Service type | Recommendation |
 | ------------ | -------------- |
 | Azure component with managed identity support | [Use the managed identity flow (recommended)](#use-managed-identity-recommended) |
 | Azure component without managed identity support | [Use an Azure Key Vault secret store](#azure-key-vault-secret-stores) |
 | Non-Azure components | [Use an Azure Key Vault secret store](#azure-key-vault-secret-stores) |
 
-
 ## Use managed identity (recommended)
 
 For Azure-hosted services, Dapr can use the [managed identity of the scoped container apps][aca-managed-id] to authenticate to the backend service provider. When using managed identity, you don't need to include secret information in a component manifest. *Using managed identity is recommended* as it eliminates storage of sensitive input in components and doesn't require managing a secret store.
@@ -72,7 +71,7 @@ scopes:
 
 #### Platform-managed Kubernetes secrets
 
-As an alternative to Kubernetes secrets, local environment variables, and local file Dapr secret stores, Azure Container Apps provides a platform-managed approach for creating and using Kubernetes secrets. This approach can be used to connect to non-Azure services or in dev/test scenarios for quickly deploying components via the CLI without setting up a secret store or managed identity.
+As an alternative to Kubernetes secrets, local environment variables, and local file Dapr secret stores, Azure Container Apps provides a platform-managed approach for creating and using Kubernetes secrets. This approach can be used to connect to non-Azure services. Or, in dev/test scenarios it can be used for quickly deploying components via the CLI without setting up a secret store or managed identity.
 
 This component configuration defines the sensitive value as a secret parameter that can be referenced from the metadata section. 
 

articles/container-apps/dapr-component-resiliency.md

@@ -7,7 +7,7 @@ author: greenie-msft
 ms.service: azure-container-apps
 ms.subservice: dapr
 ms.topic: concept-article
-ms.date: 02/02/2026
+ms.date: 03/27/2026
 ms.author: nigreenf
 ms.reviewer: hannahhunter
 ms.custom:
@@ -20,7 +20,7 @@ ms.custom:
 
 # Dapr component resiliency (preview)
 
-Resiliency policies proactively prevent, detect, and recover from your container app failures. In this article, you learn how to apply resiliency policies for applications that use Dapr to integrate with different cloud services, like state stores, pub/sub message brokers, secret stores, and more. 
+Resiliency policies proactively prevent, detect, and recover from your container app failures. In this article, you learn how to apply resiliency policies for applications that use Dapr to integrate with different cloud services. Such as, state stores, pub/sub message brokers, secret stores, and more. 
 
 You can configure resiliency policies like retries, timeouts, and circuit breakers for the following outbound and inbound operation directions by using a Dapr component: 
 
@@ -317,12 +317,12 @@ properties: {
 Specifying `consecutiveErrors` (the circuit trip condition as `consecutiveFailures > $(consecutiveErrors)-1`) sets the number of errors allowed to occur before the circuit trips and opens halfway. 
 
 The circuit waits half-open for the `timeoutInSeconds` amount of time, during which the `consecutiveErrors` number of requests must consecutively succeed. 
-- _If the requests succeed,_ the circuit closes. 
-- _If the requests fail,_ the circuit remains in a half-opened state.
+- *If the requests succeed*, the circuit closes. 
+- *If the requests fail*, the circuit remains in a half-opened state.
 
 If you didn't set any `intervalInSeconds` value, the circuit resets to a closed state after the amount of time you set for `timeoutInSeconds`, regardless of consecutive request success or failure. If you set `intervalInSeconds` to *0*, the circuit never automatically resets, only moving from half-open to closed state by successfully completing `consecutiveErrors` requests in a row.
 
-If you did set an `intervalInSeconds` value, that determines the amount of time before the circuit is reset to closed state, independent of whether the requests sent in half-opened state succeeded or not.
+If you did set an `intervalInSeconds` value, it determines the amount of time before the circuit is reset to closed state, independent of whether the requests sent in half-opened state succeeded or not.
 
 ## Resiliency logs
 
@@ -342,13 +342,13 @@ ContainerAppConsoleLogs_CL
 
 Select **Run** to run the query and view the result with the log message indicating the policy is loading.
 
-:::image type="content" source="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png" alt-text="Screenshot showing resiliency query results based on provided query example for checking if resiliency policy has loaded." lightbox="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png":::
+:::image type="content" source="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png" alt-text="Screenshot showing resiliency query results based on the provided query example for checking if the resiliency policy is loaded." lightbox="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png":::
 
 You can also find the actual resiliency policy by enabling debug logs on your container app and querying to see if a resiliency resource is loaded. 
 
 :::image type="content" source="media/dapr-component-resiliency/dapr-debug-logs.png" alt-text="Screenshot demonstrating how to enable debug logs on your container app via the portal." lightbox="media/dapr-component-resiliency/dapr-debug-logs.png":::
 
-Once debug logs are enabled, use a query similar to the following:
+Once debug logs are enabled, use a query similar to the following example:
 
 ```
 ContainerAppConsoleLogs_CL