diff --git a/website/content/docs/concepts/acl.mdx b/website/content/docs/concepts/acl.mdx
index 784fbd5da56..1875004849e 100644
--- a/website/content/docs/concepts/acl.mdx
+++ b/website/content/docs/concepts/acl.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Access Control List (ACL)
-description: Learn about Nomad's ACL subsystem
+description: Learn how Nomad's Access Control List (ACL) feature uses tokens, policies, roles, and capabilities to control access.
---
# Access Control List (ACL)
@@ -15,7 +15,7 @@ Single Sign-On (SSO) ACL capabilities.
The Nomad [access control tutorials][] provide detailed information and
guidance on Nomad ACL system.
-### Policy
+## Policy
Policies consist of a set of rules defining the capabilities or actions to be
granted. For example, a `readonly` policy might only grant the ability to list
@@ -27,13 +27,13 @@ Nomad ACL token for accessing the objects in a Nomad cluster, objects like
namespaces, node, agent, operator, quota, etc. For more information on writing
policies, see the [ACL policy reference doc][].
-### Role
+## Role
Roles group one or more ACL policies into a container which can then be used to
generate ACL tokens for authorisation. This abstraction allows easier control
and updating of ACL permissions, particularly in larger, more diverse clusters.
-### Token
+## Token
Requests to Nomad are authenticated using a bearer token. Each ACL token has a
public Accessor ID which is used to name a token and a Secret ID which is used
@@ -49,14 +49,14 @@ other regions. Otherwise, tokens are created locally in the region the request
was made and not replicated. `Local` tokens cannot be used for cross-region
requests since they are not replicated between regions.
-### Workload Identity
+## Workload Identity
Nomad allocations can receive workload identities in the form of a
[JSON Web Token (JWT)][jwt]. The
[Workload Identity concept page][workload identity] has more information on
this topic.
-### Auth Method
+## Auth Method
Authentication methods dictate how Nomad should talk to SSO providers when a
user requests to authenticate using one. Currently, Nomad supports the [OpenID
@@ -64,7 +64,7 @@ Connect (OIDC)][oidc] SSO workflow which allows users to log in to Nomad via
applications such as [Auth0][auth0], [Okta][okta], and [Vault][vault], and
non-interactive login via externally-issued [JSON Web Tokens (JWT)][jwt].
-### Binding Rule
+## Binding Rule
Binding rules provide a mapping between a Nomad user's SSO authorisation claims
and internal Nomad objects such as ACL Roles and ACL Policies. A binding rule
diff --git a/website/content/docs/concepts/architecture/federation.mdx b/website/content/docs/concepts/architecture/federation.mdx
index 6d1b73ca218..921efa3ec58 100644
--- a/website/content/docs/concepts/architecture/federation.mdx
+++ b/website/content/docs/concepts/architecture/federation.mdx
@@ -2,28 +2,29 @@
layout: docs
page_title: Federation
description: |-
- Nomad federation is a multi-cluster orchestration and management feature that allows multiple
- Nomad clusters, defined as a region, to work together seamlessly.
+ Learn how Nomad federation enables multiple Nomad clusters, defined as a region, to work together seamlessly.
---
# Federation
-Nomad federation is a multi-cluster orchestration and management feature that allows multiple Nomad
-clusters, defined as a region, to work together seamlessly. By federating clusters, you benefit
-from improved scalability, fault tolerance, and centralized management of workloads across various
-data centers or geographical locations.
+Nomad federation is a multi-cluster orchestration and management feature that
+enables multiple Nomad clusters, defined as a region, to work together
+seamlessly. By federating clusters, you benefit from improved scalability, fault
+tolerance, and centralized management of workloads across various data centers
+or geographical locations.
## Cross-Region request forwarding
-API calls can include a `region` query parameter that defines the Nomad region the query is
-specified for. If this is not the local region, Nomad transparently forwards the request to a
-server in the requested region. When you omit the query parameter, Nomad uses the region of the
-server that is processing the request.
+API calls can include a `region` query parameter that defines the Nomad region
+the query is specified for. If this is not the local region, Nomad transparently
+forwards the request to a server in the requested region. When you omit the
+query parameter, Nomad uses the region of the server that is processing the
+request.
## Replication
-Nomad writes the following objects in the authoritative region and replicates them to all federated
-regions:
+Nomad writes the following objects in the authoritative region and replicates
+them to all federated regions:
- ACL [policies][acl_policy], [roles][acl_role], [auth methods][acl_auth_method],
[binding rules][acl_binding_rule], and [global tokens][acl_token]
@@ -32,25 +33,25 @@ regions:
- [Quota specifications][quota]
- [Sentinel policies][sentinel_policies]
-When creating, updating, or deleting these objects, Nomad always sends the request to the
-authoritative region using RPC forwarding.
+When creating, updating, or deleting these objects, Nomad always sends the
+request to the authoritative region using RPC forwarding.
-Nomad starts replication routines on each federated cluster's leader server in a hub and spoke
-design. The routines then use blocking queries to receive updates from the authoritative region to
-mirror in their own state store. These routines also implement rate limiting, so that busy clusters
-do not degrade due to overly aggressive replication processes.
+Nomad starts replication routines on each federated cluster's leader server in a
+hub and spoke design. The routines then use blocking queries to receive updates
+from the authoritative region to mirror in their own state store. These routines
+also implement rate limiting, so that busy clusters do not degrade due to overly
+aggressive replication processes.
-
-Nomad writes ACL local tokens in the region where you make the request and does not replicate
-those local tokens.
-
+ Nomad writes ACL local tokens in the region where you make the request
+and does not replicate those local tokens.
## Multi-Region job deployments
-Nomad job deployments can use the [`multiregion`][] block when running in federated mode.
-Multiregion configuration instructs Nomad to register and run the job on all the specified regions,
-removing the need for multiple job specification copies and registration on each region.
-Multiregion jobs do not provide regional failover in the event of failure.
+Nomad job deployments can use the [`multiregion`][] block when running in
+federated mode. Multiregion configuration instructs Nomad to register and run
+the job on all the specified regions, removing the need for multiple job
+specification copies and registration on each region. Multiregion jobs do not
+provide regional failover in the event of failure.
[acl_policy]: /nomad/docs/concepts/acl#policy
[acl_role]: /nomad/docs/concepts/acl#role
diff --git a/website/content/docs/concepts/architecture/index.mdx b/website/content/docs/concepts/architecture/index.mdx
index f204891550a..bfa17935dc3 100644
--- a/website/content/docs/concepts/architecture/index.mdx
+++ b/website/content/docs/concepts/architecture/index.mdx
@@ -1,7 +1,8 @@
---
layout: docs
page_title: Architecture
-description: Learn about the internal architecture of Nomad.
+description: |-
+ Learn how Nomad's system architecture implements a run any workload anywhere approach to scheduling and orchestration.
---
# Architecture
diff --git a/website/content/docs/concepts/consensus.mdx b/website/content/docs/concepts/consensus.mdx
index 509c257c87d..6841e19a783 100644
--- a/website/content/docs/concepts/consensus.mdx
+++ b/website/content/docs/concepts/consensus.mdx
@@ -2,16 +2,13 @@
layout: docs
page_title: Consensus Protocol
description: |-
- Nomad uses a consensus protocol to provide Consistency as defined by CAP.
- The consensus protocol is based on Raft: In search of an Understandable
- Consensus Algorithm. For a visual explanation of Raft, see The Secret Lives of
- Data.
+ Learn how Nomad uses a consensus protocol based on Raft to manage cluster node state.
---
# Consensus Protocol
Nomad uses a [consensus protocol]()
-to provide [Consistency (as defined by CAP)](https://en.wikipedia.org/wiki/CAP_theorem).
+to provide [Consistency as defined by CAP](https://en.wikipedia.org/wiki/CAP_theorem).
The consensus protocol is based on
["Raft: In search of an Understandable Consensus Algorithm"](https://raft.github.io/raft.pdf).
For a visual explanation of Raft, see [The Secret Lives of Data](http://thesecretlivesofdata.com/raft).
@@ -182,7 +179,7 @@ failure scenario.
| 2 |
0 |
-
+
| 3 |
2 |
1 |
@@ -192,7 +189,7 @@ failure scenario.
3 |
1 |
-
+
| 5 |
3 |
2 |
diff --git a/website/content/docs/concepts/cpu.mdx b/website/content/docs/concepts/cpu.mdx
index e492aae0272..031102c0782 100644
--- a/website/content/docs/concepts/cpu.mdx
+++ b/website/content/docs/concepts/cpu.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: CPU
-description: Learn about how Nomad manages CPU resources.
+description: Learn how Nomad manages CPU resources.
---
# Modern processors
diff --git a/website/content/docs/concepts/filesystem.mdx b/website/content/docs/concepts/filesystem.mdx
index 74dff6d50a0..4c404ad0b1d 100644
--- a/website/content/docs/concepts/filesystem.mdx
+++ b/website/content/docs/concepts/filesystem.mdx
@@ -2,11 +2,10 @@
layout: docs
page_title: Filesystem
description: |-
- Nomad creates an allocation working directory for every allocation. Learn what
- goes into the working directory and how it interacts with Nomad task drivers.
+ Learn how Nomad uses allocation working directories to store task artifacts and logs.
---
-# Filesystem
+# Allocation Filesystems
Nomad creates a working directory for each allocation on a client. This
directory can be found in the Nomad [`data_dir`] at
diff --git a/website/content/docs/concepts/gossip.mdx b/website/content/docs/concepts/gossip.mdx
index 8ea094b4e35..3d89b603896 100644
--- a/website/content/docs/concepts/gossip.mdx
+++ b/website/content/docs/concepts/gossip.mdx
@@ -2,8 +2,7 @@
layout: docs
page_title: Gossip Protocol
description: |-
- Nomad uses a gossip protocol to manage membership. All of this is provided
- through the use of the Serf library.
+ Learn how Nomad uses a gossip protocol to manage membership.
---
# Gossip Protocol
diff --git a/website/content/docs/concepts/index.mdx b/website/content/docs/concepts/index.mdx
index 105e8f44fe7..f13be5647b6 100644
--- a/website/content/docs/concepts/index.mdx
+++ b/website/content/docs/concepts/index.mdx
@@ -2,8 +2,7 @@
layout: docs
page_title: Concepts
description: >-
- This section covers the core concepts of Nomad and explains technical details of
- Nomads operation.
+ Learn about Nomad's architecture, core concepts, and behavior.
---
# Nomad Concepts
diff --git a/website/content/docs/concepts/job.mdx b/website/content/docs/concepts/job.mdx
index c6ff1f49947..e71fd1ff531 100644
--- a/website/content/docs/concepts/job.mdx
+++ b/website/content/docs/concepts/job.mdx
@@ -2,7 +2,7 @@
layout: docs
page_title: Job
description: |-
- Learn about Nomad's job feature, which is how you deploy your apps, maintenance scripts, cron jobs, and similar tasks.
+ Learn how a Nomad job deploys your apps, maintenance scripts, cron jobs, and similar tasks.
---
# Job
diff --git a/website/content/docs/concepts/node-pools.mdx b/website/content/docs/concepts/node-pools.mdx
index e87474f7cb4..48458cb3a29 100644
--- a/website/content/docs/concepts/node-pools.mdx
+++ b/website/content/docs/concepts/node-pools.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Node Pools
-description: Learn about the internal architecture of Nomad.
+description: Learn about Nomad's node pools group clients and segment infrastructure into logical units for allocation placement.
---
# Node Pools
diff --git a/website/content/docs/concepts/plugins/base.mdx b/website/content/docs/concepts/plugins/base.mdx
index 3d546a93e14..3aa8919dfab 100644
--- a/website/content/docs/concepts/plugins/base.mdx
+++ b/website/content/docs/concepts/plugins/base.mdx
@@ -1,7 +1,8 @@
---
layout: docs
page_title: Base Plugin
-description: Learn about how to author a Nomad plugin.
+description: |-
+ Learn how to create a Nomad plugin so you can extend Nomad's functionality.
---
# Base Plugin
diff --git a/website/content/docs/concepts/plugins/cni.mdx b/website/content/docs/concepts/plugins/cni.mdx
index 74c13eb6519..d8a33bad361 100644
--- a/website/content/docs/concepts/plugins/cni.mdx
+++ b/website/content/docs/concepts/plugins/cni.mdx
@@ -1,7 +1,8 @@
---
layout: docs
page_title: Network Plugins
-description: Learn how Nomad manages custom user-specified network configurations.
+description: |-
+ Learn how Nomad's network plugin support enables scheduling tasks with custom network configurations.
---
# Network plugins
diff --git a/website/content/docs/concepts/plugins/csi.mdx b/website/content/docs/concepts/plugins/csi.mdx
index a7f5a4ed196..4737118819c 100644
--- a/website/content/docs/concepts/plugins/csi.mdx
+++ b/website/content/docs/concepts/plugins/csi.mdx
@@ -1,7 +1,8 @@
---
layout: docs
page_title: Storage Plugins
-description: Learn how Nomad manages dynamic storage plugins.
+description: |-
+ Learn how Nomad's storage plugin support enables scheduling tasks with external storage volumes.
---
# Storage Plugins
diff --git a/website/content/docs/concepts/plugins/devices.mdx b/website/content/docs/concepts/plugins/devices.mdx
index 40da71b30d4..ce360adfddd 100644
--- a/website/content/docs/concepts/plugins/devices.mdx
+++ b/website/content/docs/concepts/plugins/devices.mdx
@@ -1,7 +1,8 @@
---
layout: docs
page_title: Device Plugins
-description: Learn how to author a Nomad device plugin.
+description: |-
+ Learn how to create a Nomad device plugin so you can schedule tasks with other devices, such as GPUs.
---
# Devices
diff --git a/website/content/docs/concepts/plugins/index.mdx b/website/content/docs/concepts/plugins/index.mdx
index 401d472f2bf..53901d91087 100644
--- a/website/content/docs/concepts/plugins/index.mdx
+++ b/website/content/docs/concepts/plugins/index.mdx
@@ -1,12 +1,12 @@
---
layout: docs
page_title: Plugins
-description: Learn about how external plugins work in Nomad.
+description: Learn how external plugins let you extend Nomad's functionality.
---
# Plugins
-Nomad implements a plugin framework which allows users to extend the
+Nomad implements a plugin framework which lets you extend the
functionality of some components within Nomad. The design of the plugin system
is inspired by the lessons learned from plugin systems implemented in other
HashiCorp products such as Terraform and Vault.
@@ -16,7 +16,7 @@ The following components are currently pluggable within Nomad:
- [Task Drivers](/nomad/docs/concepts/plugins/task-drivers)
- [Devices](/nomad/docs/concepts/plugins/devices)
-# Architecture
+## Architecture
The Nomad plugin framework uses the [go-plugin][goplugin] project to expose
a language independent plugin interface. Plugins implement a set of gRPC
diff --git a/website/content/docs/concepts/plugins/task-drivers.mdx b/website/content/docs/concepts/plugins/task-drivers.mdx
index 4d457ec0e5f..dc12b088758 100644
--- a/website/content/docs/concepts/plugins/task-drivers.mdx
+++ b/website/content/docs/concepts/plugins/task-drivers.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Task Driver Plugins
-description: Learn how to author a Nomad task driver plugin.
+description: Learn how to create a Nomad task driver plugin to extend Nomad's workload execution functionality.
---
# Task Drivers
diff --git a/website/content/docs/concepts/scheduling/index.mdx b/website/content/docs/concepts/scheduling/index.mdx
index 1bc895b27ad..d354601dc6e 100644
--- a/website/content/docs/concepts/scheduling/index.mdx
+++ b/website/content/docs/concepts/scheduling/index.mdx
@@ -1,12 +1,12 @@
---
layout: docs
page_title: Scheduling
-description: Learn about how scheduling works in Nomad.
+description: Learn how Nomad's scheduling component assigns jobs to client machines.
---
-# Scheduling
+# Scheduling workloads
-Scheduling is a core function of Nomad. It is the process of assigning tasks
+Scheduling workloads is a core function of Nomad. It is the process of assigning tasks
from jobs to client machines. The design is heavily inspired by Google's work on
both [Omega: flexible, scalable schedulers for large compute clusters][omega] and
[Large-scale cluster management at Google with Borg][borg]. See the links below
diff --git a/website/content/docs/concepts/scheduling/placement.mdx b/website/content/docs/concepts/scheduling/placement.mdx
index b50949ae0a5..1a77d86b0ef 100644
--- a/website/content/docs/concepts/scheduling/placement.mdx
+++ b/website/content/docs/concepts/scheduling/placement.mdx
@@ -1,10 +1,10 @@
---
layout: docs
page_title: Placement
-description: Learn about how placements are computed in Nomad.
+description: Learn how Nomad schedules jobs to run on clients.
---
-# Placement
+# Allocation Placement
When the Nomad scheduler receives a job registration request, it needs to
determine which clients will run allocations for the job.
diff --git a/website/content/docs/concepts/scheduling/preemption.mdx b/website/content/docs/concepts/scheduling/preemption.mdx
index 93ce9723a6e..95cdd9a5f57 100644
--- a/website/content/docs/concepts/scheduling/preemption.mdx
+++ b/website/content/docs/concepts/scheduling/preemption.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Preemption
-description: Learn about how preemption works in Nomad.
+description: Learn how Nomad uses preemption to evict existing allocations in order to place allocations for a higher priority job.
---
# Preemption
@@ -12,7 +12,7 @@ run high priority jobs even under resource contention across the cluster.
~> **Advanced Topic!** This page covers technical details of Nomad. You do not need to understand these details to effectively use Nomad. The details are documented here for those who wish to learn about them without having to go spelunking through the source code.
-# Preemption in Nomad
+## Preemption in Nomad
Every job in Nomad has a priority associated with it. Priorities impact scheduling at the evaluation and planning
stages by sorting the respective queues accordingly (higher priority jobs get moved ahead in the queues).
@@ -21,7 +21,7 @@ Nomad has preemption capabilities for service, batch, and system jobs. The Nomad
to free up capacity for new allocations resulting from relatively higher priority jobs, sending evicted allocations back
into the plan queue.
-# Details
+## Details
Preemption is enabled by default for system jobs. Operators can use the [scheduler config](/nomad/api-docs/operator#update-scheduler-configuration) API endpoint to disable preemption.
@@ -45,7 +45,7 @@ Allocations are selected starting from the lowest priority, and scored according
to how closely they fit the job's required capacity. For example, if the `75` priority job needs 1GB disk and 2GB memory, Nomad will preempt
allocations `a1`, `a2` and `a4` to satisfy those requirements.
-# Preemption Visibility
+## Preemption Visibility
Operators can use the [allocation API](/nomad/api-docs/allocations#read-allocation) or the `alloc status` command to get visibility into
whether an allocation has been preempted. Preempted allocations will have their DesiredStatus set to “evict”. The `Allocation` object
@@ -57,7 +57,7 @@ in the API also has two additional fields related to preemption.
- `PreemptedByAllocID` - This field is set on allocations that were preempted by the scheduler. It contains the allocation ID of the allocation
that preempted it. In the above example, allocations `a1`, `a2` and `a4` will have this field set to the ID of the allocation from the job `webapp`.
-# Integration with Nomad plan
+## Integration with Nomad plan
`nomad plan` allows operators to dry run the scheduler. If the scheduler determines that
preemption is necessary to place the job, it shows additional information in the CLI output for
diff --git a/website/content/docs/concepts/scheduling/scheduling.mdx b/website/content/docs/concepts/scheduling/scheduling.mdx
index e6b39f24986..b648cc8c8c4 100644
--- a/website/content/docs/concepts/scheduling/scheduling.mdx
+++ b/website/content/docs/concepts/scheduling/scheduling.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Scheduling
-description: Learn about how scheduling works in Nomad.
+description: Learn how Nomad implements job scheduling.
---
# Scheduling in Nomad
diff --git a/website/content/docs/concepts/security.mdx b/website/content/docs/concepts/security.mdx
index fdb707f1b1b..59803afdcb3 100644
--- a/website/content/docs/concepts/security.mdx
+++ b/website/content/docs/concepts/security.mdx
@@ -2,11 +2,7 @@
layout: docs
page_title: Security Model
description: >-
- Nomad relies on both a lightweight gossip mechanism and an RPC system to
- provide various features. Both of the systems have different security
- mechanisms that stem from their designs. However, the security mechanisms of
- Nomad have a common goal: to provide confidentiality, integrity, and
- authentication.
+ Learn how Nomad's lightweight gossip and RPC system provides security mechanisms for confidentiality, integrity, and authentication.
---
# Security Model
@@ -46,7 +42,7 @@ but the general mechanisms for a secure Nomad deployment revolve around:
(**Enterprise Only**) - Sentinel policies allow for granular control over
components such as task drivers within a cluster.
-### Personas
+## Personas
When thinking about Nomad, it helps to consider the following types of base
personas when managing the security requirements for the cluster deployment. The
@@ -84,7 +80,7 @@ within Nomad itself.
internet such as a web server. This is someone who shouldn't have any
network access to the Nomad server API.
-### Secure Configuration
+## Secure Configuration
Nomad's security model is applicable only if all parts of the system are running
with a secure configuration; **Nomad is not secure-by-default.** Without the following
@@ -93,7 +89,7 @@ to a cluster. Like all security considerations, one must appropriately determine
what concerns they have for their environment and adapt to these security
recommendations accordingly.
-#### Requirements
+### Requirements
- **[mTLS enabled](/nomad/tutorials/transport-security/security-enable-tls)** -
Mutual TLS (mTLS) enables [mutual
@@ -167,7 +163,7 @@ recommendations accordingly.
Access to these resource quotas can be managed via ACLs to ensure read-only
access for operators so they can't just change their quotas.
-#### Recommendations
+### Recommendations
The following are security recommendations that can help significantly improve
the security of your cluster depending on your use case. We recommend always
@@ -226,7 +222,7 @@ environment.
- **[HTTP Headers](/nomad/docs/configuration#http_api_response_headers)** -
Additional security [headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers), such as [`X-XSS-Protection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection), can be [configured](/nomad/docs/configuration#http_api_response_headers) for HTTP API responses.
-### Threat Model
+## Threat Model
The following are parts of the Nomad threat model:
@@ -292,7 +288,7 @@ The following are not part of the threat model for client agents:
devices. Such privileges can be used to facilitate compromise other workloads,
or cause denial-of-service attacks.
-#### Internal Threats
+### Internal Threats
- **Job Operator** - Someone with a valid mTLS certificate and ACL token may still be a
threat to your cluster in certain situations, especially in multi-team
@@ -316,7 +312,7 @@ The following are not part of the threat model for client agents:
to an exposed Docker daemon API through other means such as the [`raw_exec`](/nomad/docs/drivers/raw_exec)
driver.
-#### External Threats
+### External Threats
There are two main components to consider to for external threats in a Nomad cluster:
@@ -331,7 +327,7 @@ There are two main components to consider to for external threats in a Nomad clu
a client node is unencrypted in the agent's data and configuration
directory.
-### Network Ports
+## Network Ports
| **Port / Protocol** | Agents | Description |
|----------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
diff --git a/website/content/docs/concepts/variables.mdx b/website/content/docs/concepts/variables.mdx
index 9b1fc45a95a..04837a41b80 100644
--- a/website/content/docs/concepts/variables.mdx
+++ b/website/content/docs/concepts/variables.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Variables
-description: Learn about the Nomad Variables feature
+description: Learn how Nomad Variables lets you store and use encrypted configuration data in your job specifications.
---
# Nomad Variables
@@ -222,16 +222,16 @@ As soon as any instance starts, it tries to lock the sync variable. If it succee
it continues to execute while a secondary thread is in charge of keeping track of
the lock and renewing it when necessary. If by any chance the renewal fails,
the main process is forced to return, and the instance goes into standby until it
-attempts to acquire the lock over the sync variable.
+attempts to acquire the lock over the sync variable.
-Only threads 1 and 3 or thread 2 are running at any given time, because every
-instance is either executing as normal while renewing the lock or waiting for a
+Only threads 1 and 3 or thread 2 are running at any given time, because every
+instance is either executing as normal while renewing the lock or waiting for a
chance to acquire it and run.
-When the main process, or protected function, returns, the helper releases the
+When the main process, or protected function, returns, the helper releases the
lock, allowing a second instance to start running.
-To see it implemented live, look for the [`nomad var lock`][] command
+To see it implemented live, look for the [`nomad var lock`][] command
implementation or the [Nomad Autoscaler][] High Availability implementation.
diff --git a/website/content/docs/concepts/workload-identity.mdx b/website/content/docs/concepts/workload-identity.mdx
index 5effb4ae2d1..20c6522a9aa 100644
--- a/website/content/docs/concepts/workload-identity.mdx
+++ b/website/content/docs/concepts/workload-identity.mdx
@@ -1,7 +1,7 @@
---
layout: docs
page_title: Workload Identity
-description: Learn about Nomad's workload identity feature
+description: Learn how Nomad's workload identity feature isolates and uniquely identities each workload so you can associate ACLs to workloads.
---
# Workload Identity