Typo fix

Author: KimiaTahvildari

articles/active-directory/workload-identities/workload-identity-federation.md

@@ -28,7 +28,7 @@ Watch this video to learn why you would use workload identity federation.
 
 Typically, a software workload (such as an application, service, script, or container-based application) needs an identity in order to authenticate and access resources or communicate with other services.  When these workloads run on Azure, you can use [managed identities](../managed-identities-azure-resources/overview.md) and the Azure platform manages the credentials for you.  You can only use managed identities, however, for software workloads running in Azure.  For a software workload running outside of Azure, you need to use application credentials (a secret or certificate) to access Microsoft Entra ID protected resources (such as Azure, Microsoft Graph, Microsoft 365, or third-party resources).  These credentials pose a security risk and have to be stored securely and rotated regularly. You also run the risk of service downtime if the credentials expire.
 
-You use workload identity federation to configure an [user-assigned managed identity](../managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md) or [app registration](../develop/app-objects-and-service-principals.md) in Microsoft Entra ID to trust tokens from an external identity provider (IdP), such as GitHub or Google. The user-assigned managed identity or app registration in Microsoft Entra ID becomes an identity for software workloads running, for example, in on-premises Kubernetes or GitHub Actions workflows. Once that trust relationship is created, your external software workload exchanges trusted tokens from the external IdP for access tokens from Microsoft identity platform.  Your software workload uses that access token to access the Microsoft Entra ID protected resources to which the workload has been granted access. You eliminate the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire.
+You use workload identity federation to configure a [user-assigned managed identity](../managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md) or [app registration](../develop/app-objects-and-service-principals.md) in Microsoft Entra ID to trust tokens from an external identity provider (IdP), such as GitHub or Google. The user-assigned managed identity or app registration in Microsoft Entra ID becomes an identity for software workloads running, for example, in on-premises Kubernetes or GitHub Actions workflows. Once that trust relationship is created, your external software workload exchanges trusted tokens from the external IdP for access tokens from Microsoft identity platform.  Your software workload uses that access token to access the Microsoft Entra ID protected resources to which the workload has been granted access. You eliminate the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire.
 
 ## Supported scenarios