Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into mrb_03_29_2023_prompt_engineering

Author: mrbullwinkle

articles/aks/enable-host-encryption.md

@@ -47,7 +47,7 @@ If you want to create clusters without host-based encryption, you can do so by o
 You can enable host-based encryption on existing clusters by adding a new node pool to your cluster. Configure a new node pool to use host-based encryption by using the `--enable-encryption-at-host` parameter.
 
 ```azurecli
-az aks nodepool add --name hostencrypt --cluster-name myAKSCluster --resource-group myResourceGroup -s Standard_DS2_v2 -l westus2 --enable-encryption-at-host
+az aks nodepool add --name hostencrypt --cluster-name myAKSCluster --resource-group myResourceGroup -s Standard_DS2_v2 --enable-encryption-at-host
 ```
 
 If you want to create new node pools without the host-based encryption feature, you can do so by omitting the `--enable-encryption-at-host` parameter.

articles/aks/use-pod-sandboxing.md

@@ -234,7 +234,7 @@ To demonstrate the deployment of an untrusted application into the pod sandbox o
 
     ```output
     root@untrusted:/# uname -r
-    5.15.80.mshv2-hvl1.m2
+    5.15.48.1-8.cm2
     ```
 
 3. Start a shell session to the container of the *trusted* pod to verify the kernel output:
@@ -252,7 +252,8 @@ To demonstrate the deployment of an untrusted application into the pod sandbox o
    The following example resembles output from the VM that is running the *trusted* pod, which is a different kernel than the *untrusted* pod running within the pod sandbox:
 
     ```output
-    5.15.48.1-8.cm2
+    5.15.80.mshv2-hvl1.m2
+    ```
 
 ## Cleanup
 

articles/api-management/how-to-event-grid.md

@@ -86,5 +86,4 @@ API Management event data includes the `resourceUri`, which identifies the API M
 
 ## Next steps
 
-* [Choose between Azure messaging services - Event Grid, Event Hubs, and Service Bus](../event-grid/compare-messaging-services.md)
 * Learn more about [subscribing to events](../event-grid/subscribe-through-portal.md).

articles/app-service/includes/quickstart-java/quickstart-java-linux-maven-pivot.md

@@ -41,6 +41,9 @@ If Maven isn't your preferred development tool, check out our similar tutorials
 
 Clone the [sample project](https://github.com/Azure-Samples/app-service-java-quickstart) and check out the source code that runs with this version of the article.
 
+> [!TIP]
+> Though App Service supports older versions of Java, the sample project uses Java records and requires **Java 17**. For more information about Java records, see [JEP 395](https://openjdk.org/jeps/395).
+
 ```azurecli-interactive
 git clone https://github.com/Azure-Samples/app-service-java-quickstart
 ```
@@ -94,7 +97,6 @@ cd petstore-ee7
 > [!TIP]
 > The Maven plugin supports **Java 17** and **Tomcat 10.0**. For more information about latest support, see [Java 17 and Tomcat 10.0 are available on Azure App Service](https://devblogs.microsoft.com/java/java-17-and-tomcat-10-0-available-on-azure-app-service/).
 
-
 The deployment process to Azure App Service uses your Azure credentials from the Azure CLI automatically. If the Azure CLI isn't installed locally, then the Maven plugin authenticates with Oauth or device login. For more information, see [authentication with Maven plugins](https://github.com/microsoft/azure-maven-plugins/wiki/Authentication).
 
 Run the Maven command shown next to configure the deployment. This command helps you to set up the App Service operating system, Java version, and Tomcat version.

articles/app-service/overview-disaster-recovery.md

@@ -19,7 +19,7 @@ For IT, business continuity plans are largely driven by two metrics:
 - Recovery Time Objective (RTO) – the time duration in which your application must come back online after an outage. 
 - Recovery Point Objective (RPO) – the acceptable amount of data loss in a disaster, expressed as a unit of time (for example, 1 minute of transactional database records). 
 
-Normally, maintaining an SLA around RTO is impractical for regional disasters, and you would typically design your disaster recovery strategy around RPO alone (i.e. focus on recovering data and not on minimizing interruption). With Azure, however, it's not only practical but could even be straightforward to deploy App Service for automatic geo-failovers. This lets you disaster-proof your applications further by take care of both RTO and RPO.
+Normally, maintaining an SLA around RTO is impractical for regional disasters, and you would typically design your disaster recovery strategy around RPO alone (i.e. focus on recovering data and not on minimizing interruption). With Azure, however, it's not only practical but could even be straightforward to deploy App Service for automatic geo-failovers. This lets you disaster-proof your applications further by taking care of both RTO and RPO.
 
 Depending on your desired RTO and RPO metrics, three disaster recovery architectures are commonly used, as shown in the following table:
 
@@ -155,4 +155,4 @@ Steps to create a passive-cold region without GRS and GZRS are summarized as fol
 
 ## Next steps
 
-[Tutorial: Create a highly available multi-region app in Azure App Service](tutorial-multi-region-app.md)
+[Tutorial: Create a highly available multi-region app in Azure App Service](tutorial-multi-region-app.md)

articles/azure-functions/monitor-functions.md

@@ -100,10 +100,10 @@ The following table lists common and recommended alert rules for Functions.
 | Metric | Average connections| When number of connections exceed a set value|
 | Metric | HTTP 404| When HTTP 404 responses exceed a set value|
 | Metric | HTTP Server Errors| When HTTP 5xx errors exceed a set value|
-| Activity Log | Create or Update Web App | When app is created or updated|
-| Activity Log | Delete Web App | When app is deleted|
-| Activity Log | Restart Web App| When app is restarted|
-| Activity Log | Stop Web App| When app is stopped|
+| Activity Log | Create or update function app | When app is created or updated|
+| Activity Log | Delete function app | When app is deleted|
+| Activity Log | Restart function app| When app is restarted|
+| Activity Log | Stop function app| When app is stopped|
 
 ## Next steps
 

articles/azure-netapp-files/whats-new.md

@@ -152,7 +152,6 @@ Azure NetApp Files is updated regularly. This article provides a summary about t
     * Azure Managed Disk as an alternate storage back end
 
 * [Active Directory connection enhancement: Reset Active Directory computer account password](create-active-directory-connections.md#reset-active-directory) (Preview)
->>>>>>> 15252d24ac8fc6f9c2853c1a0deeb10d3393f104
 
 ## June 2022
 

articles/container-apps/user-defined-routes.md

@@ -16,32 +16,33 @@ ms.date: 03/29/2023
 
 This article shows you how to use user defined routes (UDR) with [Azure Firewall](../firewall/overview.md) to lock down outbound traffic from your Container Apps to back-end Azure resources or other network resources.
 
-Azure creates a default route table for your virtual networks on create. By implementing a user-defined route table, you can control how traffic is routed within your virtual network. In this guide, you'll setup UDR on the Container Apps virtual network to restrict outbound traffic with Azure Firewall.
+Azure creates a default route table for your virtual networks on create. By implementing a user-defined route table, you can control how traffic is routed within your virtual network. In this guide, your setup UDR on the Container Apps virtual network to restrict outbound traffic with Azure Firewall.
 
-You can also use a NAT gateway or any other 3rd party appliances instead of Azure Firewall.
+You can also use a NAT gateway or any other third party appliances instead of Azure Firewall.
 
 For more information on networking concepts in Container Apps, see [Networking Architecture in Azure Container Apps](./networking.md).
 
 ## Prerequisites
 
-* An **internal** container app environment on the workload profiles architecture that's integrated with a custom virtual network. When you create an internal container app environment, your container app environment has no public IP addresses, and all traffic is routed through the virtual network. For more information, see the [guide for how to create a container app environment on the workload profiles architecture](./workload-profiles-manage-cli.md). Ensure that you're creating an **internal** environment.
+* **Internal environment**: An internal container app environment on the workload profiles architecture that's integrated with a custom virtual network. When you create an internal container app environment, your container app environment has no public IP addresses, and all traffic is routed through the virtual network. For more information, see the [guide for how to create a container app environment on the workload profiles architecture](./workload-profiles-manage-cli.md).
 
-* In your container app, have a container that supports `curl` commands. You can use `curl` to verify the container app is deployed correctly. The *helloworld* container from the sample container image already supports `curl` commands.
+* **`curl` support**: Your container app must have a container that supports `curl` commands. You use `curl` to verify the container app is deployed correctly. The *helloworld* container from the sample container image already supports `curl` commands.
 
 ## Create the firewall subnet
 
 A subnet called **AzureFirewallSubnet** is required in order to deploy a firewall into the integrated virtual network.
 
-1. In the [Azure portal](https://portal.azure.com), navigate to the virtual network that's integrated with your app.
+1. Open the virtual network that's integrated with your app in the [Azure portal](https://portal.azure.com).
 
 1. From the menu on the left, select **Subnets**, then select **+ Subnet**.
 
 1. Enter the following values:
 
     | Setting      | Action      |
     | ------------ | ---------------- |
-    | **Name** | Enter **AzureFirewallSubnet**. | 
+    | **Name** | Enter **AzureFirewallSubnet**. |
     | **Subnet address range** | Use the default or specify a [subnet range /26 or larger](../firewall/firewall-faq.yml#why-does-azure-firewall-need-a--26-subnet-size).
+
 1. Select **Save**
 
 ## Deploy the firewall
@@ -73,7 +74,7 @@ A subnet called **AzureFirewallSubnet** is required in order to deploy a firewal
 
 ## Route all traffic to the firewall
 
-Your virtual networks in Azure have default route tables in place upon create. By implementing a user-defined route table, you can control how traffic is routed within your virtual network. In the following steps, you create a UDR to route all traffic to your Azure Firewall.
+Your virtual networks in Azure have default route tables in place when you create the network. By implementing a user-defined route table, you can control how traffic is routed within your virtual network. In the following steps, you create a UDR to route all traffic to your Azure Firewall.
 
 1. On the Azure portal menu or the *Home* page, select **Create a resource**.
 
@@ -107,14 +108,14 @@ Your virtual networks in Azure have default route tables in place upon create. B
 
 1. Select **Add** to create the route.
 
-1. From the menu on the left, select **Subnets**, then select **Associate** to associate your route table with the subnet your Container App is integrated with.
+1. From the menu on the left, select **Subnets**, then select **Associate** to associate your route table with the container app's subnet.
 
 1. Configure the *Associate subnet* with the following values:
 
     | Setting      | Action      |
     |--|--|
-    | **Address prefix** | Select the virtual network your container app is integrated with |
-    | **Next hop type** | Select the subnet your container app is integrated with  |
+    | **Address prefix** | Select the virtual network for your container app. |
+    | **Next hop type** | Select the subnet your for container app.  |
 
 1. Select **OK**.
 
@@ -151,7 +152,7 @@ Now, all outbound traffic from your container app is routed to the firewall. Cur
     | **Action** | Select *Allow* |
 
     >[!Note]
-    > If you are using [Docker Hub registry](https://docs.docker.com/desktop/allow-list/) and want to access it through your firewall, you will need to add the following FQDNs to your rules destination list above: *hub.docker.com*, *registry-1.docker.io*, and *production.cloudflare.docker.com*.
+    > If you are using [Docker Hub registry](https://docs.docker.com/desktop/allow-list/) and want to access it through your firewall, you will need to add the following FQDNs to your rules destination list: *hub.docker.com*, *registry-1.docker.io*, and *production.cloudflare.docker.com*.
 
 1. Select **Add**.
 
@@ -161,13 +162,13 @@ To verify your firewall configuration is set up correctly, you can use the `curl
 
 1. Navigate to your Container App that is configured with Azure Firewall.
 
-1. From the menu on the left, select **Console**, then select your container that supports the `curl` command. If you're using the helloworld container from the sample container image quickstart, you can run the `curl` command.
+1. From the menu on the left, select **Console**, then select your container that supports the `curl` command. If you're using the *helloworld* container from the sample container image quickstart, you can run the `curl` command.
 
 1. In the **Choose start up command** menu, select **/bin/sh**, and select **Connect**.
 
 1. In the console, run `curl -s https://mcr.microsoft.com`. You should see a successful response as you added `mcr.microsoft.com` to the allowlist for your firewall policies.
 
-1. Run `curl -s https://<fqdn-address>` for a URL that doesn't match any of your destination rules such as `example.com`. The example command would be `curl -s https://example.com`. You should get no response, which indicates that your firewall has blocked the request.
+1. Run `curl -s https://<FQDN_ADDRESS>` for a URL that doesn't match any of your destination rules such as `example.com`. The example command would be `curl -s https://example.com`. You should get no response, which indicates that your firewall has blocked the request.
 
 ## Next steps