Fixing unrelated acrolinx issues

JackStromberg · web-flow · commit ad334b7b6b2c · 2023-02-26T08:29:37.000-06:00
diff --git a/articles/application-gateway/application-gateway-faq.yml b/articles/application-gateway/application-gateway-faq.yml
@@ -6,7 +6,7 @@ metadata:
   author: greg-lindsay
   ms.service: application-gateway
   ms.topic: faq
-  ms.date: 02/24/2023
+  ms.date: 02/26/2023
   ms.author: greglin
   ms.custom: references_regions
 title: Frequently asked questions about Application Gateway
@@ -59,15 +59,15 @@ sections:
           
       - question: Where do I find the Application Gateway IP and DNS?
         answer: |
-          If you're using a public IP address as an endpoint, you'll find the IP and DNS information on the public IP address resource. Or find it in the portal, on the overview page for the application gateway. If you're using internal IP addresses, find the information on the overview page.
+          If you're using a public IP address as an endpoint, you find the IP and DNS information on the public IP address resource. Or find it in the portal, on the overview page for the application gateway. If you're using internal IP addresses, find the information on the overview page.
           
           For the v2 SKU, open the public IP resource and select **Configuration**. The **DNS name label (optional)** field is available to configure the DNS name.
           
       - question: What are the settings for Keep-Alive timeout and TCP idle timeout?
         answer: |
-          *Keep-Alive timeout* governs how long the Application Gateway will wait for a client to send another HTTP request on a persistent connection before reusing it or closing it. *TCP idle timeout* governs how long a TCP connection is kept open if there is no activity. 
+          *Keep-Alive timeout* governs how long the Application Gateway waits for a client to send another HTTP request on a persistent connection before reusing it or closing it. *TCP idle timeout* governs how long a TCP connection is kept open if there is no activity. 
           
-          The *Keep-Alive timeout* in the Application Gateway v1 SKU is 120 seconds and in the v2 SKU it's 75 seconds. The *TCP idle timeout* is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateways to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateways, you'll need to navigate to the public IP of the Application Gateway and change the TCP idle timeout under the "Configuration" blade of the public IP on Portal. Changing the value of the private IP address isn't supported. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands: 
+          The *Keep-Alive timeout* in the Application Gateway v1 SKU is 120 seconds and in the v2 SKU it's 75 seconds. The *TCP idle timeout* is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateways to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateways, you need to navigate to the public IP of the Application Gateway and change the TCP idle timeout under the "Configuration" blade of the public IP on Portal. Changing the value of the private IP address isn't supported. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands: 
           
           ```azurepowershell-interactive
           $publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
@@ -129,15 +129,15 @@ sections:
         answer: |
           Yes. For details see, [Migrate Azure Application Gateway and Web Application Firewall from v1 to v2](migrate-v1-v2.md).
           
-      - question: Will the Application Gateway v1 SKU continue to be supported?
+      - question: Is Application Gateway v1 SKU supported?
         answer: |
-          Yes. The Application Gateway v1 SKU will continue to be supported. However, it is strongly recommended to move to v2 to take advantage of the feature updates in that SKU. For more information on the differences between v1 and v2 features, see [Autoscaling and Zone-redundant Application Gateway v2](application-gateway-autoscaling-zone-redundant.md). You can manually migrate Application Gateway v1 sku deployments to v2 by following our [v1-v2 migration document](migrate-v1-v2.md).
+          Yes. The Application Gateway v1 SKU continues to be supported. However, it is strongly recommended to move to v2 to take advantage of the feature updates in that SKU. For more information on the differences between v1 and v2 features, see [Autoscaling and Zone-redundant Application Gateway v2](application-gateway-autoscaling-zone-redundant.md). You can manually migrate Application Gateway v1 sku deployments to v2 by following our [v1-v2 migration document](migrate-v1-v2.md).
           
       - question: Does Application Gateway V2 support proxying requests with NTLM authentication?
         answer: No. Application Gateway V2 doesn't support proxying requests with NTLM authentication.
         
       - question: Why are some header values not present when requests are forwarded to my application?
-        answer: Request header names can contain alphanumeric characters and hyphens. Request header names containing other characters will be discarded when a request is sent to the backend target. Response header names can contain any alphanumeric characters and specific symbols as defined in [RFC 7230](https://tools.ietf.org/html/rfc7230#page-27), with the exception of underscores (\_).
+        answer: Request header names can contain alphanumeric characters and hyphens. Request header names containing other characters will be discarded when a request is sent to the backend target. Response header names can contain any alphanumeric characters and specific symbols as defined in [RFC 7230](https://tools.ietf.org/html/rfc7230#page-27), except for underscores (\_).
 
       - question: Does Application Gateway affinity cookie support SameSite attribute?
         answer: |
@@ -192,7 +192,7 @@ sections:
         
       - question: Can I change the virtual network or subnet for an existing Application Gateway?
         answer: |
-          You can move an Application Gateway across subnets within the same virtual network only. It is supported with V1 with public and private frontend, and V2 with public frontend only. It is also important to note that the Application Gateway should be in a *Stopped* state to perform this action. Keep in mind that stopping/starting V1 will change the public IP. This operation can only be done using Azure PowerShell and Azure CLI by running the following commands:
+          You can move an Application Gateway across subnets within the same virtual network only. It is supported with V1 with public and private frontend, and V2 with public frontend only. It is also important to note that the Application Gateway should be in a *Stopped* state to perform this action. Keep in mind that stopping/starting V1 changes the public IP. This operation can only be done using Azure PowerShell and Azure CLI by running the following commands:
           
           **Azure PowerShell**
 
@@ -225,7 +225,7 @@ sections:
           
       - question: Are service endpoint policies supported in the Application Gateway subnet?
         answer: |
-          No. [Service endpoint policies](../virtual-network/virtual-network-service-endpoint-policies-overview.md) for storage accounts aren't supported in Application Gateway subnet and configuring it will block Azure infrastructure traffic.
+          No. [Service endpoint policies](../virtual-network/virtual-network-service-endpoint-policies-overview.md) for storage accounts aren't supported in Application Gateway subnet and configuring it blocks Azure infrastructure traffic.
           
       - question: What are the limits on Application Gateway? Can I increase these limits?
         answer: |
@@ -286,7 +286,7 @@ sections:
               
               d. Keep the default rules like allowing VirtualNetwork inbound so that the access on private IP address isn't blocked
               
-              e. Outbound internet connectivity can't be blocked. Otherwise, you will face issues with logging, metrics, etc.
+              e. Outbound internet connectivity can't be blocked. Otherwise, you face issues with logging, metrics, etc.
           
           Sample NSG configuration for private IP only access:
           ![Application Gateway V2 NSG Configuration for private IP access only](./media/application-gateway-faq/appgw-privip-nsg.png)
@@ -413,7 +413,7 @@ sections:
           
           For Application Gateway specific information, see below -
           
-          If you're using a certificate issued by one of the revoked ICAs, your application’s availability might be interrupted and depending on your application, you may receive a variety of error messages including but not limited to: 
+          If you're using a certificate issued by one of the revoked ICAs, your application’s availability might be interrupted and depending on your application, you may receive various error messages including but not limited to: 
           
           1. Invalid certificate/revoked certificate
           2. Connection timed out
@@ -423,7 +423,7 @@ sections:
           
           1. Contact your certificate provider on how to reissue your certificates.
           2. Once reissued, update your certificates on the Azure Application Gateway/WAF with the complete [chain of trust](/windows/win32/seccrypto/certificate-chains) (leaf, intermediate, root certificate). Based on where you're using your certificate, either on the listener or the HTTP settings of the Application Gateway, follow the steps below to update the certificates and check the documentation links mentioned for more information.
-          3. Update your backend application servers to use the reissued certificate. Depending on the backend server that you're using, your certificate update steps may vary. Please check for the documentation from your vendor.
+          3. Update your backend application servers to use the reissued certificate. Depending on the backend server that you're using, your certificate update steps may vary. Check for the documentation from your vendor.
           
           To update the certificate in your listener:
           
@@ -468,21 +468,21 @@ sections:
 
       - question: Why is my AKS cluster with kubenet not working with AGIC?
         answer: |
-          AGIC tries to automatically associate the route table resource to the Application Gateway subnet but may fail to do so due to lack of permissions from the AGIC. If AGIC is unable to associate the route table to the Application Gateway subnet, there will be an error in the AGIC logs saying so, in which case you'll have to manually associate the route table created by the AKS cluster to the Application Gateway's subnet. For more information, see [Supported user-defined routes](configuration-infrastructure.md#supported-user-defined-routes).
+          AGIC tries to automatically associate the route table resource to the Application Gateway subnet but may fail to do so due to lack of permissions from the AGIC. If AGIC is unable to associate the route table to the Application Gateway subnet, there will be an error in the AGIC logs saying so, in which case you have to manually associate the route table created by the AKS cluster to the Application Gateway's subnet. For more information, see [Supported user-defined routes](configuration-infrastructure.md#supported-user-defined-routes).
           
       - question: Can I connect my AKS cluster and Application Gateway in separate virtual networks? 
         answer: Yes, as long as the virtual networks are peered and they don't have overlapping address spaces. If you're running AKS with kubenet, then be sure to associate the route table generated by AKS to the Application Gateway subnet. 
 
       - question: What features aren't supported on the AGIC add-on? 
         answer: |
-          Please see the differences between AGIC deployed through Helm versus deployed as an AKS add-on [here](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on)
+          See the differences between AGIC deployed through Helm versus deployed as an AKS add-on [here](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on)
           
       - question: When should I use the add-on versus the Helm deployment? 
         answer: |
-          Please see the differences between AGIC deployed through Helm versus deployed as an AKS add-on [here](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on), especially the tables documenting which scenario(s) are supported by AGIC deployed through Helm as opposed to an AKS add-on. In general, deploying through Helm will allow you to test out beta features and release candidates before an official release. 
+          Please see the differences between AGIC deployed through Helm versus deployed as an AKS add-on [here](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on), especially the tables documenting which scenario(s) are supported by AGIC deployed through Helm as opposed to an AKS add-on. In general, deploying through Helm allows you to test out beta features and release candidates before an official release. 
           
       - question: Can I control which version of AGIC will be deployed with the add-on?
-        answer: No, AGIC add-on is a managed service which means Microsoft will automatically update the add-on to the latest stable version.
+        answer: No, AGIC add-on is a managed service, which means Microsoft will automatically update the add-on to the latest stable version.
 
   - name: Configuration - mutual authentication
     questions:
@@ -533,7 +533,7 @@ sections:
           Usually, you see an unknown status when access to the backend is blocked by a network security group (NSG), custom DNS, or user-defined routing (UDR) on the application gateway subnet. For more information, see [Backend health, diagnostics logging, and metrics for Application Gateway](application-gateway-diagnostics.md).
           
       - question: Are NSG flow logs supported on NSGs associated to Application Gateway v2 subnet?
-        answer: Due to current platform limitations, if you have an NSG on the Application Gateway v2 (Standard_v2, WAF_v2) subnet and if you have enabled NSG flow logs on it, you will see nondeterministic behavior and this scenario is currently not supported.
+        answer: Due to current platform limitations, if you have an NSG on the Application Gateway v2 (Standard_v2, WAF_v2) subnet and if you have enabled NSG flow logs on it, you see nondeterministic behavior and this scenario is currently not supported.
 
       - question: Where does Application Gateway store customer data?
         answer: Application Gateway doesn't move or store customer data out of the region it's deployed in.
