diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index 52408e6022..05680c9cbd 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -181,45 +181,6 @@ If you want to access data from a Secret in a Pod, one way to do that is to
 have Kubernetes make the value of that Secret be available as a file inside
 the filesystem of one or more of the Pod's containers.
 
-To configure that, you:
-
-1. Create a secret or use an existing one. Multiple Pods can reference the same secret.
-1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything,
-   and have a `.spec.volumes[].secret.secretName` field equal to the name of the Secret object.
-1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the secret. Specify
-   `.spec.containers[].volumeMounts[].readOnly = true` and
-   `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the
-   secrets to appear.
-1. Modify your image or command line so that the program looks for files in that directory. Each
-   key in the secret `data` map becomes the filename under `mountPath`.
-
-This is an example of a Pod that mounts a Secret named `mysecret` in a volume:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-      readOnly: true
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      optional: false # default setting; "mysecret" must exist
-```
-
-Each Secret you want to use needs to be referred to in `.spec.volumes`.
-
-If there are multiple containers in the Pod, then each container needs its
-own `volumeMounts` block, but only one `.spec.volumes` is needed per Secret.
-
 {{< note >}}
 Versions of Kubernetes before v1.22 automatically created credentials for accessing
 the Kubernetes API. This older mechanism was based on creating token Secrets that
@@ -238,123 +199,6 @@ You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubec
 command to obtain a token from the `TokenRequest` API.
 {{< /note >}}
 
-#### Projection of Secret keys to specific paths
-
-You can also control the paths within the volume where Secret keys are projected.
-You can use the `.spec.volumes[].secret.items` field to change the target path of each key:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-      readOnly: true
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      items:
-      - key: username
-        path: my-group/my-username
-```
-
-What will happen:
-
-* the `username` key from `mysecret` is available to the container at the path
-  `/etc/foo/my-group/my-username` instead of at `/etc/foo/username`.
-* the `password` key from that Secret object is not projected.
-
-If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected.
-To consume all keys from the Secret, all of them must be listed in the `items` field.
-
-If you list keys explicitly, then all listed keys must exist in the corresponding Secret.
-Otherwise, the volume is not created.
-
-#### Secret files permissions
-
-You can set the POSIX file access permission bits for a single Secret key.
-If you don't specify any permissions, `0644` is used by default.
-You can also set a default mode for the entire Secret volume and override per key if needed.
-
-For example, you can specify a default mode like this:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      defaultMode: 0400
-```
-
-The secret is mounted on `/etc/foo`; all the files created by the
-secret volume mount have permission `0400`.
-
-{{< note >}}
-If you're defining a Pod or a Pod template using JSON, beware that the JSON
-specification doesn't support octal notation. You can use the decimal value
-for the `defaultMode` (for example, 0400 in octal is 256 in decimal) instead.
-If you're writing YAML, you can write the `defaultMode` in octal.
-{{< /note >}}
-
-#### Consuming Secret values from volumes
-
-Inside the container that mounts a secret volume, the secret keys appear as
-files. The secret values are base64 decoded and stored inside these files.
-
-This is the result of commands executed inside the container from the example above:
-
-```shell
-ls /etc/foo/
-```
-
-The output is similar to:
-
-```
-username
-password
-```
-
-```shell
-cat /etc/foo/username
-```
-
-The output is similar to:
-
-```
-admin
-```
-
-```shell
-cat /etc/foo/password
-```
-
-The output is similar to:
-
-```
-1f2d1e2e67df
-```
-
-The program in a container is responsible for reading the secret data from these
-files, as needed.
-
 #### Mounted Secrets are updated automatically
 
 When a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks
diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
index d2ca2feabd..203d2434f3 100644
--- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
+++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -149,6 +149,127 @@ Here is a configuration file you can use to create a Pod:
    39528$vdg7Jb
    ```
 
+Modify your image or command line so that the program looks for files in the
+`mountPath` directory. Each key in the Secret `data` map becomes a file name
+in this directory.
+
+#### Projection of Secret keys to specific paths
+
+You can also control the paths within the volume where Secret keys are projected.
+You can use the `.spec.volumes[].secret.items` field to change the target path of each key:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+      readOnly: true
+  volumes:
+  - name: foo
+    secret:
+      secretName: mysecret
+      items:
+      - key: username
+        path: my-group/my-username
+```
+
+What will happen:
+
+* the `username` key from `mysecret` is available to the container at the path
+  `/etc/foo/my-group/my-username` instead of at `/etc/foo/username`.
+* the `password` key from that Secret object is not projected.
+
+If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected.
+To consume all keys from the Secret, all of them must be listed in the `items` field.
+
+If you list keys explicitly, then all listed keys must exist in the corresponding Secret.
+Otherwise, the volume is not created.
+
+#### Secret files permissions
+
+You can set the POSIX file access permission bits for a single Secret key.
+If you don't specify any permissions, `0644` is used by default.
+You can also set a default mode for the entire Secret volume and override per key if needed.
+
+For example, you can specify a default mode like this:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+  volumes:
+  - name: foo
+    secret:
+      secretName: mysecret
+      defaultMode: 0400
+```
+
+The secret is mounted on `/etc/foo`; all the files created by the
+secret volume mount have permission `0400`.
+
+{{< note >}}
+If you're defining a Pod or a Pod template using JSON, beware that the JSON
+specification doesn't support octal notation. You can use the decimal value
+for the `defaultMode` (for example, 0400 in octal is 256 in decimal) instead.
+If you're writing YAML, you can write the `defaultMode` in octal.
+{{< /note >}}
+
+#### Consuming Secret values from volumes
+
+Inside the container that mounts a secret volume, the secret keys appear as
+files. The secret values are base64 decoded and stored inside these files.
+
+This is the result of commands executed inside the container from the example above:
+
+```shell
+ls /etc/foo/
+```
+
+The output is similar to:
+
+```
+username
+password
+```
+
+```shell
+cat /etc/foo/username
+```
+
+The output is similar to:
+
+```
+admin
+```
+
+```shell
+cat /etc/foo/password
+```
+
+The output is similar to:
+
+```
+1f2d1e2e67df
+```
+
+The program in a container is responsible for reading the secret data from these
+files, as needed.
+
 ## Define container environment variables using Secret data
 
 ### Define a container environment variable with data from a single Secret
diff --git a/content/en/examples/pods/inject/secret-pod.yaml b/content/en/examples/pods/inject/secret-pod.yaml
index 8be694cdde..8487da8d1c 100644
--- a/content/en/examples/pods/inject/secret-pod.yaml
+++ b/content/en/examples/pods/inject/secret-pod.yaml
@@ -10,6 +10,7 @@ spec:
         # name must match the volume name below
         - name: secret-volume
           mountPath: /etc/secret-volume
+          readOnly: true
   # The secret data is exposed to Containers in the Pod through a Volume.
   volumes:
     - name: secret-volume