resolve comments

Author: yungezz

articles/service-connector/known-limitations.md

@@ -13,11 +13,11 @@ author: mcleanbyron
 
 In this article, learn about Service Connector's existing limitations and how to mitigate them.
 
-## Limitations to IaC
+## Limitations to Infrastructure as Code (IaC)
 
 Service Connector has been designed to bring the benefits of easy, secure, and consistent backing service connections to as many Azure services as possible. To do so, Service Connector has been developed as an extension resource provider.
 
-Unfortunately, there's some limitations in IaC(Infra as Code) where an Azure Resource Manager (ARM), Bicep or Terraform template defines these resources explicitly. When creating service connection, Service Connector modifies resources on a user’s behalf, such as adding Azure App Service's AppSettings, adding Azure SQL database's firewall rules. When reapplying ARM templates or other IaC codes, which are used to provision source compute or target backing services at first place, these configurations on these resources added by Service Connector is cleared up. If an application is already running on these resources, then the application is down between reapplying the resource provisioning IaC codes and connection setup. For example, by default, Azure Container App has managed identity (MI) disabled. User provisions an Azure Container App through an ARM template with MI disabled. Whereas Service Connector enables it if the user chooses MI as an authentication method when creating a connection. Later, user reruns the ARM template, the MI is disabled again.
+Unfortunately, there are some limitations with IaC support as Service Connector modifies infrastructure on users' behalf. In this scenario, users would begin by using Azure Resource Manager (ARM), Bicep, Terraform, or other IaC templates to create resources. Afterwards, they would use Service Connector to setup resource connections. During this step, Service Connector modifies resource configurations on behalf of the user. If the user reruns their IaC template at a later time, modifications made by Service Connector would disappear as they were not reflected in the original IaC templates. An example of this behavior is Azure Container Apps deployed with ARM templates usually have Managed Identity (MI) disabled by default, Service Connector enables MI when setting up connections on users' behalf. If users trigger the same ARM templates without updating MI settings, the redeployed container apps will have MI disabled again.
 
 If you run into any issues when using Service Connector, [file an issue with us](https://github.com/Azure/ServiceConnector/issues/new). 
 
@@ -28,7 +28,7 @@ We suggest the following solutions:
 
 - If CI/CD pipelines contain ARM templates of source compute or backing services, suggested flow is: reapplying the ARM templates, adding sanity check or smoke tests to make sure the application is up and running, then allowing live traffic to the application. The flow adds verification step before allowing live traffic.
 
-- When automating an Azure Container App application using Service Connector, we recommend the use of the [multiple revision mode](../container-apps/revisions.md#revision-modes), to avoid sending traffic to a temporarily nonfunctional app, before Service Connector setup connections for the new app revision. 
+- When automating Azure Container App code deployments with Service Connector, we recommend the use of [multiple revision mode](../container-apps/revisions.md#revision-modes) to avoid routing traffic to a temporarily nonfunctional app before Service connector can reapply connections.
 
 - The order in which automation operations are performed matters greatly. Ensure your connection endpoints are there before the connection itself is created. Ideally, create the backing service, then the compute service, and then the connection between the two. So Service Connector can configure both the compute service and the backing service appropriately.