add diagram to ingres-overview

Author: cebundy

articles/container-apps/client-certificate-authorization.md

@@ -12,19 +12,18 @@ ms.author: cshoe
 # Configure client certificate authentication in Azure Container Apps
 
 Azure Container Apps supports client certificate authentication (also known as mutual TLS or mTLS) that allows access to your container app through two-way authentication. This article shows you how to configure client certificate authorization in Azure Container Apps.
- 
+
 When client certificates are used, the TLS certificates are exchanged between the client and your container app to authenticate identity and encrypt traffic.  Client certificates are often used in "zero trust" security models to authorize client access within an organization.
 
 For example, you may want to require a client certificate for a container app that manages sensitive data.
 
 Container Apps accepts client certificates in the PKCS12 format are that issued by a trusted certificate authority (CA), or are self-signed.  
 
->[!NOTE]
-> Client certificate authorization is only supported in Container Apps environments that use a [custom VNET](vnet-custom.md).
-
 ## Configure client certificate authorization
 
-The client certificate mode property available as you enable [ingress](./ingress-how-to.md) on your container app.  The property can be set to one of the following values:
+Set the `clientCertificateMode` property in your container app template to configure support of client certificates.
+
+The property can be set to one of the following values:
 
 - `require`: The client certificate is required for all requests to the container app.
 - `accept`: The client certificate is optional. If the client certificate isn't provided, the request is still accepted.

articles/container-apps/ingress-how-to.md

@@ -161,6 +161,8 @@ Disable ingress for your container app by omitting the `ingress` configuration p
 
 ---
 
+::: zone-end
+
 ## Next steps
 
 > [!div class="nextstepaction"]

articles/container-apps/ingress-overview.md

@@ -23,10 +23,10 @@ Ingress supports:
 - [Traffic splitting between revisions](#traffic-splitting)
 - [Session affinity](#session-affinity)
 
-<!--
-> [!NOTE]
-> Add diagram here,  Talked with Anthony about this.  He thought that we should consult Ahmed.  I think that we should have a diagram that shows the ingress options and how they work together.
--->
+Example ingress configuration showing ingress split between two revisions:
+
+:::image type="content" source="media/ingress/ingress-diagram.png" alt-text="Diagram showing an ingress configuration splitting traffic between two revisions.":::
+
 For configuration details, see [Configure ingress](ingress-how-to.md).
 
 ## External and internal ingress
@@ -85,6 +85,8 @@ You can access your app in the following ways:
 - A custom domain name:  You can configure a custom DNS domain for your Container Apps environment.  For more information, see [Custom domain names and certificates](./custom-domains-certificates.md).
 - The app name: You can use the app name for communication between apps in the same environment.
 
+To get the FQDN for your app, see [Location](connect-apps.md#location).
+
 ## IP restrictions
 
 Container Apps supports IP restrictions for ingress. You can create rules to either configure IP addresses that are allowed or denied access to your container app. For more information, see [Configure IP restrictions](ip-restrictions.md).

articles/container-apps/ip-restrictions.md

@@ -19,9 +19,9 @@ There are two types of restrictions:
 * *Allow*: Allow inbound traffic only from address ranges you specify in allow rules.
 * *Deny*: Deny all inbound traffic only from address ranges you specify in deny rules.
 
-If no IP restriction rules are defined, all inbound traffic is allowed.
+when no IP restriction rules are defined, all inbound traffic is allowed.
 
-IP restrictions are defined by one or more rules with the following properties:
+IP restrictions rules contain the following properties:
 
 | Property | Value | Description |
 |----------|-------|-------------|
@@ -30,7 +30,7 @@ IP restrictions are defined by one or more rules with the following properties:
 | ipAddressRange | IP address range in CIDR format | The IP address range in CIDR notation. |
 | action | Allow or Deny | The action to take for the rule. |
 
-The ipAddressRange parameter accepts IPv4 addresses. Define each IPv4 address block in [Classless Inter-Domain Routing (CIDR)](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation.  
+The `ipAddressRange` parameter accepts IPv4 addresses. Define each IPv4 address block in [Classless Inter-Domain Routing (CIDR)](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation.  
 
 > [!NOTE]
 > All rules must be the same type. You cannot combine allow rules and deny rules.
@@ -108,7 +108,7 @@ Add more rules by repeating the command with a different `--rule-name` and -`--i
 
 #### Create allow rules
 
-The following example `az containerapp access-restriction set` command creates a rule to restrict inbound access to a IP address range.  Note that you must delete any existing deny rules before you can add allow rules.
+The following example `az containerapp access-restriction set` command creates a rule to restrict inbound access to an IP address range.  You must delete any existing deny rules before you can add any allow rules.
 
 Replace the values in the following example with your own values.
 
@@ -126,7 +126,7 @@ You can add to the allow rules by repeating the command with a different `--ip-a
 
 #### Create deny rules
 
-The following example of the `az containerapp access-restriction set` command creates an access rule to deny inbound traffic from a specified IP range.  Note that you must delete any existing allow rules before you can add deny rules.
+The following example of the `az containerapp access-restriction set` command creates an access rule to deny inbound traffic from a specified IP range.  You must delete any existing allow rules before you can add deny rules.
 
 Replace the placeholders in the following example with your own values.
 
@@ -146,7 +146,7 @@ You can add to the deny rules by repeating the command with a different `--ip-ad
 
 You can update a rule using the `az containerapp ingress access-restriction set` command.  You can change the IP address range and the rule description, but not the rule name or action.
 
-The `--action` parameter is required, but you cannot change the action from Allow to Deny or vice versa.  
+The `--action` parameter is required, but you can't change the action from Allow to Deny or vice versa.  
 If you omit the `---description` parameter, the description is deleted.
 
 The following example updates the ip address range.

articles/container-apps/media/ingress/ingress-diagram.png

@@ -18,7 +18,7 @@ Session affinity, also known as sticky sessions, is a feature that allows you to
 
 Session stickiness is enforced using HTTP cookies. This feature is available in single revision mode when HTTP ingress is enabled. A client may be routed to a new replica if the previous replica is no longer available.
 
-If your app doesn't require session affinity, we recommend that you don't enable it. This allows the ingress to distribute requests more evenly across replicas, which improves the performance of your app.
+If your app doesn't require session affinity, we recommend that you don't enable it. With session affinity disabled, ingress distributes requests more evenly across replicas improving the performance of your app.
 
 Note session affinity is only supported when your app is in [single revision mode](revisions.md#single-revision-mode) and the ingress type is HTTP.
 

articles/container-apps/sticky-sessions.md

@@ -124,7 +124,7 @@ The following example shows traffic splitting between two revisions by name:
   },
 ```
 
-The following example shows traffic splitting between two revision by label:
+The following example shows traffic splitting between two revisions by label:
 
 ```json
 {