Merge pull request #219314 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/api-management/api-management-howto-cache.md

@@ -22,8 +22,7 @@ ms.author: danlep
 APIs and operations in API Management can be configured with response caching. Response caching can significantly reduce latency for API callers and backend load for API providers.
 
 > [!IMPORTANT]
-> Built-in cache is volatile and is shared by all units in the same region in the same API Management service.
-
+> Built-in cache is volatile and is shared by all units in the same region in the same API Management service. Regardless of the cache type being used (internal or external), if the cache-related operations fail to connect to the cache due to the volatility of the cache or any other reason, the API call that uses the cache related operation doesn't raise an error, and the cache operation completes successfully. In the case of a read operation, a null value is returned to the calling policy expression. Your policy code should be designed to ensure that that there's a "fallback" mechanism to retrieve data not found in the cache.
 For more detailed information about caching, see [API Management caching policies](api-management-caching-policies.md) and  [Custom caching in Azure API Management](api-management-sample-cache-by-key.md).
 
 ![cache policies](media/api-management-howto-cache/cache-policies.png)

articles/container-instances/container-instances-init-container.md

@@ -21,7 +21,7 @@ This article shows how to use an Azure Resource Manager template to configure a
 * **Order of execution** - Init containers are executed in the order specified in the template, and before other containers. By default, you can specify a maximum of 59 init containers per container group. At least one non-init container must be in the group.
 * **Host environment** - Init containers run on the same hardware as the rest of the containers in the group.
 * **Resources** - You don't specify resources for init containers. They are granted the total resources such as CPUs and memory available to the container group. While an init container runs, no other containers run in the group.
-* **Supported properties** - Init containers can use group properties such as volumes, secrets, and managed identities. However, they can't use ports or an IP address if configured for the container group. 
+* **Supported properties** - Init containers can use some group properties such as volumes and secrets. However, they can't use ports, IP address and managed identities if configured for the container group. 
 * **Restart policy** - Each init container must exit successfully before the next container in the group starts. If an init container doesn't exit successfully, its restart action depends on the [restart policy](container-instances-restart-policy.md) configured for the group:
 
     |Policy in group  |Policy in init  |

articles/logic-apps/set-up-devops-deployment-single-tenant-azure-logic-apps.md

@@ -66,7 +66,7 @@ The following diagram shows the dependencies between your logic app project and
 
 ## Deploy logic app resources (zip deploy)
 
-After you push your logic app project to your source repository, you can set up build and release pipelines that deploy logic apps to infrastructure either inside or outside Azure.
+After you push your logic app project to your source repository, you can set up build and release pipelines either inside or outside Azure that deploy logic apps to infrastructure.
 
 ### Build your project