Added links to matching learn guide (#7636)

website/source/docs/agent/autoauth/methods/aws.html.md

@@ -7,7 +7,7 @@ description: |-
   AWS Method for Vault Agent Auto-Auth
 ---
 
-# Vault Agent Auto-Auth AWS Method 
+# Vault Agent Auto-Auth AWS Method
 
 The `aws` method performs authentication against the [AWS Auth
 method](https://www.vaultproject.io/docs/auth/aws.html). Both `ec2` and `iam`
@@ -27,14 +27,14 @@ will use the first valid credentials it finds in the following order:
 2. Environment variables
 3. A file containing credentials
 4. From any identity services available in its physical environment like container environment variables or role-based instance metadata
- 
+
-Wherever possible, we recommend using identity services (method 4) for credentials. 
+Wherever possible, we recommend using identity services (method 4) for credentials.
-These rotate regularly and require no effort on your part to provision, making 
+These rotate regularly and require no effort on your part to provision, making
-identity services the most secure of the four methods. If using identity services _and_ a custom 
+identity services the most secure of the four methods. If using identity services _and_ a custom
 `credential_poll_interval`, be sure the frequency is set low enough to pick up new credentials
 from the physical environment as they become available.
 
-To use identity services, choose the `iam` type and leave the `access_key`, `secret_key`, and `session_token` 
+To use identity services, choose the `iam` type and leave the `access_key`, `secret_key`, and `session_token`
 parameters unset in your configuration.
 
 ## Configuration
@@ -53,3 +53,9 @@ parameters unset in your configuration.
 
 - `header_value` `(string: optional)` - If configured in Vault, the value to use for
   [`iam_server_id_header_value`](https://www.vaultproject.io/api/auth/aws/index.html#iam_server_id_header_value).
+
+## Learn
+
+Refer to the [Vault Agent with
+AWS](https://learn.hashicorp.com/vault/identity-access-management/vault-agent-aws)
+guide for a step-by-step tutorial.

website/source/docs/agent/autoauth/methods/kubernetes.html.md

@@ -7,7 +7,7 @@ description: |-
   Kubernetes Method for Vault Agent Auto-Auth
 ---
 
-# Vault Agent Auto-Auth Kubernetes Method 
+# Vault Agent Auto-Auth Kubernetes Method
 
 The `kubernetes` method reads in a Kubernetes service account token from the
 running pod (via `/var/run/secrets/kubernetes.io/serviceaccount/token`) and
@@ -19,3 +19,9 @@ method](https://www.vaultproject.io/docs/auth/kubernetes.html).
 - `role` `(string: required)` - The role to authenticate against on Vault
 - `token_path` `(string: optional)` - The file path to a custom JWT token to use
 for authentication. If omitted, the default service account token path is used.
+
+## Learn
+
+Refer to the [Vault Agent with
+Kubernetes](https://learn.hashicorp.com/vault/identity-access-management/vault-agent-k8s)
+guide for a step-by-step tutorial.

website/source/docs/agent/caching/index.html.md

@@ -232,3 +232,9 @@ vault {
   address = "http://127.0.0.1:8200"
 }
 ```
+
+## Learn
+
+Refer to the [Vault Agent
+Caching](https://learn.hashicorp.com/vault/identity-access-management/agent-caching)
+guide for a step-by-step tutorial.

website/source/docs/auth/approle.html.md

@@ -230,6 +230,12 @@ not require a credential, but still enforce constraints for login.  For
 example, `secret_id_bound_cidrs` will only allow logins coming from IP addresses
 belonging to configured CIDR blocks on the AppRole.
 
+## Learn
+
+Refer to the [AppRole Pull
+Authentication](https://learn.hashicorp.com/vault/identity-access-management/iam-authentication)
+guide for a step-by-step tutorial.
+
 ## API
 
 The AppRole auth method has a full HTTP API. Please see the

website/source/docs/concepts/policies.html.md

@@ -280,7 +280,7 @@ If you wanted to create a shared section of KV that is associated with entities
 group.
 
 ```ruby
-# In the example below, the group ID maps a group and the path 
+# In the example below, the group ID maps a group and the path
 path "secret/data/groups/{{identity.groups.ids.fb036ebc-2f62-4124-9503-42aa7A869741.name}}/*" {
   capabilities = ["create", "update", "read", "delete"]
 }
@@ -455,7 +455,7 @@ wrapping mandatory for a particular path.
     wrapped response.
 
 ```ruby
-# This effectively makes response wrapping mandatory for this path by setting min_wrapping_ttl to 1 second. 
+# This effectively makes response wrapping mandatory for this path by setting min_wrapping_ttl to 1 second.
 # This also sets this path's wrapped response maximum allowed TTL to 90 seconds.
 path "auth/approle/role/my-role/secret-id" {
     capabilities = ["create", "update"]
@@ -682,3 +682,11 @@ new set of policies.
 However, the _contents_ of policies are parsed in real-time whenever the token is used.
 As a result, if a policy is modified, the modified rules will be in force the
 next time a token, with that policy attached, is used to make a call to Vault.
+
+
+## Learn
+
+Refer to the following tutorials for further learning:
+
+- [Vault Policies](https://learn.hashicorp.com/vault/identity-access-management/iam-policies)
+- [ACL Policy Path Templating](https://learn.hashicorp.com/vault/identity-access-management/policy-templating)

website/source/docs/configuration/seal/awskms.html.md

@@ -40,7 +40,7 @@ seal "awskms" {
 These parameters apply to the `seal` stanza in the Vault configuration file:
 
 - `region` `(string: "us-east-1")`: The AWS region where the encryption key
-  lives. If not provided, may be populated from the `AWS_REGION` or 
+  lives. If not provided, may be populated from the `AWS_REGION` or
   `AWS_DEFAULT_REGION` environment variables, from your `~/.aws/config` file,
    or from instance metadata.
 
@@ -74,13 +74,12 @@ variables or as configuration parameters.
 `AWS_ACCESS_KEY_ID` and `AWS_ACCESS_KEY_ID` as part of the seal's parameters, it
 is *strongly* recommended to set these values via environment variables.
 
-```text
 AWS authentication values:
 
 * `AWS_REGION` or `AWS_DEFAULT_REGION`
 * `AWS_ACCESS_KEY_ID`
 * `AWS_SECRET_ACCESS_KEY`
-```
+
 
 Note: The client uses the official AWS SDK and will use the specified
 credentials, environment credentials, shared file credentials, or IAM role/ECS
@@ -99,20 +98,25 @@ the KMS key policy for the KMS key, or via KMS Grants on the key.
 ## `awskms` Environment Variables
 
 Alternatively, the AWS KMS seal can be activated by providing the following
-environment variables:
+environment variables.
 
-```text
 Vault Seal specific values:
 
 * `VAULT_SEAL_TYPE`
 * `VAULT_AWSKMS_SEAL_KEY_ID`
-```
+
 
 ## Key Rotation
 
-This seal supports rotating the master keys defined in AWS KMS 
+This seal supports rotating the master keys defined in AWS KMS
-[doc](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). Both automatic 
+[doc](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). Both automatic
-rotation and manual rotation is supported for KMS since the key information is stored with the 
+rotation and manual rotation is supported for KMS since the key information is stored with the
-encrypted data.  Old keys must not be disabled or deleted and are used to decrypt older data. 
+encrypted data.  Old keys must not be disabled or deleted and are used to decrypt older data.
 Any new or updated data will be encrypted with the current key defined in the seal configuration
 or set to current under a key alias.
+
+
+## Learn
+
+Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)
+guide for a step-by-step tutorial.

website/source/docs/configuration/seal/azurekeyvault.html.md

@@ -62,14 +62,13 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
 Authentication-related values must be provided, either as environment
 variables or as configuration parameters.
 
-```text
 Azure authentication values:
 
 * `AZURE_TENANT_ID`
 * `AZURE_CLIENT_ID`
 * `AZURE_CLIENT_SECRET`
 * `AZURE_ENVIRONMENT`
-```
+
 
 ~> **Note:** If Vault is hosted on Azure, Vault can use Managed Service
 Identities (MSI) to access Azure instead of an environment and shared client id
@@ -87,12 +86,15 @@ for more best practices.
 Alternatively, the Azure Key Vault seal can be activated by providing the following
 environment variables:
 
-```text
 * `VAULT_AZUREKEYVAULT_VAULT_NAME`
 * `VAULT_AZUREKEYVAULT_KEY_NAME`
-```
 
 ## Key Rotation
 
 This seal supports rotating keys defined in Azure Key Vault.  Key metadata is stored with the
 encrypted data to ensure the correct key is used during decryption operations.
+
+## Learn
+
+Refer to the [Auto-unseal using Azure Key Vault](https://learn.hashicorp.com/vault/operations/autounseal-azure-keyvault)
+guide for a step-by-step tutorial.

website/source/docs/configuration/seal/gcpckms.html.md

@@ -63,13 +63,12 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
 Authentication-related values must be provided, either as environment
 variables or as configuration parameters.
 
-```text
 GCP authentication values:
 
 * `GOOGLE_CREDENTIALS` or `GOOGLE_APPLICATION_CREDENTIALS`
 * `GOOGLE_PROJECT`
 * `GOOGLE_REGION`
-```
+
 
 Note: The client uses the official Google SDK and will use the specified
 credentials, environment credentials, or [application default
@@ -98,11 +97,10 @@ cloudkms.cryptoKeys.get
 Alternatively, the GCP Cloud KMS seal can be activated by providing the following
 environment variables:
 
-```text
 * `VAULT_SEAL_TYPE`
 * `VAULT_GCPCKMS_SEAL_KEY_RING`
 * `VAULT_GCPCKMS_SEAL_CRYPTO_KEY`
-```
+
 
 ## Key Rotation
 
@@ -111,3 +109,8 @@ This seal supports rotating keys defined in Google Cloud KMS
 rotation is supported for CKMS since the key information. Old keys version must not be
 disabled or deleted and are used to decrypt older data. Any new or updated data will be
 encrypted with the primary key version.
+
+## Learn
+
+Refer to the [Auto-unseal using GCP Cloud KMS](https://learn.hashicorp.com/vault/operations/autounseal-gcp-kms)
+guide for a step-by-step tutorial.

website/source/docs/configuration/seal/pkcs11.html.md

@@ -63,11 +63,11 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
   Vault binary is currently running on (e.g.: a Linux system may require other
   libraries to interpret Windows .dll files).
 
-- `slot` `(string: <slot or token label required>)`: The slot number to use, 
+- `slot` `(string: <slot or token label required>)`: The slot number to use,
   specified as a string (e.g. `"0"`). May also be specified by the `VAULT_HSM_SLOT`
   environment variable.
 
-- `token_label` `(string: <slot or token label required>)`: The slot token label to 
+- `token_label` `(string: <slot or token label required>)`: The slot token label to
   use. May also be specified by the `VAULT_HSM_TOKEN_LABEL` environment variable.
 
 - `pin` `(string: <required>)`: The PIN for login. May also be specified by the
@@ -83,8 +83,8 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
 - `default_key_label` `(string: "")`: This is the default key label for decryption
   operations.  Prior to 0.10.1, key labels were not stored with the ciphertext.
   Seal entries now track the label used in encryption operations.  The default value
-  for this field is the `key_label`.  If `key_label` is rotated and this value is not 
+  for this field is the `key_label`.  If `key_label` is rotated and this value is not
-  set, decryption may fail. May also be specified by the `VAULT_HSM_DEFAULT_KEY_LABEL` 
+  set, decryption may fail. May also be specified by the `VAULT_HSM_DEFAULT_KEY_LABEL`
   environment variable.  This value is ignored in new installations.
 
 - `hmac_key_label` `(string: <required>)`: The label of the key to use for
@@ -97,13 +97,13 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
 - `default_hmac_key_label` `(string: "")`: This is the default HMAC key label for signing
   operations.  Prior to 0.10.1, HMAC key labels were not stored with the signature.
   Seal entries now track the label used in signing operations.  The default value
-  for this field is the `hmac_key_label`.  If `hmac_key_label` is rotated and this 
+  for this field is the `hmac_key_label`.  If `hmac_key_label` is rotated and this
-  value is not set, signature verification may fail. May also be specified by the 
+  value is not set, signature verification may fail. May also be specified by the
-  `VAULT_HSM_HMAC_DEFAULT_KEY_LABEL` environment variable.  This value is ignored in 
+  `VAULT_HSM_HMAC_DEFAULT_KEY_LABEL` environment variable.  This value is ignored in
   new installations.
- 
+
 - `mechanism` `(string: <best available>)`: The encryption/decryption mechanism to use,
-  specified as a decimal or hexadecimal (prefixed by `0x`) string. May also be 
+  specified as a decimal or hexadecimal (prefixed by `0x`) string. May also be
   specified by the `VAULT_HSM_MECHANISM` environment variable.  
   Currently supported mechanisms (in order of precedence):
 
@@ -132,12 +132,12 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
 
 - `rsa_encrypt_local` `(string: "false")`: For HSMs that do not support encryption
   for RSA keys, perform encryption locally.  Available for mechanisms
-  `CKM_RSA_PKCS_OAEP` and `CKM_RSA_PKCS`.  May also be specified by the 
+  `CKM_RSA_PKCS_OAEP` and `CKM_RSA_PKCS`.  May also be specified by the
   `VAULT_HSM_RSA_ENCRYPT_LOCAL` environment variable.
 
 - `rsa_oaep_hash` `(string: "sha256")`: Specify the hash algorithm to use for RSA
-  with OAEP padding.  Valid values are sha1, sha224, sha256, sha384, and sha512. 
+  with OAEP padding.  Valid values are sha1, sha224, sha256, sha384, and sha512.
-  Available for mechanism `CKM_RSA_PKCS_OAEP`.  May also be specified by the 
+  Available for mechanism `CKM_RSA_PKCS_OAEP`.  May also be specified by the
   `VAULT_HSM_RSA_OAEP_HASH` environment variable.
 
 ~> **Note:** Although the configuration file allows you to pass in
@@ -235,9 +235,15 @@ _Private Key_
 This seal supports rotating keys by using different key labels to track key versions. To rotate
 the key value, generate a new key in a different key label in the HSM and update Vault's
 configuration with the new key label value.  Restart your vault instance to pick up the new key
-label and all new encryption operations will use the updated key label. Old keys must not be disabled 
+label and all new encryption operations will use the updated key label. Old keys must not be disabled
 or deleted and are used to decrypt older data.
 
-**NOTE**: Prior to version 0.10.1, key information was not tracked with the ciphertext. If 
+**NOTE**: Prior to version 0.10.1, key information was not tracked with the ciphertext. If
-rotation is desired for data that was seal wrapped prior to this version must also set 
+rotation is desired for data that was seal wrapped prior to this version must also set
 `default_key_label` and `hmac_default_key_label` to allow for decryption of older values.
+
+
+## Learn
+
+Refer to the [HSM Integration - Seal Wrap](https://learn.hashicorp.com/vault/operations/ops-seal-wrap)
+guide for a step-by-step tutorial.

website/source/docs/configuration/seal/transit.html.md

@@ -116,3 +116,8 @@ path "<mount path>/decrypt/<key name>" {
 This seal supports key rotation using the Transit Secret Engine's key rotation endpoints.  See
 [doc](/api/secret/transit/index.html#rotate-key). Old keys must not be disabled or deleted and are
 used to decrypt older data.
+
+## Learn
+
+Refer to the [Auto-unseal using Transit Secrets Engine](https://learn.hashicorp.com/vault/operations/autounseal-transit)
+guide for a step-by-step tutorial.

website/source/docs/enterprise/control-groups/index.html.md

@@ -15,20 +15,20 @@ add additional authorization factors to be required before satisfying a request.
 
 When a Control Group is required for a request, a limited duration response
 wrapping token is returned to the user instead of the requested data. The
-accessor of the response wrapping token can be passed to the authorizers 
+accessor of the response wrapping token can be passed to the authorizers
 required by the control group policy. Once all authorizations are satisfied,
 the wrapping token can be used to unwrap and process the original request.
 
 ## Control Group Factors
 
 Control Groups can verify the following factors:
- 
+
 - `Identity Groups` - Require an authorizer to be in a specific set of identity
 groups.
 
 ## Control Groups In ACL Policies
 
-Control Group requirements on paths are specified as `control_group` along 
+Control Group requirements on paths are specified as `control_group` along
 with other ACL parameters.
 
 ### Sample ACL Policies
@@ -71,10 +71,10 @@ path "secret/foo" {
 }
 ```
 
-The above policy grants `create` and `update` access to `secret/foo` only after 
+The above policy grants `create` and `update` access to `secret/foo` only after
 two member of the "managers" or "leads" group and one member of the "superusers"
-group authorizes the request.  If an authorizer is a member of both the 
+group authorizes the request.  If an authorizer is a member of both the
-"managers" and "superusers" group, one authorization for both factors will be 
+"managers" and "superusers" group, one authorization for both factors will be
 satisfied.
 
 ## Control Groups in Sentinel
@@ -113,7 +113,12 @@ The above policy will reject the request unless two members of the `managers`
 group have authorized the request. Additionally it verifies the authorizations
 happened in the last hour.
 
-### API
+## Learn
 
-Control Groups can be managed over the HTTP API. Please see 
+Refer to the [Control Groups](https://learn.hashicorp.com/vault/identity-access-management/iam-control-groups)
+guide for a step-by-step tutorial.
+
+## API
+
+Control Groups can be managed over the HTTP API. Please see
 [Control Groups API](/api/system/control-group.html) for more details.

website/source/docs/enterprise/namespaces/index.html.md

@@ -4,7 +4,7 @@ page_title: "Namespaces - Vault Enterprise"
 sidebar_title: "Namespaces"
 sidebar_current: "docs-vault-enterprise-namespaces"
 description: |-
-  Vault Enterprise has support for Namespaces, a feature to enable Secure Multi-tenancy (SMT) and self-management. 
+  Vault Enterprise has support for Namespaces, a feature to enable Secure Multi-tenancy (SMT) and self-management.
 
 ---
 
@@ -12,22 +12,22 @@ description: |-
 
 ## Overview
 
-Many organizations implement Vault as a "service", providing centralized 
+Many organizations implement Vault as a "service", providing centralized
 management for teams within an organization while ensuring that those teams
-operate within isolated environments known as *tenants*. 
+operate within isolated environments known as *tenants*.
 
 There are two common challenges when implementing this architecture in Vault:
 
 **Tenant Isolation**
 
 Frequently teams within a VaaS environment require strong isolation from other
-users in their policies, secrets, and identities. Tenant isolation is typically a 
+users in their policies, secrets, and identities. Tenant isolation is typically a
-result of compliance regulations such as [GDPR](https://www.eugdpr.org/), though it may 
+result of compliance regulations such as [GDPR](https://www.eugdpr.org/), though it may
 be necessitated by corporate or organizational infosec requirements.
 
 **Self-Management**
 
-As new tenants are added, there is an additional human cost in the management 
+As new tenants are added, there is an additional human cost in the management
 overhead for teams. Given that tenants will likely have different policies and
 request changes at a different rate, managing a multi-tenant environment can
 become very difficult for a single team as the number of tenants within that
@@ -62,7 +62,7 @@ For example, these three requests are equivalent:
 
 Namespaces are isolated environments that functionally exist as "Vaults within a Vault."
 They have separate login paths and support creating and managing data isolated to their
-namespace. This data includes the following: 
+namespace. This data includes the following:
 
 - Secret Engines
 - Auth Methods
@@ -72,17 +72,15 @@ namespace. This data includes the following:
 
 Rather than rely on Vault system admins, namespaces can be managed by delegated admins who
 can be prescribed administration rights for their namespace. These delegated admins can also
-create their own child namespaces, thereby prescribing admin rights on a subordinate group 
+create their own child namespaces, thereby prescribing admin rights on a subordinate group
-of delegate admins. 
+of delegate admins.
 
 Child namespaces can share policies from their parent namespaces. For example, a child namespace
 may refer to parent identities (entities and groups) when writing policies that function only
 within that child namespace. Similarly, a parent namespace can have policies asserted on child
-identities. 
+identities.
 
-## Setup and Best Practices
+## Learn
-
-A [deployment guide](/guides/operations/multi-tenant.html) is available to help guide you
-through the deployment and administration of namespaces, and contains examples on architecture
-for using namespaces to implement SMT across your organization. 
 
+Refer to the [Secure Multi-Tenancy with Namespaces](https://learn.hashicorp.com/vault/operations/namespaces)
+guide for a step-by-step tutorial.

website/source/docs/enterprise/replication/index.html.md

@@ -135,11 +135,15 @@ generation until it is used.
 Once a secondary is activated, its cluster information is stored safely behind
 its encrypted barrier.
 
-## Setup and Best Practices
 
-A [setup guide](/guides/operations/replication.html) is
+## Learn
-available to help you get started; this guide also contains best practices
+
-around operationalizing the replication feature.
+Refer to the following tutorials replication setup and best practices:
+
+- [Setting up Performance Replication](https://learn.hashicorp.com/vault/operations/ops-replication)
+- [Disaster Recovery Replication Setup](https://learn.hashicorp.com/vault/operations/ops-disaster-recovery)
+- [Performance Replication with Mount Filters](https://learn.hashicorp.com/vault/operations/mount-filter)
+- [Monitoring Vault Replication](https://learn.hashicorp.com/vault/operations/monitor-replication)
 
 ## API
 

website/source/docs/enterprise/sentinel/index.html.md

@@ -111,3 +111,8 @@ See the [Examples](/docs/enterprise/sentinel/examples.html) page for examples
 of Sentinel in action, and the
 [Properties](/docs/enterprise/sentinel/properties.html) page for detailed
 property documentation.
+
+## Learn
+
+Refer to the [Sentinel Policies](https://learn.hashicorp.com/vault/identity-access-management/iam-sentinel)
+guide for a step-by-step tutorial.

website/source/docs/secrets/azure/index.html.md

@@ -229,6 +229,11 @@ Vault releases, but the code is managed separately.
 Please report issues, add feature requests, and submit contributions to the
 [vault-plugin-secrets-azure repo][repo] on GitHub.
 
+## Learn
+
+Refer to the [Azure Secrets
+Engine](https://learn.hashicorp.com/vault/secrets-management/azure-creds) guide
+for a step-by-step tutorial.
 
 ## API
 The Azure secrets engine has a full HTTP API. Please see the [Azure secrets engine API docs][api]

website/source/docs/secrets/cubbyhole/index.html.md

@@ -52,6 +52,11 @@ engine allows for writing keys with arbitrary values.
     my-value    s3cr3t
     ```
 
+## Learn
+
+Refer to the [Cubbyhole Response Wrapping](https://learn.hashicorp.com/vault/secrets-management/sm-cubbyhole)
+guide for a step-by-step tutorial.
+
 ## API
 
 The Cubbyhole secrets engine has a full HTTP API. Please see the

website/source/docs/secrets/databases/index.html.md

@@ -107,6 +107,7 @@ of the role:
     password           8cab931c-d62e-a73d-60d3-5ee85139cd66
     username           v-root-e2978cd0-
     ```
+
 ## Custom Plugins
 
 This secrets engine allows custom database types to be run through the exposed
@@ -119,6 +120,14 @@ Password generation for both static and dynamic database credentials occurs via
 
 Please see the [DB plugin credentials source code](https://github.com/hashicorp/vault/blob/master/sdk/database/dbplugin/database.pb.go) for more information.
 
+## Learn
+
+Refer to the following step-by-step tutorials for more information:
+
+- [Secrets as a Service: Dynamic Secrets](https://learn.hashicorp.com/vault/secrets-management/sm-dynamic-secrets)
+- [Database Root Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-root-rotation)
+- [Database Static Roles and Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-creds-rotation)
+
 ## API
 
 The database secrets engine has a full HTTP API. Please see the [Database secret

website/source/docs/secrets/kmip/index.html.md

@@ -20,7 +20,7 @@ its storage and lifecycle to a key management server.
 ## Setup
 
 The KMIP secrets engine must be configured before it can start accepting KMIP
-requests. 
+requests.
 
 1. Enable the KMIP secrets engine
 
@@ -33,7 +33,7 @@ requests.
 TLS parameters, or leave unwritten to use default values
 
     ```text
-    $ vault write kmip/config listen_addrs=0.0.0.0:5696 
+    $ vault write kmip/config listen_addrs=0.0.0.0:5696
     ```
 
 ## Usage
@@ -56,15 +56,15 @@ allowed operations for it.
     $ vault write -f kmip/scope/my-service             
     Success! Data written to: kmip/scope/my-service
     ```
-    
+
 1. Create a role within the scope, specifying the set of operations to allow or
 deny.
 
     ```text
-    $ vault write kmip/scope/my-service/role/admin operation_all=true 
+    $ vault write kmip/scope/my-service/role/admin operation_all=true
       Success! Data written to: kmip/scope/my-service/role/admin
     ```
-    
+
 ### Client Certificate Generation
 
 Once a scope and role has been created, client certificates can be generated for
@@ -165,5 +165,11 @@ operation_all
 operation_none
 ```
 
+## Learn
+
+Refer to the [KMIP Secrets Engine](https://learn.hashicorp.com/vault/secrets-management/kmip-engine)
+guide for a step-by-step tutorial.
+
+
 [kmip-spec]: http://docs.oasis-open.org/kmip/spec/v1.4/kmip-spec-v1.4.html
 [kmip-ops]: http://docs.oasis-open.org/kmip/spec/v1.4/os/kmip-spec-v1.4-os.html#_Toc490660840

website/source/docs/secrets/kv/kv-v1.html.md

@@ -101,6 +101,12 @@ my-value            s3cr3t
 ttl                 30m
 ```
 
+## Learn
+
+Refer to the [Static Secrets: Key/Value Secrets
+Engine](https://learn.hashicorp.com/vault/secrets-management/sm-static-secrets)
+guide for a step-by-step tutorial.
+
 ## API
 
 The KV secrets engine has a full HTTP API. Please see the

website/source/docs/secrets/kv/kv-v2.html.md

@@ -394,6 +394,12 @@ See the commands below for more information:
 	Success! Data deleted (if it existed) at: secret/metadata/my-secret
     ```
 
+## Learn
+
+Refer to the [Versioned Key/Value Secrets
+Engine](https://learn.hashicorp.com/vault/secrets-management/sm-versioned-kv)
+guide for a step-by-step tutorial.
+
 ## API
 
 The KV secrets engine has a full HTTP API. Please see the

website/source/docs/secrets/pki/index.html.md

@@ -674,6 +674,11 @@ The CA Chain returns all the intermediate authorities in the trust chain. The ro
 authority is not included since that will usually be trusted by the underlying
 OS.
 
+## Learn
+
+Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine)
+guide for a step-by-step tutorial.
+
 ## API
 
 The PKI secrets engine has a full HTTP API. Please see the

website/source/docs/secrets/ssh/one-time-ssh-passwords.html.md

@@ -109,6 +109,12 @@ username@<IP of remote host>:~$
 Note: `sshpass` cannot handle host key checking. Host key checking can be
 disabled by setting `-strict-host-key-checking=no`.
 
+## Learn
+
+Refer to the [SSH Secrets Engine: One-Time SSH
+Password](https://learn.hashicorp.com/vault/secrets-management/sm-ssh-otp) guide
+for a step-by-step tutorial.
+
 ## API
 
 The SSH secrets engine has a full HTTP API. Please see the

website/source/docs/secrets/transit/index.html.md

@@ -208,6 +208,12 @@ plaintext with the newest key in the keyring.
     data, since the process would not be able to get access to the plaintext
     data.
 
+## Learn
+
+Refer to the [Encryption as a Service: Transit Secrets
+Engine](https://learn.hashicorp.com/vault/encryption-as-a-service/eaas-transit)
+guide for a step-by-step tutorial.
+
 ## API
 
 The Transit secrets engine has a full HTTP API. Please see the