Clarity

Author: PatAltimore

articles/iot-operations/manage-mqtt-broker/howto-configure-authentication.md

@@ -8,7 +8,7 @@ ms.subservice: azure-mqtt-broker
 ms.topic: how-to
 ms.custom:
   - ignite-2023
-ms.date: 10/30/2024
+ms.date: 11/02/2024
 
 #CustomerIntent: As an operator, I want to configure authentication so that I have secure MQTT broker communications.
 ---
@@ -279,7 +279,7 @@ az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FI
 
 # [Kubernetes](#tab/kubernetes)
 
-Modify the *BrokerAuthentication* resource for a authentication policy by adding new methods to the `authenticationMethods` section. The following example shows multiple authentication methods for a *BrokerAuthentication* resource:
+Modify the *BrokerAuthentication* resource for an authentication policy by adding new methods to the `authenticationMethods` section. The following example shows multiple authentication methods for a *BrokerAuthentication* resource:
 
 ```yaml
 apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
@@ -762,7 +762,7 @@ MQTT broker disconnects clients when their credentials expire. Disconnect after
 
 On disconnect, the client's network connection is closed. The client won't receive an MQTT DISCONNECT packet, but the broker logs a message that it disconnected the client.
 
-MQTT v5 clients authenticated with SATs and custom authentication can reauthenticate with a new credential before their initial credential expires. X.509 clients cannot reauthenticate and must re-establish the connection since authentication is done at the TLS layer.
+MQTT v5 clients authenticated with SATs and custom authentication can reauthenticate with a new credential before their initial credential expires. X.509 clients can't reauthenticate and must re-establish the connection since authentication is done at the TLS layer.
 
 Clients can reauthenticate by sending an MQTT v5 AUTH packet.
 

articles/iot-operations/manage-mqtt-broker/howto-configure-authorization.md

@@ -303,7 +303,7 @@ spec:
 
 ---
 
-Here, if the `clientIds` were not set under the `Connect` method, a client with any client ID could connect as long as it had the `building` attribute set to `building22` or `building23`. By adding the `clientIds` field, only clients with client IDs that start with `building22` or `building23` can connect. This ensures not only that the client has the correct attribute but also that the client ID matches the expected pattern.
+Here, if the `clientIds` weren't set under the `Connect` method, a client with any client ID could connect as long as it had the `building` attribute set to `building22` or `building23`. By adding the `clientIds` field, only clients with client IDs that start with `building22` or `building23` can connect. This ensures not only that the client has the correct attribute but also that the client ID matches the expected pattern.
 
 ## Authorize clients that use X.509 authentication
 

articles/iot-operations/manage-mqtt-broker/howto-configure-brokerlistener.md

@@ -31,7 +31,7 @@ Listeners have the following characteristics:
 - BrokerAuthentication and BrokerAuthorization references are per port
 - TLS configuration is per port
 - Service names must be unique
-- Ports cannot conflict over different listeners
+- Ports can't conflict over different listeners
 
 For a list of the available settings, see the [Broker Listener](/rest/api/iotoperationsmq/broker-listener) API reference.
 
@@ -56,7 +56,7 @@ To view or edit the listener:
 
 # [Bicep](#tab/bicep)
 
-You should not modify the default listener using Bicep. Instead, create a new listener and configure it as needed.
+You shouldn't modify the default listener using Bicep. Instead, create a new listener and configure it as needed.
 
 # [Kubernetes](#tab/kubernetes)