Apply suggestions from code review

Author: Danielabom

api-reference/beta/api/appmanagementpolicy-post.md

@@ -70,7 +70,7 @@ The following example shows a request. This request created an app management po
 - Enables the policy.
 - Blocks creating of new passwords for applications and service principals created on or after October 19th 2019 at 10:37 AM UTC time.
 - Limits password secrets for apps and service principals created after October 19th 2014 at 10:37 AM UTC time to less than 90 days.
-- Disables the nonDefaultUriAddition restriction. This means that apps with this policy applied to them are able to add new nondefault identifier URIs to their apps, even if the tenant default policy would typically block it.
+- Disables the nonDefaultUriAddition restriction. This means that apps with this policy applied to them can add new nondefault identifier URIs to their apps, even if the tenant default policy typically blocks it.
 - Doesn't specify any other restrictions. This means that the behavior for those restrictions on apps/service principals with this policy applied falls back to however the tenant default policy is configured.
 
 

api-reference/beta/resources/applicationauthenticationmethodpolicy.md

@@ -35,10 +35,10 @@ These properties enable an organization to separately control the configuration
 
 App management policies are defined in the [appManagementPolicy](appmanagementpolicy.md) resource, which contains a collection of policies with varying restrictions or different enforcement dates from what's defined in tenant default policy. One of these policies can be assigned to an application or service principal to override the tenant default policy.
 
-When the tenant default policy and an app management policy both define the same restriction, the app management policy takes precedence.  If a restriction is set on an app management policy in a `disabled` state, that restriction won't apply to apps with that policy linked to them, regardless of what the tenant default policy would normally enforce.  Similarly, if a restriction is set on an app management policy in an `enabled` state, that restriction will apply to apps with that policy linked to them.  However, if the app management policy doesn't define any behavior for a certain restriction, it will fall back to the tenant default policy's behavior. Only one app management policy can be assigned to an application or service principal.
+When the tenant default policy and an app management policy define the same restriction, the app management policy takes precedence.  If a restriction is set on an app management policy in a `disabled` state, that restriction won't apply to apps with that policy linked to them, regardless of what the tenant default policy would normally enforce.  Similarly, if a restriction is set on an app management policy in an `enabled` state, that restriction will apply to apps with that policy linked to them.  However, if the app management policy doesn't define any behavior for a certain restriction, it falls back to the tenant default policy's behavior. Only one app management policy can be assigned to an application or service principal.
 
 > [!Note]
-> Neither the tenant default policies nor the app management policies block token issuance for existing applications. An application that does not meet the policy requirements will continue to work; only the app creation/update operation that violates the policy will be blocked.
+> Neither the tenant default nor the app management policies block token issuance for existing applications. An application that doesn't meet the policy requirements continues to work; only the app creation/update operation that violates the policy is blocked.
 
 ## What restrictions can be managed in Microsoft Graph?