Update container-group-deployment-waiting-state.md

Author: ryanberg-aquent

support/azure/azure-container-instances/configuration-setup/container-group-deployment-waiting-state.md

@@ -35,7 +35,7 @@ Possible solutions include:
 - Check that the container runs fine locally. A local machine with Docker can be used to do this.
 - Inspect possible errors on the **Container Events** tab starting with the main container process.
 - Make sure no reserved ports are being used in the container definition. For more information, see [Does the ACI service reserve ports for service functionality?](/azure/container-instances/container-instances-faq#does-the-aci-service-reserve-ports-for-service-functionality-).
-- Check that theress connectivity to the Azure file share and that the key is correct or valid. If deployment is on BYOVNET, check that DNS resolution is working for the Azure file share fully qualified domain name (FQDN).
+- Check that there's connectivity to the Azure file share and that the key is correct or valid. If deployment is on BYOVNET, check that DNS resolution is working for the Azure file share fully qualified domain name (FQDN).
 - Check Azure file share volume [limitations](/azure/container-instances/container-instances-volume-azure-files#limitations) for Azure Container Instances (ACI). Using a private endpoint to connect to an Azure file share hasn't been tested and might not be reliable. Instead, use a subnet service endpoint for private connectivity as recommended in documentation.
 - Change the subnet network mask. ACI keeps its own IP mapping internally and at ARM level all IPs always show as available. Depending on the frequency of deployments or restarts, subnet IP exhaustion errors can happen because internal mapping isn't updated in time. To avoid this issue, we recommend using a subnet network mask of `/24` or greater.
 - Attempt the deployment with less resource requests or in another region to confirm possible capacity issues.