"Fixing Azrolinx Issues"

Author: shanhix1

articles/governance/policy/concepts/effects.md

@@ -25,12 +25,12 @@ These effects are currently supported in a policy definition:
 
 ## Interchanging effects
 
-Sometimes multiple effects can be valid for a given policy definition. Parameters are often used to specify allowed effect values so that a single definition can be more versatile. However, it is important to note that not all effects are interchangeable. Resource properties and logic in the policy rule can determine whether a cerain effect is considered valid to the policy definition. For example, policy definitions with effect **AuditIfNotExists** require additional details in the policy rule which are not required for policies with effect **Audit**. The effects also behave differently. **Audit** policies will assess a resource's compliance based on its own properties, while **AuditIfNotExists** policies will assess a resource's compliance based on a child or extension resource's properties.
+Sometimes multiple effects can be valid for a given policy definition. Parameters are often used to specify allowed effect values so that a single definition can be more versatile. However, it's important to note that not all effects are interchangeable. Resource properties and logic in the policy rule can determine whether a certain effect is considered valid to the policy definition. For example, policy definitions with effect **AuditIfNotExists** require additional details in the policy rule that aren't required for policies with effect **Audit**. The effects also behave differently. **Audit** policies will assess a resource's compliance based on its own properties, while **AuditIfNotExists** policies will assess a resource's compliance based on a child or extension resource's properties.
 
-The following is general guidance around interchangeable effects:
+Below is some general guidance around interchangeable effects:
 - **Audit**, **Deny**, and either **Modify** or **Append** are often interchangeable.
 - **AuditIfNotExists** and **DeployIfNotExists** are often interchangeable.
-- **Manual** is not interchangeable.
+- **Manual** isn't interchangeable.
 - **Disabled** is interchangeable with any effect.
 
 ## Order of evaluation
@@ -162,7 +162,7 @@ definitions as `constraintTemplate` is deprecated.
       template. See
       [Create policy definition from constraint template](../how-to/extension-for-vscode.md) to
       create a custom definition from an existing
-      [Open Policy Agent](https://www.openpolicyagent.org/) (OPA) GateKeeper v3
+      [Open Policy Agent](https://www.openpolicyagent.org/) (OPA) Gatekeeper v3
       [constraint template](https://open-policy-agent.github.io/gatekeeper/website/docs/howto/#constraint-templates).
 - **constraint** (deprecated)
   - Can't be used with `templateInfo`.
@@ -173,7 +173,7 @@ definitions as `constraintTemplate` is deprecated.
   - An _array_ of
     [Kubernetes namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
     to limit policy evaluation to.
-  - An empty or missing value causes policy evaluation to include all namespaces, except those
+  - An empty or missing value causes policy evaluation to include all namespaces not
     defined in _excludedNamespaces_.
 - **excludedNamespaces** (required)
   - An _array_ of
@@ -374,7 +374,7 @@ definitions as `constraintTemplate` is deprecated.
       template. See
       [Create policy definition from constraint template](../how-to/extension-for-vscode.md) to
       create a custom definition from an existing
-      [Open Policy Agent](https://www.openpolicyagent.org/) (OPA) GateKeeper v3
+      [Open Policy Agent](https://www.openpolicyagent.org/) (OPA) Gatekeeper v3
       [constraint template](https://open-policy-agent.github.io/gatekeeper/website/docs/howto/#constraint-templates).
 - **constraint** (optional)
   - Can't be used with `templateInfo`.
@@ -693,7 +693,7 @@ The following operations are supported by Modify:
 - Add, replace, or remove resource tags. For tags, a Modify policy should have `mode` set to
   _Indexed_ unless the target resource is a resource group.
 - Add or replace the value of managed identity type (`identity.type`) of virtual machines and
-  virtual machine scale sets.
+  Virtual Machine Scale Sets.
 - Add or replace the values of certain aliases.
   - Use
     `Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' }`
@@ -748,11 +748,11 @@ needed for remediation and the **operations** used to add, update, or remove tag
   - Determines which policy definition "wins" if more than one policy definition modifies the same
     property or when the Modify operation doesn't work on the specified alias.
     - For new or updated resources, the policy definition with _deny_ takes precedence. Policy
-      definitions with _audit_ skip all **operations**. If more than one policy definition has
+      definitions with _audit_ skip all **operations**. If more than one policy definition has the effect
       _deny_, the request is denied as a conflict. If all policy definitions have _audit_, then none
       of the **operations** of the conflicting policy definitions are processed.
-    - For existing resources, if more than one policy definition has _deny_, the compliance status
-      is _Conflict_. If one or fewer policy definitions have _deny_, each assignment returns a
+    - For existing resources, if more than one policy definition has the effect _deny_, the compliance status
+      is _Conflict_. If one or fewer policy definitions have the effect _deny_, each assignment returns a
       compliance status of _Non-compliant_.
   - Available values: _audit_, _deny_, _disabled_.
   - Default value is _deny_.

articles/governance/policy/concepts/policy-applicability.md

@@ -8,7 +8,7 @@ author: timwarner-msft
 ---
 # What is applicability in Azure Policy?
 
-When a policy definition is assigned to a scope, Azure Policy determines which resources in that scope should be considered for compliance evaluation. A resource will only be assessed for compliance if it is considered **applicable** to the given policy assignment. 
+When a policy definition is assigned to a scope, Azure Policy determines which resources in that scope should be considered for compliance evaluation. A resource will only be assessed for compliance if it's considered **applicable** to the given policy assignment. 
 
 Applicability is determined by several factors:
 - **Conditions** in the `if` block of the [policy rule](../concepts/definition-structure.md#policy-rule).
@@ -21,7 +21,7 @@ Condition(s) in the `if` block of the policy rule are evaluated for applicabilit
 > [!NOTE]
 > Applicability is different from compliance, and the logic used to determine each is different. If a resource is **applicable** that means it is relevant to the policy. If a resource is **compliant** that means it adheres to the policy. Sometimes only certain conditions from the policy rule impact applicability, while all conditions of the policy rule impact compliance state.
 
-## Applicability logic for resource manager modes
+## Applicability logic for Resource Manager modes
 
 ### Append, Audit, Manual, Modify and Deny policy effects
 
@@ -31,21 +31,21 @@ Following are special cases to the previously described applicability logic:
 
 |Scenario  |Result  |
 |---------|---------|
-|Any invalid aliases in the `if` conditions     |The policy is not applicable |
+|Any invalid aliases in the `if` conditions     |The policy isn't applicable |
 |When the `if` conditions consist of only `kind` conditions     |The policy is applicable to all resources |
 |When the `if` conditions consist of only `name` conditions     |The policy is applicable to all resources |
 |When the `if` conditions consist of only `type` and `kind` or `type` and `name` conditions     |Only type conditions are considered when deciding applicability |
-|When any conditions (including deployment parameters) include a `location` condition     |Will not be applicable to subscriptions |
+|When any conditions (including deployment parameters) include a `location` condition     |Won't be applicable to subscriptions |
 
 ### AuditIfNotExists and DeployIfNotExists policy effects
 
-The applicability of `AuditIfNotExists` and `DeployIfNotExists` policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy is not applicable.
+The applicability of `AuditIfNotExists` and `DeployIfNotExists` policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy isn't applicable.
 
 ## Applicability logic for resource provider modes
 
 ### Microsoft.Kubernetes.Data
 
-The applicability of `Microsoft.Kubernetes.Data` policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy is not applicable.
+The applicability of `Microsoft.Kubernetes.Data` policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy isn't applicable.
 
 ### Microsoft.KeyVault.Data
 

articles/governance/policy/how-to/get-compliance-data.md

@@ -10,8 +10,8 @@ ms.author: timwarner
 
 One of the largest benefits of Azure Policy is the insight and controls it provides over resources
 in a subscription or [management group](../../management-groups/overview.md) of subscriptions. This
-control can be exercised in many different ways, such as preventing resources being created in the
-wrong location, enforcing common and consistent tag usage, or auditing existing resources for
+control can be used to prevent resources from being created in the
+wrong location, enforce common and consistent tag usage, or audit existing resources for
 appropriate configurations and settings. In all cases, data is generated by Azure Policy to enable
 you to understand the compliance state of your environment.
 
@@ -40,10 +40,9 @@ operations of the Azure Policy Insights REST API, see
 Evaluations of assigned policies and initiatives happen as the result of various events:
 
 - A policy or initiative is newly assigned to a scope. It takes around five minutes for the assignment
-  to be applied to the defined scope. Once it's applied, the evaluation cycle begins for resources
-  within that scope against the newly assigned policy or initiative and depending on the effects
-  used by the policy or initiative, resources are marked as compliant, non-compliant, or exempt. A
-  large policy or initiative evaluated against a large scope of resources can take time. As such,
+  to be applied to the defined scope, then the evaluation cycle begins for applicable resources against the newly assigned policy or initiative. Depending on the effects
+  used, resources are marked as compliant, non-compliant, exempt, or unknown. A
+  large policy or initiative evaluated against a large scope of resources can take time, so
   there's no pre-defined expectation of when the evaluation cycle completes. Once it completes,
   updated compliance results are available in the portal and SDKs.
 
@@ -96,7 +95,7 @@ to trigger an on-demand evaluation scan from your
 [GitHub workflow](https://docs.github.com/actions/configuring-and-managing-workflows/configuring-a-workflow#about-workflows)
 on one or multiple resources, resource groups, or subscriptions, and gate the workflow based on the
 compliance state of resources. You can also configure the workflow to run at a scheduled time so
-that you get the latest compliance status at a convenient time. Optionally, this GitHub Actions can
+that you get the latest compliance status at a convenient time. Optionally, GitHub Actions can
 generate a report on the compliance state of scanned resources for further analysis or for
 archiving.
 
@@ -249,7 +248,7 @@ Azure Policy supports the following compliance states:
 
 ### Compliant and non-compliant states
 
-In an assignment, a resource is **non-compliant** if it is applicable to the policy assignment and does not adhere to conditions in the policy rule. The following table shows how different policy effects work with the condition evaluation for the resulting compliance state:
+In an assignment, a resource is **non-compliant** if it's applicable to the policy assignment and doesn't adhere to conditions in the policy rule. The following table shows how different policy effects work with the condition evaluation for the resulting compliance state:
 
 | Resource State | Effect | Policy Evaluation | Compliance State |
 | --- | --- | --- | --- |
@@ -274,7 +273,7 @@ For example, assume that you have a resource group - ContsoRG, with some storage
 
 In this example, you need to be wary of security risks. Now that you've created a policy assignment,
 it's evaluated for all included and non-exempt storage accounts in the ContosoRG resource group. It
-audits the three non-compliant storage accounts, consequently changing their states to
+audits the three non-compliant storage accounts, changing their states to
 **Non-compliant.**
 
 :::image type="complex" source="../media/getting-compliance-data/resource-group03.png" alt-text="Diagram of storage account compliance in the Contoso R G resource group." border="false":::
@@ -302,7 +301,7 @@ Besides **Compliant** and **Non-compliant**, policies and resources have four ot
 Azure Policy relies on several factors to determine whether a resource is considered [applicable](../concepts/policy-applicability.md), then to determine its compliance state.
 
 The compliance percentage is determined by dividing **Compliant**, **Exempt**, and **Unknown** resources by _total
-resources_. _Total resources_ is defined as the sum of the **Compliant**, **Non-compliant**,
+resources_. _Total resources_ include **Compliant**, **Non-compliant**,
 **Exempt**, and **Conflicting** resources. The overall compliance numbers are the sum of distinct
 resources that are **Compliant**, **Exempt**, and **Unknown** divided by the sum of all distinct resources. In the
 image below, there are 20 distinct resources that are applicable and only one is **Non-compliant**.
@@ -315,7 +314,7 @@ The overall resource compliance is 95% (19 out of 20).
 > pages in portal are different for enabled initiatives. For more information, see
 > [Regulatory Compliance](../concepts/regulatory-compliance.md)
 
-### Compliance roll up
+### Compliance rollup
 
 There are several ways to view aggregated compliance results:
 
@@ -335,7 +334,7 @@ So how is the aggregate compliance state determined if multiple resources or pol
 
 This means that if there are both non-compliant and compliant states, the rolled up aggregate would be non-compliant, and so on. Let's look at an example.
 
-Assume an initiative contains 10 policies, and a resource is exempt from one policy but compliant to the remaining nine. Because a compliant state has a higher rank than an exempted state, the resource would register as compliant in the rolled-up summary of the initiative. So, a resource will only show as exempt for the entire initiative if it is exempt from, or has unknown compliance to, every other single applicable policy in that initiative. On the other extreme, if the resource is non-compliant to at least one applicable policy in the initiative, it will have an overall compliance state of non-compliant, regardless of the remaining applicable policies.
+Assume an initiative contains 10 policies, and a resource is exempt from one policy but compliant to the remaining nine. Because a compliant state has a higher rank than an exempted state, the resource would register as compliant in the rolled-up summary of the initiative. So, a resource will only show as exempt for the entire initiative if it's exempt from, or has unknown compliance to, every other single applicable policy in that initiative. On the other extreme, if the resource is non-compliant to at least one applicable policy in the initiative, it will have an overall compliance state of non-compliant, regardless of the remaining applicable policies.
 
 ## Portal
 
@@ -374,7 +373,7 @@ history.
 Back on the resource compliance page, select and hold (or right-click) on the row of the event you
 would like to gather more details on and select **Show activity logs**. The activity log page opens
 and is pre-filtered to the search showing details for the assignment and the events. The activity
-log provides additional context and information about those events.
+log provides more context and information about those events.
 
 :::image type="content" source="../media/getting-compliance-data/compliance-activitylog.png" alt-text="Screenshot of the Activity Log for Azure Policy activities and evaluations." border="false":::
 
@@ -392,7 +391,7 @@ Use ARMClient or a similar tool to handle authentication to Azure for the REST A
 
 ### Summarize results
 
-With the REST API, summarization can be performed by container, definition, or assignment. Here is
+With the REST API, summarization can be performed by container, definition, or assignment. Here's
 an example of summarization at the subscription level using Azure Policy Insight's [Summarize For
 Subscription](/rest/api/policy/policystates/summarizeforsubscription):
 
@@ -404,7 +403,7 @@ The output summarizes the subscription. In the example output below, the summari
 under **value.results.nonCompliantResources** and **value.results.nonCompliantPolicies**. This
 request provides further details, including each assignment that made up the non-compliant numbers
 and the definition information for each assignment. Each policy object in the hierarchy provides a
-**queryResultsUri** that can be used to get additional detail at that level.
+**queryResultsUri** that can be used to get more detail at that level.
 
 ```json
 {
@@ -443,7 +442,7 @@ and the definition information for each assignment. Each policy object in the hi
 ### Query for resources
 
 In the example above, **value.policyAssignments.policyDefinitions.results.queryResultsUri** provides
-a sample URI for all non-compliant resources for a specific policy definition. Looking at the
+a sample URI for all non-compliant resources for a specific policy definition. In the
 **$filter** value, ComplianceState is equal (eq) to 'NonCompliant', PolicyAssignmentId is specified
 for the policy definition, and then the PolicyDefinitionId itself. The reason for including the
 PolicyAssignmentId in the filter is because the PolicyDefinitionId could exist in several policy or