Address pre-existing Acrolinx suggestions

Author: WilliamAntonRohm

articles/service-fabric/container-image-management.md

@@ -10,7 +10,7 @@ ms.date: 06/22/2023
 ---
 
 # Container Image Management 
-The activation path during Service Fabric containers deployment, handles the downloading of the container images to the VM on which the containers are running. Once the containers have been removed from the cluster and their application types have been unregistered, there's a cleanup cycle that deletes the container images. This container image cleanup works only if the container image has been hard coded in the service manifest. For existing Service Fabric runtime versions, the configurations supporting the cleanup of the container images are as follows - 
+The activation path during Service Fabric containers deployment, handles the downloading of the container images to the VM on which the containers are running. Once the containers are removed from the cluster and their application types are unregistered, there's a cleanup cycle that deletes the container images. This container image cleanup works only if the container image was hard coded in the service manifest. For existing Service Fabric runtime versions, the configurations supporting the cleanup of the container images are as follows - 
 
 ## Settings
 
@@ -38,7 +38,7 @@ The activation path during Service Fabric containers deployment, handles the dow
    |CacheCleanupScanInterval |Setting in seconds determining how often the cleanup cycle runs.  |
 
 ## Container Image Management v2
-Starting Service Fabric version 10.0 there's a newer version of the container image deletion flow. This flow cleans up container images irrespective of how the container images may have been defined - either hard coded or parameterized during application deployment. PruneContainerImages and ContainerImageDeletionEnabled configuration are mutually exclusive and cluster upgrade validation exists to ensure one or the other is switched on but not both. The configuration supporting this feature are as follows - 
+Starting Service Fabric version 10.0 there's a newer version of the container image deletion flow. This flow cleans up container images irrespective of how the container images were defined - either hard coded or parameterized during application deployment. PruneContainerImages and ContainerImageDeletionEnabled configuration are mutually exclusive and cluster upgrade validation exists to ensure one or the other is switched on but not both. The configuration supporting this feature are as follows - 
 
 ### Settings
 
@@ -77,7 +77,7 @@ Starting Service Fabric version 10.0 there's a newer version of the container im
    |ContainerImageDeletionEnabled |Setting to enable or disable deletion of container images. |
    |ContainerImageCleanupInterval |Time interval for cleaning up unused container images.  |
    |ContainerImageTTL |Time to live for container images once they're eligible for removal (not referenced by containers on the VM and the application is deleted(if ContainerImageDeletionOnAppInstanceDeletionEnabled is enabled)).  |
-   |ContainerImageDeletionOnAppInstanceDeletionEnabled |Setting to enable or disable deletion of expired ttl container images only after application has been deleted as well.  |
+   |ContainerImageDeletionOnAppInstanceDeletionEnabled |Setting to enable or disable deletion of expired ttl container images only after application was deleted as well.  |
    |ContainerImagesToSkip |When set enables the container runtime to skip deleting images that match any of the set of regular expressions. The \| character separates each expression. Example: "mcr.microsoft.com/.+\|docker.io/library/alpine:latest" - this example matches everything prefixed with "mcr.microsoft.com/" and matches exactly "docker.io/library/alpine:latest". By default we don't delete the known Windows base images microsoft/windowsservercore or microsoft/nanoserver.  |
 
 ## Next steps