Merge pull request #290436 from spelluru/freshness1112

Freshness review - 11-12

Author: v-regandowner

articles/event-grid/security-authentication.md

@@ -1,8 +1,9 @@
 ---
-title: Authenticate event delivery to event handlers (Azure Event Grid)
+title: Authenticate event delivery to event handlers
 description: This article describes different ways of authenticating delivery to event handlers in Azure Event Grid. 
-ms.topic: conceptual
-ms.date: 08/31/2023
+ms.topic: concept-article
+ms.date: 11/12/2024
+# Customer intent: I want to learn how to authenticate delivery of events to event handlers. 
 ---
 
 # Authenticate event delivery to event handlers (Azure Event Grid)
@@ -14,7 +15,7 @@ Azure Event Grid uses different authentication methods to deliver events to even
 | Authentication method | Supported event handlers | Description  |
 |--|--|--|
 Access key | - Event Hubs<br/>- Service Bus<br/>- Storage Queues<br/>- Relay Hybrid Connections<br/>- Azure Functions<br/>- Storage Blobs (Deadletter) | Access keys are fetched using Event Grid service principal's credentials. The permissions are granted to Event Grid when you register the Event Grid resource provider in their Azure subscription. |  
-Managed System Identity <br/>&<br/> Role-based access control | - Event Hubs<br/>- Service Bus<br/>- Storage Queues<br/>- Storage  Blobs (Deadletter) | Enable managed system identity for the topic and add it to the appropriate role on the destination. For details, see [Use system-assigned identities for event delivery](#use-system-assigned-identities-for-event-delivery).  |
+Managed System Identity <br/>&<br/> Role-based access control | - Event Hubs<br/>- Service Bus<br/>- Storage Queues<br/>- Storage  Blobs (Deadletter) | Enable managed system identity for the topic and add it to the appropriate role on the destination. For details, see [Use system-assigned identities for event delivery](#use-system-assigned-identities-for-event-delivery). |
 |Bearer token authentication with Microsoft Entra protected webhook | Webhook | See the [Authenticate event delivery to webhook endpoints](#authenticate-event-delivery-to-webhook-endpoints) section for details. |
 Client secret as a query parameter | Webhook | See the [Using client secret as a query parameter](#using-client-secret-as-a-query-parameter) section for details. |
 
@@ -26,7 +27,7 @@ You can enable a system-assigned managed identity for a topic or domain and use
 
 Here are the steps: 
 
-1. Create a topic or domain with a system-assigned identity, or update an existing topic or domain to enable identity. For more information, see [Enable managed identity for a system topic](enable-identity-system-topics.md) or [Enable managed identity for a custom topic or a domain](enable-identity-custom-topics-domains.md)
+1. Create a topic or domain with a system-assigned identity, or enable identity on an existing topic or domain. For more information, see [Enable managed identity for a system topic](enable-identity-system-topics.md) or [Enable managed identity for a custom topic or a domain](enable-identity-custom-topics-domains.md)
 1. Add the identity to an appropriate role (for example, Service Bus Data Sender) on the destination (for example, a Service Bus queue). For more information, see [Grant identity the access to Event Grid destination](add-identity-roles.md)
 1. When you create event subscriptions, enable the usage of the identity to deliver events to the destination. For more information, see [Create an event subscription that uses the identity](managed-service-identity.md). 
 
@@ -54,5 +55,5 @@ For more information on delivering events to webhooks, see [Webhook event delive
 If you're already familiar with Event Grid, you might be aware of the endpoint validation handshake for preventing abuse. CloudEvents v1.0 implements its own [abuse protection semantics](end-point-validation-cloud-events-schema.md) by using the **HTTP OPTIONS** method. To read more about it, see [HTTP 1.1 Web Hooks for event delivery - Version 1.0](https://github.com/cloudevents/spec/blob/v1.0/http-webhook.md#4-abuse-protection). When you use the CloudEvents schema for output, Event Grid uses the CloudEvents v1.0 abuse protection in place of the Event Grid validation event mechanism. For more information, see [Use CloudEvents v1.0 schema with Event Grid](cloud-event-schema.md). 
 
 
-## Next steps
+## Related content
 See [Authenticate publishing clients](security-authenticate-publishing-clients.md) to learn about authenticating clients publishing events to topics or domains. 

articles/event-hubs/event-hubs-auto-inflate.md

@@ -1,61 +1,61 @@
 ---
 title: Automatically scale up throughput units in Azure Event Hubs
-description: Enable Auto-inflate on a namespace to automatically scale up throughput units (standard tier).
+description: Enable Auto inflate on a namespace to automatically scale up throughput units (standard tier).
 ms.topic: article
 ms.custom: devx-track-arm-template
-ms.date: 07/28/2023
+ms.date: 11/12/2024
 ---
 
 # Automatically scale up Azure Event Hubs throughput units (standard tier) 
 
-When you create a standard tier Event Hubs namespace, you specify the number of [throughput units (TUs)](event-hubs-scalability.md#throughput-units). These TUs may not be enough when the usage goes up later. When that happens, you could manually increase the number of TUs assigned to the namespace. However, it's better to have Event Hubs automatically increase (inflate) TUs based on the workload. 
+When you create a standard tier Event Hubs namespace, you specify the number of [throughput units (TUs)](event-hubs-scalability.md#throughput-units). These TUs might not be enough when the usage goes up later. When that happens, you could manually increase the number of TUs assigned to the namespace. However, it's better to have Event Hubs automatically increase (inflate) TUs based on the workload. 
 
-The **Auto-inflate** feature of Event Hubs automatically scales up by increasing the number of TUs, to meet usage needs. Increasing TUs prevents throttling scenarios where data ingress or data egress rates exceed the rates allowed by the TUs assigned to the namespace. The Event Hubs service increases the throughput when load increases beyond the minimum threshold, without any requests failing with ServerBusy errors.
+The **Auto inflate** feature of Event Hubs automatically scales up by increasing the number of TUs, to meet usage needs. Increasing TUs prevents throttling scenarios where data ingress or data egress rates exceed the rates allowed by the TUs assigned to the namespace. The Event Hubs service increases the throughput when load increases beyond the minimum threshold, without any requests failing with ServerBusy errors.
 
 > [!NOTE]
-> The auto-inflate feature is currently supported only in the standard tier. 
+> The auto inflate feature is currently supported only in the standard tier. 
 
-## How Auto-inflate works in standard tier
+## How Auto inflate works in standard tier
 
-Event Hubs traffic is controlled by TUs (standard tier). For the limits such as ingress and egress rates per TU, see [Event Hubs quotas and limits](event-hubs-quotas.md). Auto-inflate enables you to start small with the minimum required TUs you choose. The feature then scales automatically to the maximum limit of TUs you need, depending on the increase in your traffic. Auto-inflate provides the following benefits:
+Event Hubs traffic is controlled by TUs (standard tier). For the limits such as ingress and egress rates per TU, see [Event Hubs quotas and limits](event-hubs-quotas.md). Auto inflate enables you to start small with the minimum required TUs you choose. The feature then scales automatically to the maximum limit of TUs you need, depending on the increase in your traffic. Auto inflate provides the following benefits:
 
 - An efficient scaling mechanism to start small and scale up as you grow.
 - Automatically scale to the specified upper limit without throttling issues.
 - More control over scaling, because you control when and how much to scale.
 
 > [!NOTE]
-> Auto-inflate doesn't **automatically scale down** the number of TUs when ingress or egress rates drop below the limits. 
+> Auto inflate doesn't **automatically scale down** the number of TUs when ingress or egress rates drop below the limits. 
 
- ## Enable Auto-inflate on a namespace
+ ## Enable Auto inflate on a namespace
 
-You can enable or disable Auto-inflate on a standard tier Event Hubs namespace by using either [Azure portal](https://portal.azure.com) or an [Azure Resource Manager template](https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.eventhub/eventhubs-create-namespace-and-enable-inflate).
+You can enable or disable auto inflate on a standard tier Event Hubs namespace by using either [Azure portal](https://portal.azure.com) or an [Azure Resource Manager template](https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.eventhub/eventhubs-create-namespace-and-enable-inflate).
 
 ## Use Azure portal
 
 In the Azure portal, you can enable the feature when creating a standard Event Hubs namespace or after the namespace is created. You can also set TUs for the namespace and specify maximum limit of TUs 
 
-You can enable the Auto-inflate feature **when creating an Event Hubs namespace**. The following image shows you how to enable the auto-inflate feature for a standard tier namespace and configure TUs to start with and the maximum number of TUs. 
+You can enable the Auto inflate feature **when creating an Event Hubs namespace**. The following image shows you how to enable the auto inflate feature for a standard tier namespace and configure TUs to start with and the maximum number of TUs. 
 
 :::image type="content" source="./media/event-hubs-auto-inflate/event-hubs-auto-inflate.png" alt-text="Screenshot of enabling auto inflate at the time event hub creation for a standard tier namespace.":::
 
 With this option enabled, you can start small with your TUs and scale up as your usage needs increase. The upper limit for inflation doesn't immediately affect pricing, which depends on the number of TUs used per hour.
 
-To enable the Auto-inflate feature and modify its settings for an existing namespace, follow these steps:
+To enable the Auto inflate feature and modify its settings for an existing namespace, follow these steps:
 
-1. On the **Event Hubs Namespace** page, select **Scale** under **Settings** on the left menu.
+1. On the **Event Hubs namespace** page, select **Scale** under **Settings** on the left menu.
 2. In the **Scale Settings** page, select the checkbox for **Enable** (if the autoscale feature wasn't enabled).
 
-    :::image type="content" source="./media/event-hubs-auto-inflate/scale-settings.png" alt-text="Screenshot of enabling auto-inflate for an existing standard namespace":::
+    :::image type="content" source="./media/event-hubs-auto-inflate/scale-settings.png" alt-text="Screenshot of enabling auto inflate for an existing standard namespace":::
 3. Enter the **maximum** number of throughput units or use the scrollbar to set the value.
 4. (optional) Update the **minimum** number of throughput units at the top of this page.
 
 > [!NOTE]
-> When you apply the auto-inflate configuration to increase throughput units, the Event Hubs service emits diagnostic logs that give you information about why and when the throughput increased. To enable diagnostic logging for an event hub, select **Diagnostic settings** on the left menu on the Event Hub page in the Azure portal. For more information, see [Set up diagnostic logs for an Azure event hub](monitor-event-hubs-reference.md#resource-logs).
+> When you apply the auto inflate configuration to increase throughput units, the Event Hubs service emits diagnostic logs that give you information about why and when the throughput increased. To enable diagnostic logging for an event hub, select **Diagnostic settings** on the left menu on the Event Hub page in the Azure portal. For more information, see [Set up diagnostic logs for an Azure event hub](monitor-event-hubs-reference.md#resource-logs).
 
 
 ## Use an Azure Resource Manager template
 
-You can enable the Auto-inflate feature during an Azure Resource Manager template deployment. For example, set the
+You can enable the Auto inflate feature during an Azure Resource Manager template deployment. For example, set the
 `isAutoInflateEnabled` property to **true** and set `maximumThroughputUnits` to 10. For example:
 
 ```json

articles/service-bus-messaging/service-bus-auto-forwarding.md

@@ -1,9 +1,10 @@
 ---
 title: Autoforwarding Azure Service Bus messaging entities
 description: This article describes how to chain an Azure Service Bus queue or subscription to another queue or topic.
-ms.topic: article
-ms.date: 07/27/2022
+ms.topic: concept-article
+ms.date: 11/12/2024
 ms.custom: devx-track-csharp
+# Customer intent: I want to learn how to automatically forward messages received by one entity to another entity in Azure Service Bus. 
 ---
 
 # Chaining Service Bus entities with autoforwarding
@@ -23,7 +24,7 @@ You can use autoforwarding to scale out an individual topic. Service Bus limits
 ![Diagram of an autoforwarding scenario showing a message processed through an Orders Topic that can branch to any of three second-level Orders Topics.][0]
 
 ### Decouple message senders from receivers
-You can also use autoforwarding to decouple message senders from receivers. For example, consider an Enterprise Resource Planning (ERP) system that consists of three modules: order processing, inventory management, and customer relations management. Each of these modules generates messages that are enqueued into a corresponding topic. Alice and Bob are sales representatives that are interested in all messages that relate to their customers. To receive those messages, Alice and Bob each create a personal queue and a subscription on each of the ERP topics that automatically forward all messages to their queue.
+You can also use autoforwarding to decouple message senders from receivers. For example, consider an Enterprise Resource Planning (ERP) system that consists of three modules: order processing, inventory management, and customer relations management. Each of these modules generates messages that are enqueued into a corresponding topic. John Doe and Jane are sales representatives who are interested in all messages that relate to their customers. To receive those messages, John Doe and Jane Doe each create a personal queue and a subscription on each of the ERP topics that automatically forward all messages to their queue.
 
 ![Diagram of an autoforwarding scenario showing three processing modules sending messages through three corresponding topics to two separate queues.][1]
 
@@ -47,7 +48,7 @@ If Alice goes on vacation, her personal queue, rather than the ERP topic, fills
 - Source queue tries to forward messages to the destination entity in the same order it received, but the destination could be a topic that doesn't support ordering. If either the source or destination entity is a partitioned entity, order isn't guaranteed.
 
 
-## Next steps
+## Related content
 To learn how to enable or disable auto forwarding in different ways (Azure portal, PowerShell, CLI, Azure Resource Management template, etc.), see [Enable auto forwarding for queues and subscriptions](enable-auto-forward.md).