Merge pull request #291822 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: Taojunshen

articles/azure-resource-manager/bicep/scenarios-monitoring.md

@@ -55,7 +55,7 @@ resource diagnosticLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-previe
   scope: appServicePlan
   properties: {
     workspaceId: logAnalytics.id
-    logs: [
+    metrics: [
       {
         category: 'AllMetrics'
         enabled: true

articles/confidential-computing/confidential-containers-on-aks-preview.md

@@ -30,7 +30,7 @@ In alignment with the guidelines set by the [Confidential Computing Consortium](
 *	Code integrity: Runtime enforcement is always available through customer defined policies for containers and container configuration, such as immutable policies and container signing. 
 *	Isolation from operator: Security designs that assume least privilege and highest isolation shielding from all untrusted parties including customer/tenant admins. It includes hardening existing Kubernetes control plane access (kubelet) to confidential pods.
 
-But with these features of confidentiality, the product should additioanally its ease of use: it supports all unmodified Linux containers with high Kubernetes feature conformance. Additionally, it supports  heterogenous node pools (GPU, general-purpose nodes) in a single cluster to optimize for cost.  
+But with these features of confidentiality, the product should additionally its ease of use: it supports all unmodified Linux containers with high Kubernetes feature conformance. Additionally, it supports  heterogenous node pools (GPU, general-purpose nodes) in a single cluster to optimize for cost.  
 
 ## What forms Confidential Containers on AKS?
 

articles/confidential-computing/skr-flow-confidential-containers-azure-container-instance.md

@@ -11,7 +11,7 @@ ms.author: ananyagarg
 
 # Secure Key Release with Confidential containers on Azure Container Instance (ACI)
 
-Secure Key Release (SKR) flow with Azure Key Vault (AKV) with confidential container offerings can implement in couple of ways. Confidential containers run a guest enlightened exposting AMD SEV-SNP device through a Linux Kernel that uses an in guest firmware with necessary Hyper-V related patches that we refer as Direct Linux Boot (DLB). This platform doesn't use vTPM and HCL based that Confidential VMs with AMD SEV-SNP support. This concept document assumes you plan to run the containers in [Azure Container Support choosing a confidential computing SKU](/azure/container-instances/container-instances-tutorial-deploy-confidential-containers-cce-arm)
+Secure Key Release (SKR) flow with Azure Key Vault (AKV) with confidential container offerings can implement in couple of ways. Confidential containers run a guest enlightened exposing AMD SEV-SNP device through a Linux Kernel that uses an in guest firmware with necessary Hyper-V related patches that we refer as Direct Linux Boot (DLB). This platform doesn't use vTPM and HCL based that Confidential VMs with AMD SEV-SNP support. This concept document assumes you plan to run the containers in [Azure Container Support choosing a confidential computing SKU](/azure/container-instances/container-instances-tutorial-deploy-confidential-containers-cce-arm)
 
 - Side-Car Helper Container provided by Azure
 - Custom implementation with your container application

articles/confidential-computing/vmss-deployment-from-hardened-linux-image.md

@@ -68,7 +68,7 @@ Steps to deploy a scale set using VMSS and a hardened image are as follows:
     For the admin credentials, you will be able to use the credentials that you set from the hardened image while you create the vm.
 
     > [!NOTE]
-    > For specalized images, [osprofile properties](/azure/virtual-machines/shared-image-galleries) are handled differently than generalized images.
+    > For specialized images, [osprofile properties](/azure/virtual-machines/shared-image-galleries) are handled differently than generalized images.
     > Using a [load balancer](/azure/load-balancer/load-balancer-overview) is optional but is encouraged for these reasons.
     
     ```azurecli-interactive

articles/connectors/connectors-create-api-cosmos-db.md

@@ -193,7 +193,7 @@ In a **Logic App (Consumption)** workflow, an Azure Cosmos DB connection require
 | **Connection name** | Yes | <*connection-name*> | The name to use for your connection. |
 | **Authentication Type** | Yes | <*connection-type*> | The authentication type that you want to use. This example uses **Access key**. <p><p>- If you select **Access Key**, provide the remaining required property values to create the connection. <p><p>- If you select **Microsoft Entra integrated**, no other property values are required, but you have to configure your connection by following the steps for [Microsoft Entra authentication and Azure Cosmos DB connector](/connectors/documentdb/#azure-ad-authentication-and-cosmos-db-connector).  |
 | **Access key to your Azure Cosmos DB account** | Yes | <*access-key*> | The access key for the Azure Cosmos DB account to use for this connection. This value is either a read-write key or a read-only key. <p><p>**Note**: To find the key, go to the Azure Cosmos DB account page. In the navigation menu, under **Settings**, select **Keys**. Copy one of the available key values. |
-| **Account Id** | Yes | <*acccount-ID*> | The name for the Azure Cosmos DB account to use for this connection. |
+| **Account Id** | Yes | <*account-ID*> | The name for the Azure Cosmos DB account to use for this connection. |
 |||||
 
 The following image shows an example connection:

articles/connectors/connectors-create-api-servicebus.md

@@ -336,7 +336,7 @@ The steps to add and use a Service Bus trigger differ based on whether you want
 
 #### Built-in connector trigger
 
-By default, the Service Bus built-in connector is a stateless connector. To run this connector's operations in stateful mode, see [Enable stateful mode for stateless built-in connectors](enable-stateful-affinity-built-in-connectors.md). Also, Service Bus built-in non-session triggers follow the [*push trigger* pattern](introduction.md#triggers), while session-based triggers provide polling capabilty.
+By default, the Service Bus built-in connector is a stateless connector. To run this connector's operations in stateful mode, see [Enable stateful mode for stateless built-in connectors](enable-stateful-affinity-built-in-connectors.md). Also, Service Bus built-in non-session triggers follow the [*push trigger* pattern](introduction.md#triggers), while session-based triggers provide polling capability.
 
 1. In the [Azure portal](https://portal.azure.com), and open your Standard logic app resource with blank workflow in the designer.
 

articles/connectors/connectors-native-reqres.md

@@ -146,7 +146,7 @@ The **Request** trigger creates a manually callable endpoint that handles *only*
 
 1. To check that the inbound call has a request body that matches your specified schema, follow these steps:
 
-   1. To enforce the inbound message to have the same exact fields that your schema describes, in your schema, add the **`required`** property and specify the required fields. Add the **`addtionalProperties`** property, and set the value to **`false`**.
+   1. To enforce the inbound message to have the same exact fields that your schema describes, in your schema, add the **`required`** property and specify the required fields. Add the **`additionalProperties`** property, and set the value to **`false`**.
 
       For example, the following schema specifies that the inbound message must have the **`msg`** field and not any other fields:
 
@@ -301,7 +301,7 @@ The **Request** trigger creates a manually callable endpoint that handles *only*
 
 1. To check that the inbound call has a request body that matches your specified schema, follow these steps:
 
-   1. To enforce the inbound message to have the same exact fields that your schema describes, in your schema, add the **`required`** property and specify the required fields. Add the **`addtionalProperties`** property, and set the value to **`false`**.
+   1. To enforce the inbound message to have the same exact fields that your schema describes, in your schema, add the **`required`** property and specify the required fields. Add the **`additionalProperties`** property, and set the value to **`false`**.
 
       For example, the following schema specifies that the inbound message must have the **`msg`** field and not any other fields:
 

articles/connectors/connectors-native-webhook.md

@@ -82,7 +82,7 @@ This built-in trigger calls the subscribe endpoint on the target service and reg
 
    > [!NOTE]
    >
-   > For the **Unsubsubscribe - Method** and **Unsubscribe - URI** properties, add them 
+   > For the **Unsubscribe - Method** and **Unsubscribe - URI** properties, add them 
    > to your action by opening the **Advanced parameters** list.
 
    For example, the following trigger includes the methods, URIs, and message bodies to use when performing the subscribe and unsubscribe operations.
@@ -159,7 +159,7 @@ This example uses the **HTTP Webhook** trigger as the first step.
 
    > [!NOTE]
    >
-   > For the **Unsubsubscribe - Method** and **Unsubscribe - URI** properties, add them 
+   > For the **Unsubscribe - Method** and **Unsubscribe - URI** properties, add them 
    > to your action by opening the **Advanced parameters** list.
 
    For example, the following action includes the methods, URIs, and message bodies to use when performing the subscribe and unsubscribe operations.

articles/container-apps/blue-green-deployment.md

@@ -282,10 +282,10 @@ export APP_DOMAIN=$(az containerapp env show -g $RESOURCE_GROUP -n $APP_ENVIRONM
 #Test the production FQDN
 curl -s https://$APP_NAME.$APP_DOMAIN/api/env | jq | grep COMMIT
 
-#Test the blue lable FQDN
+#Test the blue label FQDN
 curl -s https://$APP_NAME---blue.$APP_DOMAIN/api/env | jq | grep COMMIT
 
-#Test the green lable FQDN
+#Test the green label FQDN
 curl -s https://$APP_NAME---green.$APP_DOMAIN/api/env | jq | grep COMMIT
 ```
 

articles/container-apps/enable-dapr.md

@@ -61,7 +61,7 @@ When using an IaC template, specify the following arguments in the `properties.c
   "dapr": {
     "enabled": true,
     "appId": "nodeapp",
-    "appProcotol": "http",
+    "appProtocol": "http",
     "appPort": 3000
   }
 ```