Apply suggestions from code review

Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
Co-authored-by: Roman Tkachenko <roman@goteleport.com>

docs/config.json

@@ -579,7 +579,7 @@
 	  "slug": "/management/dynamic-resources/",
 	  "entries": [
         {
-          "title": "Managing users and roles",
+          "title": "Managing Users and Roles",
           "slug": "/management/dynamic-resources/user-and-role/"
         },
         {
@@ -1653,7 +1653,7 @@
           "slug": "/reference/signals/"
         },
         {
-          "title": "User types",
+          "title": "User Types",
           "slug": "/reference/user-types/"
         },
         {

docs/pages/management/dynamic-resources.mdx

@@ -59,9 +59,9 @@ to manipulate cluster resources stored on the Auth Service backend. The design
 of Teleport's configuration interface makes it well suited for
 infrastructure-as-code and GitOps approaches.
 
-You can get started with `tctl`, the Terraform Provider or the Kubernetes
+You can get started with `tctl`, the Terraform Provider, and the Kubernetes
 Operator by following
-the ["Managing users and roles with IaC" guide](./dynamic-resources/user-and-role.mdx)
+the ["Managing Users and Roles with IaC" guide](./dynamic-resources/user-and-role.mdx)
 
 For more information on Teleport roles, including the `internal.logins`
 trait we use in these example roles, see the [Teleport Access

docs/pages/management/dynamic-resources/access-list.mdx

@@ -3,9 +3,8 @@ title: Creating Access Lists with IaC
 description: Use Infrastructure-as-Code tooling to create Teleport AccessLists.
 ---
 
-Access Lists allow Teleport users to be granted long term access to resources
-managed within Teleport. With Access Lists, administrators and access list
-owners can regularly audit and control membership to specific roles and
+Access Lists allow Teleport users to be granted long-term access to resources
+managed within Teleport. With Access Lists, administrators can regularly audit and control membership to specific roles and
 traits, which then tie easily back into Teleport's existing RBAC system.
 
 In this guide, we'll follow up on [the IaC users and roles guide]()
@@ -26,7 +25,7 @@ ensures access grants are periodically reviewed.
 To follow this guide, you must follow first [the basic users and roles IaC guide]().
 We will reuse its users and roles for our Access List.
 
-### Step 1/3 - Write manifests
+## Step 1/3. Write manifests
 
 #### Write the privileged role manifest
 
@@ -53,7 +52,7 @@ spec:
 ```
 
 </TabItem>
-<TabItem label="operator">
+<TabItem label="Operator">
 
 Create the following `privileged-role.yaml` file:
 
@@ -75,7 +74,7 @@ yet roles v6 and v7.
 </Admonition>
 
 </TabItem>
-<TabItem label="terraform">
+<TabItem label="Terraform">
 
 Create the following `privileged-role.tf` file:
 
@@ -100,9 +99,9 @@ resource "teleport_role" "support-engineer" {
 </TabItem>
 </Tabs>
 
-#### Write the AccessList manifest
+#### Write the Access List manifest
 
-In this step we'll create an AccessList that allows users with the `manager`
+In this step we'll create an Access List that allows users with the `manager`
 role such as  `alice` to grant access to production to users with the `engineer`
 role.
 
@@ -137,7 +136,7 @@ spec:
 ```
 
 </TabItem>
-<TabItem label="operator">
+<TabItem label="Operator">
 
 Create the following `accesslist.yaml` file:
 
@@ -167,7 +166,7 @@ spec:
 ```
 
 </TabItem>
-<TabItem label="terraform">
+<TabItem label="Terraform">
 
 Create the following `accesslist.tf` file:
 
@@ -210,7 +209,7 @@ resource "teleport_access_list" "support-engineers" {
 </TabItem>
 </Tabs>
 
-### Step 2/3 - Apply the manifests
+## Step 2/3. Apply the manifests
 
 <Tabs>
 <TabItem label="tctl">
@@ -224,12 +223,12 @@ Access list "support-engineers" has been created
 ```
 
 <Admonition type="note">
-The user resource depends on roles, you must create roles before users as a user
+The user resource depends on roles. You must create roles before users as a user
 with a non-existing role is invalid and will be rejected by Teleport.
 </Admonition>
 
 </TabItem>
-<TabItem label="operator">
+<TabItem label="Operator">
 
 Create the Kubernetes CRs with the following commands:
 
@@ -242,7 +241,7 @@ teleportaccesslist.resources.teleport.dev/support-engineers
 ```
 
 </TabItem>
-<TabItem label="terraform">
+<TabItem label="Terraform">
 
 ```code
 $ terraform plan
@@ -259,15 +258,15 @@ teleport_access_list.support-engineers: Creation complete after 0s [id=support-e
 </TabItem>
 </Tabs>
 
-### Step 3/3 - Log in as `alice` and grant access to `bob`
+## Step 3/3. Log in as `alice` and grant access to `bob`
 
 Now, you created an Access List allowing `alice` to grant the `support-engineer`
 role to its engineers.
 
 You can log in as alice and add `bob` to the `support-engineers` Access List.
 
 <Tabs>
-<TabItem label="web UI">
+<TabItem label="Web UI">
 
 Login as `alice` in the web UI, open the management panel and select the
 "Access Lists" tab. Your Access List should be displayed, open it, choose "Enroll
@@ -276,7 +275,7 @@ members" and add `bob`.
 ![Screenshot of the web UI showing the Access List and the "Enroll Member" button](../../../img/management/access-list-web-ui.png)
 
 </TabItem>
-<TabItem label="cli">
+<TabItem label="CLI">
 
 Login as `alice` with `tsh`, then add bob to the Access List:
 

docs/pages/management/dynamic-resources/teleport-operator.mdx

@@ -49,5 +49,4 @@ follow [the standalone operator guide](./teleport-operator-standalone.mdx).
 ## Next steps
 
 - Follow the ["Managing users and roles with IaC" guide](./user-and-role.mdx).
-
-- Check out [access controls documentation](../../access-controls/introduction.mdx)
+- Check out [access controls documentation](../../access-controls/introduction.mdx).

docs/pages/reference/user-types.mdx

@@ -40,7 +40,7 @@ can still join even if local auth is disabled.
 The [Machine ID introduction](../machine-id/introduction.mdx).
 </Admonition>
 
-## Remote users (Single Sign On)
+## SSO users
 
 Those users are imported in Teleport from an external identity provider.
 Teleport contains a user resource representing those users, but it's only a
@@ -66,7 +66,7 @@ and automatically expires after a few days. Those users cannot be edited via
 The [SSO setup guides](../access-controls/sso.mdx).
 </Admonition>
 
-### Sync-ed users
+### Synced users
 
 Since version 15, Teleport supports fetching users from external identity
 providers like Okta.