Apply suggestions from code review

Co-authored-by: Christopher Scott <[email protected]>

Author: alexwolfmsft

docs/azure/sdk/authentication/authentication-best-practices.md

@@ -35,9 +35,9 @@ Other types of .NET apps can reuse credential instances as follows:
 The Azure Identity library for .NET allows you to authenticate via managed identity with `ManagedIdentityCredential`. The way you use `ManagedIdentityCredential` impacts the applied retry strategy:
 
 - When used via `DefaultAzureCredential`:
-  - No retries are attempted when token acquisition fails, which makes this the least resilient option.
+  - No retries are attempted when the initial token acquisition attempt fails or times out after a short duration, which makes this the least resilient option.
 - When used via any other approach, such as `ChainedTokenCredential` or `ManagedIdentityCredential` directly:
-  - The time interval between retries starts at 0.8 seconds, and a maximum of five retries are attempted.
+  - The time interval between retries starts at 0.8 seconds and increases exponentially. A maximum of five retries are attempted.
   - If the Azure service to which you're authenticating provides a `Retry-After` response header, the next retry is delayed by the duration specified in that header's value.
   - If the service doesn't provide a `Retry-After` header, the maximum permissible delay between retries is 1 minute.
   - To change any of the default retry settings, use the `Retry` property on `ManagedIdentityCredentialOptions`. For example, retry a maximum of three times, with a starting interval of 0.5 seconds:

docs/azure/sdk/includes/default-azure-credential-usage.md

@@ -1,5 +1,5 @@
 
-`DefaultAzureCredential` is the most approachable way to get started with the Azure Identity library, but that convenience also introduces certain tradeoffs. For example, the specific credential in the [chain](/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet) that will succeed and be used for request authentication can't be guaranteed ahead of time. In a production environment, this unpredictability can introduce significant and sometimes subtle problems.
+`DefaultAzureCredential` is the most approachable way to get started with the Azure Identity library, but that convenience also introduces certain tradeoffs. For example, the specific credential in the [chain](/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet) that will succeed and be used for request authentication is not 100% deterministic. In a production environment, this unpredictability can introduce significant and sometimes subtle problems.
 
 For example, consider the following hypothetical sequence of events:
 
@@ -13,7 +13,7 @@ For example, consider the following hypothetical sequence of events:
 `DefaultAzureCredential` also introduces the following challenges in some scenarios:
 
 - **Debugging challenges**: When authentication fails, it can be difficult to identify and [debug the offending credential](/dotnet/azure/sdk/authentication/credential-chains?tabs=dac#debug-a-chained-credential). Enable logging to see the sequential progression and success or failure status of each credential.
-- **Performance overhead**: Sequential credential attempts can introduce performance overhead. For example, managed identity is unavailable on a local development machine. Consequently, `ManagedIdentityCredential` always fails locally, unless explicitly disabled via its corresponding `Exclude`-prefixed property.
+- **Performance overhead**: Sequential credential attempts can introduce performance overhead into the developer inner loop. For example, managed identity is unavailable on a local development machine. Consequently, `ManagedIdentityCredential` always fails locally, unless explicitly disabled via its corresponding `Exclude`-prefixed property.
 
 To prevent these types of subtle issues or silent failures in production apps, strongly consider moving from `DefaultAzureCredential` to one of the following deterministic solutions: