diff --git a/docs/pages/kubernetes-access/manage-access/federation.mdx b/docs/pages/kubernetes-access/manage-access/federation.mdx
index 199766bd7a417..7ebb54d9052e9 100644
--- a/docs/pages/kubernetes-access/manage-access/federation.mdx
+++ b/docs/pages/kubernetes-access/manage-access/federation.mdx
@@ -13,20 +13,20 @@ to federate trust across Kubernetes clusters.
 <TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
 
 When multiple trusted clusters are present behind the Teleport Proxy Service, the
-`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) will contain the
+`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) contains the
 Kubernetes API endpoint determined by the `<cluster>` argument to [tsh
 login](../../reference/cli/tsh.mdx#tsh-login).
 
-For example, consider the following setup:
+For example, consider the following scenario:
 
 - There are three Teleport/Kubernetes clusters: the root cluster named `main` and the leaf clusters 
-  `east` and `west` specified in the `cluster_name` setting in each cluster's configuration file.
+  named `east` and `west` in the `cluster_name` setting for each cluster.
 - The clusters `east` and `west` trust the `main` root cluster certificate authority.
 - Users always authenticate against `main` but use their certificates to access
   SSH nodes and the Kubernetes API in all three clusters.
-- The DNS name of the main Proxy Service is `main.example.com`.
+- The DNS name of the root cluster Teleport Proxy Service is `main.example.com`.
 
-In this scenario, users usually log in using this command:
+In this scenario, users usually log in using the following command:
 
 ```code
 # Using login without arguments
@@ -46,19 +46,21 @@ $ tsh --proxy=main.example.com login east
 <TabItem scope={["cloud","team"]} label="Cloud-Hosted">
 
 When multiple trusted clusters are present behind the Teleport Proxy Service, the
-`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) will contain the
-Kubernetes API endpoint determined by the `<cluster>` argument to [tsh
-login](../../reference/cli/tsh.mdx#tsh-login).
+`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) contains the
+Kubernetes API endpoint determined by the `<cluster>` argument to the [tsh
+login](../../reference/cli/tsh.mdx#tsh-login) command.
 
-For example, consider the following setup:
+For example, consider the following scenario:
 
-- There are two Teleport/Kubernetes clusters, `east` and `west`. 
-  These are the names set in the `cluster_name` setting in their configuration files.
-- The clusters `east` and `west` are trusted clusters for a Teleport Team or Enterprise Cloud tenant, `mytenant.teleport.sh`.
+- There are two Teleport/Kubernetes clusters named `east` and `west`.
+  Each cluster has its own configuration file with its name specified in the 
+  `cluster_name` field.
+- The clusters `east` and `west` are leaf clusters that trust a Teleport Team 
+  or Enterprise Cloud account, for example, `mytenant.teleport.sh`.
 - Users always authenticate against `mytenant.teleport.sh` but use their certificates to access
   SSH nodes and the Kubernetes API in all three clusters.
 
-In this scenario, users usually log in using this command:
+In this scenario, users usually log in using the following command:
 
 ```code
 # Using login without arguments