Merge pull request #276424 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/aks/concepts-vulnerability-management.md

@@ -77,7 +77,7 @@ The following table describes vulnerability severity categories:
 
 AKS patches Common Vulnerabilities and Exposures (CVEs) that have a *vendor fix* every week. Any CVEs without a fix are waiting on a vendor fix before they can be remediated. The fixed container images are cached in the next corresponding virtual hard disk (VHD) build, which also contains the updated Ubuntu/Azure Linux/Windows patched CVEs. As long as you're running the updated VHD, you shouldn't be running any container image CVEs with a vendor fix that is over 30 days old.  
 
-For the OS-based vulnerabilities in the VHD, AKS also relies on node image vhd updates by default, so any security updates will come with weekly node image releases . Unattended upgrades is disabled unless you switch to unmanaged which is not recommended as its release is global.
+For the OS-based vulnerabilities in the VHD, AKS also relies on node image vhd updates by default, so any security updates will come with weekly node image releases. Unattended upgrades is disabled unless you switch to unmanaged which is not recommended as its release is global.
 
 ## Update release timelines
 
@@ -103,7 +103,7 @@ Include the following requested information (as much as you can provide) to help
   * Any special configuration required to reproduce the issue
   * Step-by-step instructions to reproduce the issue
   * Proof-of-concept or exploit code (if possible)
-  * Impact of the issue, including how an attacker might exploit the issue.
+  * Impact of the issue, including how an attacker might exploit the issue
 
 This information helps us triage your reported security issue quicker.
 

articles/aks/supported-kubernetes-versions.md

@@ -310,15 +310,15 @@ To upgrade from *1.27.x* -> *1.29.x*:
 
 Skipping multiple versions can only be done when upgrading from an unsupported version back into the minimum supported version. For example, you can upgrade from an unsupported *1.25.x* to a supported *1.27.x* if *1.27* is the minimum supported minor version.
 
-When performing an upgrade from an _unsupported version_ that skips two or more minor versions, the upgrade is performed without any guarantee of functionality and is excluded from the service-level agreements and limited warranty.Clusters running _unsupported version_ has the flexibility of decoupling control plane upgrades with node pool upgrades. However if your version is significantly out of date, we recommend that you re-create the cluster.
+When performing an upgrade from an _unsupported version_ that skips two or more minor versions, the upgrade is performed without any guarantee of functionality and is excluded from the service-level agreements and limited warranty. Clusters running _unsupported version_ has the flexibility of decoupling control plane upgrades with node pool upgrades. However if your version is significantly out of date, we recommend that you re-create the cluster.
 
 ### Can I create a new 1.xx.x cluster during its 30 day support window?
 
 No. Once a version is deprecated/removed, you can't create a cluster with that version. As the change rolls out, you'll start to see the old version removed from your version list. This process might take up to two weeks from announcement, progressively by region.
 
 ### I'm on a freshly deprecated version, can I still add new node pools? Or will I have to upgrade?
 
-No. You aren't allowed to add node pools of the deprecated version to your cluster. Creation or upgrade of node pools upto the _unsupported version_ control plane version is allowed , irrespective of version difference between node pool and the control plane. Only alias minor upgrades are allowed.
+No. You aren't allowed to add node pools of the deprecated version to your cluster. Creation or upgrade of node pools upto the _unsupported version_ control plane version is allowed, irrespective of version difference between node pool and the control plane. Only alias minor upgrades are allowed.
 
 ### How often do you update patches?
 

articles/azure-monitor/essentials/metrics-store-custom-rest-api.md

@@ -202,7 +202,7 @@ Submit the following HTTP POST request by using the following variables:
 + `accessToken`: The authorization token acquired from the *Get an authorization token* step.
 
     ```console
-    curl -X POST 'https://<location>/.monitoring.azure.com<resourceId>/metrics' \
+    curl -X POST 'https://<location>.monitoring.azure.com/<resourceId>/metrics' \
     -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer <accessToken>' \
     -d @custommetric.json 

articles/virtual-machines/trusted-launch-portal.md

@@ -550,7 +550,7 @@ New-AzVM `
 ---
 ## Trusted Launch Built-In Policies
 
-To help end-users adopt Trusted Launch, there is Azure policies available to help resource owners adopt Trusted Launch. The main objbective being to help convert Generation 1 and 2 Virtual Machines that are Trusted Launch capable. **Virtual Machine should have Trusted Launch enabled** single policy checks if the virtual machine, currently enabled with Trusted Launch security configurations. **Disks and OS Supported for Trusted Launch** checks if previously created virtual machines has the [capable Generation 2 operating system and virtual machine size](trusted-launch.md#virtual-machines-sizes) to deploy a Trusted Launch virtual machines. These two policies come together to make the Trusted Launch policy initative, enabling you to group several related policy definitions to simplify assignments and management resources to include Trusted Launch configuration.  
+To help end-users adopt Trusted Launch, there is Azure policies available to help resource owners adopt Trusted Launch. The main objective being to help convert Generation 1 and 2 Virtual Machines that are Trusted Launch capable. **Virtual Machine should have Trusted Launch enabled** single policy checks if the virtual machine, currently enabled with Trusted Launch security configurations. **Disks and OS Supported for Trusted Launch** checks if previously created virtual machines has the [capable Generation 2 operating system and virtual machine size](trusted-launch.md#virtual-machines-sizes) to deploy a Trusted Launch virtual machines. These two policies come together to make the Trusted Launch policy initative, enabling you to group several related policy definitions to simplify assignments and management resources to include Trusted Launch configuration.  
 
 To learn more, and start deploying the [Trusted Launch built-in policies](../governance/policy/samples/built-in-policies.md#trusted-launch).