diff --git a/site/content/en/docs/Reference/API/Kustomization File/configMapGenerator.md b/site/content/en/docs/Reference/API/Kustomization File/configMapGenerator.md
index 02b04804ff..e37a98d6d2 100644
--- a/site/content/en/docs/Reference/API/Kustomization File/configMapGenerator.md	
+++ b/site/content/en/docs/Reference/API/Kustomization File/configMapGenerator.md	
@@ -6,354 +6,3 @@ weight: 6
 description: >
     Generate ConfigMap resources.
 ---
-
-Each entry in this list results in the creation of
-one ConfigMap resource (it's a generator of n maps).
-
-The example below creates four ConfigMaps:
-
-- first, with the names and contents of the given files
-- second, with key/value as data using key/value pairs from files
-- third, also with key/value as data, directly specified using `literals`
-- and a fourth, which sets an annotation and label via `options` for that single ConfigMap
-
-Each configMapGenerator item accepts a parameter of
-`behavior: [create|replace|merge]`.
-This allows an overlay to modify or
-replace an existing configMap from the parent.
-
-Also, each entry has an `options` field, that has the
-same subfields as the kustomization file's `generatorOptions` field.
-  
-This `options` field allows one to add labels and/or
-annotations to the generated instance, or to individually
-disable the name suffix hash for that instance.
-Labels and annotations added here will not be overwritten
-by the global options associated with the kustomization
-file `generatorOptions` field.  However, due to how
-booleans behave, if the global `generatorOptions` field
-specifies `disableNameSuffixHash: true`, this will
-trump any attempt to locally override it.
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-# These labels are added to all configmaps and secrets.
-generatorOptions:
-  labels:
-    fruit: apple
-
-configMapGenerator:
-- name: my-java-server-props
-  behavior: merge
-  files:
-  - application.properties
-  - more.properties
-- name: my-java-server-env-file-vars
-  envs:
-  - my-server-env.properties
-  - more-server-props.env
-- name: my-java-server-env-vars
-  literals:
-  - JAVA_HOME=/opt/java/jdk
-  - JAVA_TOOL_OPTIONS=-agentlib:hprof
-  options:
-    disableNameSuffixHash: true
-    labels:
-      pet: dog
-- name: dashboards
-  files:
-  - mydashboard.json
-  options:
-    annotations:
-      dashboard: "1"
-    labels:
-      app.kubernetes.io/name: "app1"
-```
-
-It is also possible to
-[define a key](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-the-key-to-use-when-creating-a-configmap-from-a-file)
-to set a name different than the filename.
-
-The example below creates a ConfigMap
-with the name of file as `myFileName.ini`
-while the _actual_ filename from which the
-configmap is created is `whatever.ini`.
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-configMapGenerator:
-- name: app-whatever
-  files:
-  - myFileName.ini=whatever.ini
-```
-
-## ConfigMap `from File`
-
-ConfigMap Resources may be generated from files - such as a java `.properties` file.  To generate a ConfigMap
-Resource for a file, add an entry to `configMapGenerator` with the filename.
-
-**Example:** Generate a ConfigMap with a data item containing the contents of a file.
-
-The ConfigMaps will have data values populated from the file contents.  The contents of each file will
-appear as a single data item in the ConfigMap keyed by the filename.
-
-The example illustrates how you can create ConfigMaps from File using Generators.
-
-### File Input
-
-```yaml
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-configMapGenerator:
-- name: my-application-properties
-  files:
-  - application.properties
-
-```
-
-```yaml
-# application.properties
-FOO=Bar
-```
-
-### Build Output
-
-```yaml
-apiVersion: v1
-data:
-  application.properties: |-
-    FOO=Bar
-kind: ConfigMap
-metadata:
-  name: my-application-properties-f7mm6mhf59
-```
-
-## ConfigMap `from Literals`
-
-ConfigMap Resources may be generated from literal key-value pairs - such as `JAVA_HOME=/opt/java/jdk`.
-To generate a ConfigMap Resource from literal key-value pairs, add an entry to `configMapGenerator` with a
-list of `literals`.
-
-{{< alert color="success" title="Literal Syntax" >}}
-- The key/value are separated by a `=` sign (left side is the key)
-- The value of each literal will appear as a data item in the ConfigMap keyed by its key.
-{{< /alert >}}
-
-**Example:** Create a ConfigMap with 2 data items generated from literals.
-
-The example illustrates how you can create ConfigMaps from Literals using Generators.
-
-### File Input
-
-```yaml
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-configMapGenerator:
-- name: my-java-server-env-vars
-  literals:
-  - JAVA_HOME=/opt/java/jdk
-  - JAVA_TOOL_OPTIONS=-agentlib:hprof
-
-```
-
-### Build Output
-
-```yaml
-apiVersion: v1
-data:
-  JAVA_HOME: /opt/java/jdk
-  JAVA_TOOL_OPTIONS: -agentlib:hprof
-kind: ConfigMap
-metadata:
-  name: my-java-server-env-vars-44k658k8gk
-```
-
-## ConfigMap `from env file`
-
-ConfigMap Resources may be generated from key-value pairs much the same as using the literals option
-but taking the key-value pairs from an environment file. These generally end in `.env`.
-To generate a ConfigMap Resource from an environment file, add an entry to `configMapGenerator` with a
-single `envs` entry, e.g. `envs: [ 'config.env' ]`.
-
-{{< alert color="success" title="Environment File Syntax" >}}
-- The key/value pairs inside of the environment file are separated by a `=` sign (left side is the key)
-- The value of each line will appear as a data item in the ConfigMap keyed by its key.
-- Pairs may span a single line only.
-{{< /alert >}}
-
-**Example:** Create a ConfigMap with 3 data items generated from an environment file.
-
-### File Input
-
-```yaml
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-configMapGenerator:
-- name: tracing-options
-  envs:
-  - tracing.env
-```
-
-```bash
-# tracing.env
-ENABLE_TRACING=true
-SAMPLER_TYPE=probabilistic
-SAMPLER_PARAMETERS=0.1
-```
-
-### Build Output
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  # The name has had a suffix applied
-  name: tracing-options-6bh8gkdf7k
-# The data has been populated from each literal pair
-data:
-  ENABLE_TRACING: "true"
-  SAMPLER_TYPE: "probabilistic"
-  SAMPLER_PARAMETERS: "0.1"
-```
-
-## Overriding Base ConfigMap Values
-
-ConfigMap values from bases may be overridden by adding another generator for the ConfigMap
-in the overlay and specifying the `behavior` field.  `behavior` may be
-one of:
-* `create` (default value): used to create a new ConfigMap. A name conflict error will be thrown if a ConfigMap with the same name and namespace already exists.
-* `replace`: replace an existing ConfigMap from the base.
-* `merge`: add or update the values in an existing ConfigMap from the base.
-
-When updating an existing ConfigMap with the `merge` or `replace` strategies, you must ensure that both the name and namespace match the ConfigMap you're targeting. For example, if the namespace is unspecified in the base, you should not specify it in the overlay. Conversely, if it is specified in the base, you must specify it in the overlay as well. This is true even if the overlay Kustomization includes a namespace, because configMapGenerator runs before the namespace transformer.
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-namespace: my-new-namespace
-
-resources:
-- ../base
-
-configMapGenerator:
-  - name: existing-name
-    namespace: existing-ns # needs to match target ConfigMap from base
-    behavior: replace
-    literals:
-      - ENV=dev
-```
-
-{{< alert color="warning" title="Name suffixing with overlay configMapGenerator" >}}
-When using configMapGenerator to override values of an existing ConfigMap, the overlay configMapGenerator does not cause suffixing of the existing ConfigMap's name to occur. To take advantage of name suffixing, use configMapGenerator in the base, and the overlay generator will correctly update the suffix based on the new content. 
-{{< /alert >}}
-
-## Propagating the Name Suffix
-
-Workloads that reference the ConfigMap or Secret will need to know the name of the generated Resource,
-including the suffix. Kustomize takes care of this automatically by identifying
-references to generated ConfigMaps and Secrets, and updating them.
-
-In the following example, the generated ConfigMap name will be `my-java-server-env-vars` with a suffix unique to its contents.
-Changes to the contents will change the name suffix, resulting in the creation of a new ConfigMap,
-which Kustomize will transform Workloads to point to.
-
-The PodTemplate volume references the ConfigMap by the name specified in the generator (excluding the suffix).
-Kustomize will update the name to include the suffix applied to the ConfigMap name.
-
-**Input:** The kustomization.yaml and deployment.yaml files
-
-```yaml
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-configMapGenerator:
-- name: my-java-server-env-vars
-  literals:
-  - JAVA_HOME=/opt/java/jdk
-  - JAVA_TOOL_OPTIONS=-agentlib:hprof
-resources:
-- deployment.yaml
-```
-
-```yaml
-# deployment.yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: test-deployment
-  labels:
-    app: test
-spec:
-  selector:
-    matchLabels:
-      app: test
-  template:
-    metadata:
-      labels:
-        app: test
-    spec:
-      containers:
-      - name: container
-        image: registry.k8s.io/busybox
-        command: [ "/bin/sh", "-c", "ls /etc/config/" ]
-        volumeMounts:
-        - name: config-volume
-          mountPath: /etc/config
-      volumes:
-      - name: config-volume
-        configMap:
-          name: my-java-server-env-vars
-```
-
-**Result:** The output of the Kustomize build.
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  # The name has been updated to include the suffix
-  name: my-java-server-env-vars-k44mhd6h5f
-data:
-  JAVA_HOME: /opt/java/jdk
-  JAVA_TOOL_OPTIONS: -agentlib:hprof
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    app: test
-  name: test-deployment
-spec:
-  selector:
-    matchLabels:
-      app: test
-  template:
-    metadata:
-      labels:
-        app: test
-    spec:
-      containers:
-      - command:
-        - /bin/sh
-        - -c
-        - ls /etc/config/
-        image: registry.k8s.io/busybox
-        name: container
-        volumeMounts:
-        - mountPath: /etc/config
-          name: config-volume
-      volumes:
-      - configMap:
-          # The name has been updated to include the
-          # suffix matching the ConfigMap
-          name: my-java-server-env-vars-k44mhd6h5f
-        name: config-volume
-```
diff --git a/site/content/en/docs/Reference/API/Kustomization File/secretGenerator.md b/site/content/en/docs/Reference/API/Kustomization File/secretGenerator.md
index e06c8e2758..a111b8317d 100644
--- a/site/content/en/docs/Reference/API/Kustomization File/secretGenerator.md	
+++ b/site/content/en/docs/Reference/API/Kustomization File/secretGenerator.md	
@@ -10,86 +10,3 @@ description: >
 Each entry in the argument list results in the creation of one Secret resource (it's a generator of N secrets).
 
 This works like the [configMapGenerator](/docs/reference/api/kustomization-file/configmapgenerator).
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-
-secretGenerator:
-- name: app-tls
-  files:
-  - secret/tls.crt
-  - secret/tls.key
-  type: "kubernetes.io/tls"
-- name: app-tls-namespaced
-  # you can define a namespace to generate
-  # a secret in, defaults to: "default"
-  namespace: apps
-  files:
-  - tls.crt=catsecret/tls.crt
-  - tls.key=secret/tls.key
-  type: "kubernetes.io/tls"
-- name: env_file_secret
-  envs:
-  - env.txt
-  type: Opaque
-- name: secret-with-annotation
-  files:
-  - app-config.yaml
-  type: Opaque
-  options:
-    annotations:
-      app_config: "true"
-    labels:
-      app.kubernetes.io/name: "app2"
-```
-
-Secret Resources may be generated much like ConfigMaps can. This includes generating them
-from literals, files or environment files.
-
-{{< alert color="success" title="Secret Syntax" >}}
-Secret type is set using the `type` field.
-{{< /alert >}}
-
-## Example
-
-### File Input
-
-```yaml
-# kustomization.yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-secretGenerator:
-- name: app-tls
-  files:
-    - "tls.crt"
-    - "tls.key"
-  type: "kubernetes.io/tls"
-```
-
-```yaml
-# tls.crt
-LS0tLS1CRUd...tCg==
-```
-
-```yaml
-# tls.key
-LS0tLS1CRUd...0tLQo=
-```
-
-### Build Output
-
-```yaml
-apiVersion: v1
-data:
-  tls.crt: TFMwdExTMUNSVWQuLi50Q2c9PQ==
-  tls.key: TFMwdExTMUNSVWQuLi4wdExRbz0=
-kind: Secret
-metadata:
-  name: app-tls-c888dfbhf8
-type: kubernetes.io/tls
-```
-
-{{< alert color="warning" title="Important" >}}
-It is important to note that the secrets are `base64` encoded
-{{< /alert >}}
\ No newline at end of file
diff --git a/site/content/en/docs/Tasks/_index.md b/site/content/en/docs/Tasks/_index.md
index e78666fcd4..1e3c04c73c 100755
--- a/site/content/en/docs/Tasks/_index.md
+++ b/site/content/en/docs/Tasks/_index.md
@@ -1,25 +1,10 @@
-
 ---
-title: "Core Tasks"
-linkTitle: "Core Tasks"
+title: "Tasks"
+linkTitle: "Tasks"
 weight: 4
-date: 2017-01-05
+date: 2023-10-06
 description: >
-  What can your user do with your project?
+  Kustomize core tasks
 ---
 
-{{% pageinfo %}}
-This is a placeholder page that shows you how to use this template site.
-{{% /pageinfo %}}
-
-Think about your project’s features and use cases. Use these to choose your core tasks. Each granular use case (enable x, configure y) should have a corresponding tasks page or tasks page section. Users should be able to quickly refer to your core tasks when they need to find out how to do one specific thing, rather than having to look for the instructions in a bigger tutorial or example. Think of your tasks pages as a cookbook with different procedures your users can combine to create something more substantial.
-
-You can give each task a page, or you can group related tasks together in a page, such as tasks related to a particular feature. As well as grouping related tasks in single pages, you can also group task pages in nested folders with an index page as an overview, as seen in this example site. Or if you have a small docset like the [Docsy User Guide](https://docsy.dev/docs/) with no Tutorials or Concepts pages, consider adding your feature-specific pages at the top level of your docs rather than in a Tasks section. 
-
-Each task should give the user
-
-* The prerequisites for this task, if any (this can be specified at the top of a multi-task page if they're the same for all the page's tasks. "All these tasks assume that you understand....and that you have already....").
-* What this task accomplishes.
-* Instructions for the task. If it involves editing a file, running a command, or writing code, provide code-formatted example snippets to show the user what to do! If there are multiple steps, provide them as a numbered list.
-* If appropriate, links to related concept, tutorial, or example pages.
-
+This section of the Kustomize documentation contains pages that show how to do individual tasks. A task page shows how to do a single thing, typically by giving a short sequence of steps.
diff --git a/site/content/en/docs/Tasks/configmap_generator.md b/site/content/en/docs/Tasks/configmap_generator.md
new file mode 100644
index 0000000000..ccee3bedd4
--- /dev/null
+++ b/site/content/en/docs/Tasks/configmap_generator.md
@@ -0,0 +1,351 @@
+---
+title: "Generating ConfigMaps"
+linkTitle: "Generating ConfigMaps"
+weight: 1
+date: 2023-10-20
+description: >
+    Working with the ConfigMap Generator
+---
+
+ConfigMap objects can be generated by adding a [`configMapGenerator`] entry to the `kustomization.yaml` file.
+
+## Create ConfigMap from a file
+
+ConfigMap Resources may be generated from files - such as a java `.properties` file.  To generate a ConfigMap Resource for a file, add an entry to [`configMapGenerator`] with the filename.
+
+The ConfigMaps will have data values populated from the file contents. The contents of each file will appear as a single data item in the ConfigMap keyed by the filename.
+
+The following example generates a ConfigMap with a data item containing the contents of a file.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+configMapGenerator:
+- name: my-application-properties
+  files:
+  - application.properties
+```
+
+2. Create a `.properties` file.
+```yaml
+# application.properties
+FOO=Bar
+```
+
+3. Create the ConfigMap using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The output is similar to:
+```yaml
+apiVersion: v1
+data:
+  application.properties: |-
+    FOO=Bar
+kind: ConfigMap
+metadata:
+  name: my-application-properties-f7mm6mhf59
+```
+
+It is also possible to [define a key](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-the-key-to-use-when-creating-a-configmap-from-a-file) to set a name different than the filename.
+
+The example below creates a ConfigMap with the name of file as `myFileName.ini` while the _actual_ filename from which the configmap is created is `whatever.ini`.
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+configMapGenerator:
+- name: app-whatever
+  files:
+  - myFileName.ini=whatever.ini
+```
+
+
+## Create ConfigMap from literals
+
+ConfigMap Resources may be generated from literal key-value pairs - such as `JAVA_HOME=/opt/java/jdk`.
+To generate a ConfigMap Resource from literal key-value pairs, add an entry to [`configMapGenerator`] with a
+list of `literals`.
+
+{{< alert color="success" title="Literal Syntax" >}}
+- The key/value are separated by a `=` sign (left side is the key).
+- The value of each literal will appear as a data item in the ConfigMap keyed by its key.
+{{< /alert >}}
+
+The following example generates a ConfigMap with two data items generated from literals.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+configMapGenerator:
+- name: my-java-server-env-vars
+  literals:
+  - JAVA_HOME=/opt/java/jdk
+  - JAVA_TOOL_OPTIONS=-agentlib:hprof
+```
+
+2. Create the ConfigMap using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The output is similar to:
+```yaml
+apiVersion: v1
+data:
+  JAVA_HOME: /opt/java/jdk
+  JAVA_TOOL_OPTIONS: -agentlib:hprof
+kind: ConfigMap
+metadata:
+  name: my-java-server-env-vars-44k658k8gk
+```
+
+## Create ConfigMap from env file
+ConfigMap Resources may be generated from key-value pairs much the same as using the literals option
+but taking the key-value pairs from an environment file. These generally end in `.env`.
+To generate a ConfigMap Resource from an environment file, add an entry to [`configMapGenerator`] with a
+single `envs` entry, e.g. `envs: [ 'config.env' ]`.
+
+{{< alert color="success" title="Environment File Syntax" >}}
+- The key/value pairs inside of the environment file are separated by a `=` sign (left side is the key).
+- The value of each line will appear as a data item in the ConfigMap keyed by its key.
+- Pairs may span a single line only.
+{{< /alert >}}
+
+The following example generates a ConfigMap with three data items generated from an environment file.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+configMapGenerator:
+- name: tracing-options
+  envs:
+  - tracing.env
+```
+
+2. Create an environment file.
+```bash
+# tracing.env
+ENABLE_TRACING=true
+SAMPLER_TYPE=probabilistic
+SAMPLER_PARAMETERS=0.1
+```
+
+3. Create the ConfigMap using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The output is similar to:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  # The name has had a suffix applied
+  name: tracing-options-6bh8gkdf7k
+# The data has been populated from each literal pair
+data:
+  ENABLE_TRACING: "true"
+  SAMPLER_TYPE: "probabilistic"
+  SAMPLER_PARAMETERS: "0.1"
+```
+
+## Create ConfigMap with options
+The labels and annotations of a generated ConfigMap can be set with the `options` field. The name suffix hash can also be disabled.
+
+Labels and annotations added with `options` will not be overwritten by values defind in the `generatorOptions` field. Note that `disableNameSuffixHash: true` defined in `globalOptions` will override the locally defined `options`. This is a result of boolean behavior.
+
+The following example generates a ConfigMap with labels, annotations and does not add a suffix hash to the name.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+generatorOptions:
+  labels:
+    fruit: apple
+
+configMapGenerator:
+- name: my-java-server-env-vars
+  literals:
+  - JAVA_HOME=/opt/java/jdk
+  - JAVA_TOOL_OPTIONS=-agentlib:hprof
+  options:
+    disableNameSuffixHash: true
+    labels:
+      pet: dog
+    annotations:
+      dashboard: "1"
+```
+
+2. Create the ConfigMap using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The ConfigMap manifest is created with labels and annotations.
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: my-java-server-env-vars
+  labels:
+    fruit: apple
+    pet: dog
+  annotations:
+    dashboard: "1"
+data:
+  JAVA_HOME: /opt/java/jdk
+  JAVA_TOOL_OPTIONS: -agentlib:hprof
+```
+
+## Override base ConfigMap values
+ConfigMap values from bases may be overridden by adding another generator for the ConfigMap
+in the overlay and specifying the `behavior` field.
+
+`behavior` may be one of:
+* `create` (default value): used to create a new ConfigMap. A name conflict error will be thrown if a ConfigMap with the same name and namespace already exists.
+* `replace`: replace an existing ConfigMap from the base.
+* `merge`: add or update the values in an existing ConfigMap from the base.
+
+When updating an existing ConfigMap with the `merge` or `replace` strategies, you must ensure that both the name and namespace match the ConfigMap you are targeting. For example, if the namespace is unspecified in the base, you should not specify it in the overlay. Conversely, if it is specified in the base, you must specify it in the overlay as well. This is true even if the overlay Kustomization includes a namespace, because `configMapGenerator` runs before the namespace transformer.
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+namespace: my-new-namespace
+
+resources:
+- ../base
+
+configMapGenerator:
+  - name: existing-name
+    namespace: existing-ns # needs to match target ConfigMap from base
+    behavior: replace
+    literals:
+      - ENV=dev
+```
+
+{{< alert color="warning" title="Name suffixing with overlay configMapGenerator" >}}
+When using `configMapGenerator` to override values of an existing ConfigMap, the overlay `configMapGenerator` does not cause suffixing of the existing ConfigMap's name to occur. To take advantage of name suffixing, use `configMapGenerator` in the base, and the overlay generator will correctly update the suffix based on the new content.
+{{< /alert >}}
+
+
+## Propagate ConfigMap Name Suffix
+
+Workloads that reference the ConfigMap or Secret will need to know the name of the generated Resource,
+including the suffix. Kustomize takes care of this automatically by identifying
+references to generated ConfigMaps and Secrets, and updating them.
+
+In the following example, the generated ConfigMap name will be `my-java-server-env-vars` with a suffix unique to its contents. Changes to the contents will change the name suffix, resulting in the creation of a new ConfigMap, which Kustomize will transform Workloads to point to.
+
+The PodTemplate volume references the ConfigMap by the name specified in the generator (excluding the suffix). Kustomize will update the name to include the suffix applied to the ConfigMap name.
+
+The following example generates a ConfigMap and propagates the ConfigMap name, including the suffix, to a Deployment that mounts the ConfigMap.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+configMapGenerator:
+- name: my-java-server-env-vars
+  literals:
+  - JAVA_HOME=/opt/java/jdk
+  - JAVA_TOOL_OPTIONS=-agentlib:hprof
+resources:
+- deployment.yaml
+```
+
+2. Create a Deployment manifest.
+```yaml
+# deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: test-deployment
+  labels:
+    app: test
+spec:
+  selector:
+    matchLabels:
+      app: test
+  template:
+    metadata:
+      labels:
+        app: test
+    spec:
+      containers:
+      - name: container
+        image: registry.k8s.io/busybox
+        command: [ "/bin/sh", "-c", "ls /etc/config/" ]
+        volumeMounts:
+        - name: config-volume
+          mountPath: /etc/config
+      volumes:
+      - name: config-volume
+        configMap:
+          name: my-java-server-env-vars
+```
+
+3. Create the ConfigMap using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The output is similar to:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  # The name has been updated to include the suffix
+  name: my-java-server-env-vars-k44mhd6h5f
+data:
+  JAVA_HOME: /opt/java/jdk
+  JAVA_TOOL_OPTIONS: -agentlib:hprof
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: test
+  name: test-deployment
+spec:
+  selector:
+    matchLabels:
+      app: test
+  template:
+    metadata:
+      labels:
+        app: test
+    spec:
+      containers:
+      - command:
+        - /bin/sh
+        - -c
+        - ls /etc/config/
+        image: registry.k8s.io/busybox
+        name: container
+        volumeMounts:
+        - mountPath: /etc/config
+          name: config-volume
+      volumes:
+      - configMap:
+          # The name has been updated to include the
+          # suffix matching the ConfigMap
+          name: my-java-server-env-vars-k44mhd6h5f
+        name: config-volume
+```
+
+[`configMapGenerator`]: /docs/reference/api/kustomization-file/configmapgenerator/
diff --git a/site/content/en/docs/Tasks/configmaps_and_secrets.md b/site/content/en/docs/Tasks/configmaps_and_secrets.md
deleted file mode 100644
index a092e058c9..0000000000
--- a/site/content/en/docs/Tasks/configmaps_and_secrets.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "ConfigMaps and Secrets"
-linkTitle: "ConfigMaps and Secrets"
-weight: 3
-date: 2017-01-05
-description: >
-  Working with ConfigMaps and Secrets
----
\ No newline at end of file
diff --git a/site/content/en/docs/Tasks/labels_and_annotations.md b/site/content/en/docs/Tasks/labels_and_annotations.md
index 861f86b6e1..bb90b3e237 100644
--- a/site/content/en/docs/Tasks/labels_and_annotations.md
+++ b/site/content/en/docs/Tasks/labels_and_annotations.md
@@ -1,8 +1,8 @@
 ---
 title: "Labels and Annotations"
 linkTitle: "Labels and Annotations"
-weight: 2
+weight: 3
 date: 2017-01-05
 description: >
   Working with Labels and Annotations
----
\ No newline at end of file
+---
diff --git a/site/content/en/docs/Tasks/namespaces_and_names.md b/site/content/en/docs/Tasks/namespaces_and_names.md
index 6654eb4cce..572cd6d2b3 100644
--- a/site/content/en/docs/Tasks/namespaces_and_names.md
+++ b/site/content/en/docs/Tasks/namespaces_and_names.md
@@ -1,8 +1,8 @@
 ---
 title: "Namespaces and Names"
 linkTitle: "Namespaces and Names"
-weight: 1
-date: 2017-01-05
+weight: 4
+date: 2023-10-14
 description: >
   Working with Namespaces and Names
----
\ No newline at end of file
+---
diff --git a/site/content/en/docs/Tasks/secret_generator.md b/site/content/en/docs/Tasks/secret_generator.md
new file mode 100644
index 0000000000..83f2c6151d
--- /dev/null
+++ b/site/content/en/docs/Tasks/secret_generator.md
@@ -0,0 +1,158 @@
+---
+title: "Generating Secrets"
+linkTitle: "Generating Secrets"
+weight: 2
+date: 2023-10-20
+description: >
+    Working with the Secret Generator
+---
+
+Secret objects can be generated by adding a [`secretGenerator`] entry to the `kustomization.yaml` file. This is similar to the [`configMapGenerator`]. Secret Resources may be generated from files and literals. It is important to note that the secrets are base64 encoded.
+
+## Create Secret from a file
+
+To generate a Secret Resource from a file, add an entry to [`secretGenerator`] with the filename.
+
+The Secret will have data values populated from the file contents. The contents of each file will appear as a single data item in the Secret keyed by the filename.
+
+The following example generates a Secret with a data item containing the contents of a file.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+secretGenerator:
+- name: db-user-pass
+  files:
+  - credentials.txt
+```
+
+2. Create a `credentials.txt` file.
+```yaml
+# credentials.txt
+username=admin
+password=S!B\*d$zDsb=
+```
+
+3. Create the Secret using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The Secret manifest is generated.
+```yaml
+apiVersion: v1
+kind: Secret
+type: Opaque
+metadata:
+  name: db-user-pass-gf9bgh225c
+data:
+  credentials.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9UyFCXCpkJHpEc2I9Cg==
+```
+
+The credentials key value is base64 encoded.
+```bash
+echo "dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9UyFCXCpkJHpEc2I9Cg==" | base64 -d
+username=admin
+password=S!B\*d$zDsb=
+```
+
+## Create Secret from literals
+
+To generate a Secret Resource from literal key-value pairs, add an entry to [`secretGenerator`] with a
+list of `literals`.
+
+{{< alert color="success" title="Literal Syntax" >}}
+- The key/value are separated by a `=` sign (left side is the key).
+- The value of each literal will appear as a data item in the Secret keyed by its key.
+{{< /alert >}}
+
+The following example generates a Secret with two data items generated from literals.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+secretGenerator:
+- name: db-user-pass
+  literals:
+    - username=admin
+    - password=S!B\*d$zDsb=
+```
+
+2. Create the Secret using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The Secret manifest is generated.
+```yaml
+apiVersion: v1
+kind: Secret
+type: Opaque
+metadata:
+  name: db-user-pass-t8d2d65755
+data:
+  password: UyFCXCpkJHpEc2I9
+  username: YWRtaW4=
+```
+
+The credential key values are base64 encoded.
+```bash
+echo "UyFCXCpkJHpEc2I9" | base64 -d
+S!B\*d$zDsb=
+
+echo "YWRtaW4=" | base64 -d
+admin
+```
+
+## Create a TLS Secret
+
+The following example generates a TLS Secret with certificate and private key data files.
+
+1. Create a Kustomization file.
+```yaml
+# kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+secretGenerator:
+- name: app-tls
+  files:
+    - "tls.crt"
+    - "tls.key"
+  type: "kubernetes.io/tls"
+```
+
+2. Create a certificate file.
+```yaml
+# tls.crt
+LS0tLS1CRUd...tCg==
+```
+
+3. Create a private key file.
+```yaml
+# tls.key
+LS0tLS1CRUd...0tLQo=
+```
+
+4. Create the Secret using `kustomize build`.
+```bash
+kustomize build .
+```
+
+The Secret manifest is generated. The data key values are base64 encoded.
+```yaml
+apiVersion: v1
+kind: Secret
+type: kubernetes.io/tls
+metadata:
+  name: app-tls-c888dfbhf8
+data:
+  tls.crt: TFMwdExTMUNSVWQuLi50Q2c9PQ==
+  tls.key: TFMwdExTMUNSVWQuLi4wdExRbz0=
+```
+
+[`secretGenerator`]: /docs/reference/api/kustomization-file/secretgenerator/
+[`configMapGenerator`]: /docs/reference/api/kustomization-file/configmapgenerator/