Merge pull request #86603 from MicrosoftDocs/repo_sync_working_branch

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

Author: huypub

articles/aks/use-pod-security-policies.md

@@ -28,7 +28,7 @@ You need the Azure CLI version 2.0.61 or later installed and configured. Run `a
 
 ### Install aks-preview CLI extension
 
-To use pod security policies, you need the *aks-preview* CLI extension version 0.4.1 or higher. Install the *aks-preview* Azure CLI extension using the [az extension add][az-extension-add] command, then check for any available updates using the [az extension update][az-extension-update] command::
+To use pod security policies, you need the *aks-preview* CLI extension version 0.4.1 or higher. Install the *aks-preview* Azure CLI extension using the [az extension add][az-extension-add] command, then check for any available updates using the [az extension update][az-extension-update] command:
 
 ```azurecli-interactive
 # Install the aks-preview extension
@@ -67,7 +67,7 @@ In a Kubernetes cluster, an admission controller is used to intercept requests t
 
 *PodSecurityPolicy* is an admission controller that validates a pod specification meets your defined requirements. These requirements may limit the use of privileged containers, access to certain types of storage, or the user or group the container can run as. When you try to deploy a resource where the pod specifications don't meet the requirements outlined in the pod security policy, the request is denied. This ability to control what pods can be scheduled in the AKS cluster prevents some possible security vulnerabilities or privilege escalations.
 
-When you enable pod security policy in an AKS cluster, some default policies are applied. These default policies provide an out-of-the-box experience to define what pods can be scheduled. However, cluster users may run into problems deploying pods until you define your own policies. The recommend approach is to:
+When you enable pod security policy in an AKS cluster, some default policies are applied. These default policies provide an out-of-the-box experience to define what pods can be scheduled. However, cluster users may run into problems deploying pods until you define your own policies. The recommended approach is to:
 
 * Create an AKS cluster
 * Define your own pod security policies
@@ -132,7 +132,7 @@ It's important to understand how these default policies interact with user reque
 
 ## Create a test user in an AKS cluster
 
-By default, when you use the [az aks get-credentials][az-aks-get-credentials] command, the *admin* credentials for the AKS cluster and added to your `kubectl` config. The admin user bypasses the enforcement of pod security policies. If you use Azure Active Directory integration for your AKS clusters, you could sign in with the credentials of a non-admin user to see the enforcement of policies in action. In this article, let's create a test user account in the AKS cluster that you can use.
+By default, when you use the [az aks get-credentials][az-aks-get-credentials] command, the *admin* credentials for the AKS cluster are added to your `kubectl` config. The admin user bypasses the enforcement of pod security policies. If you use Azure Active Directory integration for your AKS clusters, you could sign in with the credentials of a non-admin user to see the enforcement of policies in action. In this article, let's create a test user account in the AKS cluster that you can use.
 
 Create a sample namespace named *psp-aks* for test resources using the [kubectl create namespace][kubectl-create] command. Then, create a service account named *nonadmin-user* using the [kubectl create serviceaccount][kubectl-create] command:
 
@@ -198,7 +198,7 @@ $ kubectl-nonadminuser apply -f nginx-privileged.yaml
 Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
 ```
 
-The pod doesn't reach the scheduling stage, so there's no resources to delete before you move on.
+The pod doesn't reach the scheduling stage, so there are no resources to delete before you move on.
 
 ## Test creation of an unprivileged pod
 
@@ -439,7 +439,7 @@ kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
 ```
 
 > [!NOTE]
-> In the first step of this article, the pod security policy feature was enabled on the AKS cluster. The recommended practice was to only enable the pod security policy feature after you've defined your own policies. This is the stage where you would enable the pod security policy feature. One or more custom policies have been defined, and user accounts have been associated with those policies. Now you can safely the pod security policy feature and minimize problems caused by the default policies.
+> In the first step of this article, the pod security policy feature was enabled on the AKS cluster. The recommended practice was to only enable the pod security policy feature after you've defined your own policies. This is the stage where you would enable the pod security policy feature. One or more custom policies have been defined, and user accounts have been associated with those policies. Now you can safely enable the pod security policy feature and minimize problems caused by the default policies.
 
 ## Test the creation of an unprivileged pod again
 

articles/governance/management-groups/index.md

@@ -32,12 +32,12 @@ example of creating a hierarchy for governance using management groups.
 
 ![Example of a management group hierarchy tree](./media/tree.png)
 
-Create a hierarchy so you can apply a policy, for example, limit VM locations
-to US West Region on the group "Production". This policy will inherit onto both EA subscriptions under that management
+You can create a hierarchy that applies a policy, for example, which limits VM locations
+to the US West Region in the group called "Production". This policy will inherit onto both EA subscriptions under that management
 group and will apply to all VMs under those subscriptions. This security policy cannot be altered by the resource or
 subscription owner allowing for improved governance.
 
-Another scenario where you would use management groups is to provide user access to multi
+Another scenario where you would use management groups is to provide user access to multiple
 subscriptions. By moving multiple subscriptions under that management group, you can create one [role-based access control](../../role-based-access-control/overview.md) (RBAC)
 assignment on the management group, which will inherit that access to all the subscriptions.
 One assignment on the management group can enable users to have access to everything they need instead of scripting RBAC over different subscriptions.
@@ -70,7 +70,7 @@ root group initially. After elevating access, the administrator can assign any R
   - New subscriptions are automatically defaulted to the root management group when created.
 - All Azure customers can see the root management group, but not all customers have access to manage that root management group.
   - Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy.  
-  - No one is given default access to the root management group. Azure AD Global Administrators are the only users that can elevate themselves to gain access.  Once they have access, the global administrators can assign any RBAC role to other users to manage.  
+  - No one is given default access to the root management group. Azure AD Global Administrators are the only users that can elevate themselves to gain access.  Once they have access to the root management group, the global administrators can assign any RBAC role to other users to manage it.  
 
 > [!IMPORTANT]
 > Any assignment of user access or policy assignment on the root management group **applies to all resources within the directory**.
@@ -149,4 +149,4 @@ To learn more about management groups, see:
 - [How to change, delete, or manage your management groups](manage.md)
 - [Review management groups in Azure PowerShell Resources Module](/powershell/module/az.resources#resources)
 - [Review management groups in REST API](/rest/api/resources/managementgroups)
-- [Review management groups in Azure CLI](/cli/azure/account/management-group)
+- [Review management groups in Azure CLI](/cli/azure/account/management-group)

articles/storage/files/storage-sync-files-planning.md

@@ -240,7 +240,7 @@ Azure File Sync is available only in the following regions:
 |--------|---------------------|
 | Australia East | New South Wales |
 | Australia Southeast | Victoria |
-| Brazil South | Sao Paolo State |
+| Brazil South | Sao Paulo State |
 | Canada Central | Toronto |
 | Canada East | Quebec City |
 | Central India | Pune |