Merge pull request #224104 from enkrumah/patch-46

Update stream-analytics-define-outputs.md

Author: v-dirichards

articles/stream-analytics/stream-analytics-define-outputs.md

@@ -6,7 +6,7 @@ ms.author: ebnkruma
 ms.service: stream-analytics
 ms.topic: conceptual
 ms.custom: contperf-fy21q1
-ms.date: 07/13/2022
+ms.date: 01/18/2023
 ---
 
 # Outputs from Azure Stream Analytics
@@ -31,9 +31,9 @@ Some outputs types support [partitioning](#partitioning), and [output batch size
 |[Azure Event Hubs](event-hubs-output.md)|Yes, need to set the partition key column in output configuration.|Access key, </br> Managed Identity|
 |[Power BI](power-bi-output.md)|No|Azure Active Directory user, </br> Managed Identity|
 |[Azure Table storage](table-storage-output.md)|Yes|Account key|
-|[Azure Service Bus queues](service-bus-queues-output.md)|Yes|Access key|
-|[Azure Service Bus topics](service-bus-topics-output.md)|Yes|Access key|
-|[Azure Cosmos DB](azure-cosmos-db-output.md)|Yes|Access key|
+|[Azure Service Bus queues](service-bus-queues-output.md)|Yes|Access key, </br> Managed Identity|
+|[Azure Service Bus topics](service-bus-topics-output.md)|Yes|Access key, </br> Managed Identity|
+|[Azure Cosmos DB](azure-cosmos-db-output.md)|Yes|Access key, </br> Managed Identity|
 |[Azure Functions](azure-functions-output.md)|Yes|Access key|
 
 > [!IMPORTANT] 
@@ -56,7 +56,7 @@ By design, the Avro and Parquet formats do not support variable schemas in a sin
 
 The following behaviors may occur when directing a stream with variable schemas to an output using these formats:
 
-- If the schema change can be detected, the current output file will be closed, and a new one initialized on the new schema. Splitting files as such will severely slow down the output when schema changes happen frequently. With back pressure this will in turn severly impact the overall performance of the job
+- If the schema change can be detected, the current output file will be closed, and a new one initialized on the new schema. Splitting files as such will severely slow down the output when schema changes happen frequently. With back pressure this will in turn severely impact the overall performance of the job
 - If the schema change cannot be detected, the row will most likely be rejected, and the job become stuck as the row can't be output. Nested columns, or multi-type arrays, are situations that won't be discovered and be rejected.
 
 It is highly recommended to consider outputs using the Avro or Parquet format to be strongly typed, or schema-on-write, and queries targeting them to be written as such (explicit conversions and projections for a uniform schema).