diff --git a/examples/configGeneration.md b/examples/configGeneration.md
index 40efd0329c..99a344dba3 100644
--- a/examples/configGeneration.md
+++ b/examples/configGeneration.md
@@ -21,11 +21,11 @@ Kustomize provides two ways of adding ConfigMap in one `kustomization`, either b
 
 The ConfigMaps declared as [resource] are treated the same way as other resources. Kustomize doesn't append any hash to the ConfigMap name. The ConfigMap declared from a ConfigMapGenerator is treated differently. A hash is appended to the name and any change in the ConfigMap will trigger a rolling update.
 
-In this demo, the same [hello_world](helloWorld/README.md) is used while the ConfigMap declared as [resources] is replaced by a ConfigMap declared from a ConfigmapGenerator. The change in this ConfigMap will result in a hash change and a rolling update.
+In this demo, the same [hello_world](helloWorld/README.md) is used while the ConfigMap declared as [resources] is replaced by a ConfigMap declared from a ConfigMapGenerator. The change in this ConfigMap will result in a hash change and a rolling update.
 
 ### Establish base and staging
 
-Establish the base with a configMapGenerator
+Establish the base with a `configMapGenerator`:
 <!-- @establishBase @test -->
 ```
 DEMO_HOME=$(mktemp -d)
@@ -85,7 +85,7 @@ EOF
 ### Review
 
 The _hello-world_ deployment running in this cluster is
-configured with data from a configMap.
+configured with data from a ConfigMap.
 
 The deployment refers to this map by name:
 
@@ -95,26 +95,26 @@ The deployment refers to this map by name:
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
 
-Changing the data held by a live configMap in a cluster
+Changing the data held by a live ConfigMap in a cluster
 is considered bad practice. Deployments have no means
-to know that the configMaps they refer to have
+to know that the ConfigMaps they refer to have
 changed, so such updates have no effect.
 
 The recommended way to change a deployment's
 configuration is to
 
- 1. create a new configMap with a new name,
+ 1. create a new ConfigMap with a new name,
  1. patch the _deployment_, modifying the name value of
     the appropriate `configMapKeyRef` field.
 
 This latter change initiates rolling update to the pods
-in the deployment.  The older configMap, when no longer
+in the deployment.  The older ConfigMap, when no longer
 referenced by any other resource, is eventually garbage
 collected.
 
 ### How this works with kustomize
 
-The _staging_ [variant] here has a configMap [patch]:
+The _staging_ [variant] here has a ConfigMap [patch]:
 
 <!-- @showMapPatch @test -->
 ```
@@ -125,7 +125,7 @@ This patch is by definition a named but not necessarily
 complete resource spec intended to modify a complete
 resource spec.
 
-The ConfigMap it modifies is declared from a configMapGenerator.
+The ConfigMap it modifies is declared from a `configMapGenerator`.
 
 <!-- @showMapBase @test -->
 ```
@@ -146,11 +146,11 @@ kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
 ```
 
-The configMap name is prefixed by _staging-_, per the
+The ConfigMap name is prefixed by _staging-_, per the
 `namePrefix` field in
 `$OVERLAYS/staging/kustomization.yaml`.
 
-The suffix to the configMap name is generated from a
+The suffix to the ConfigMap name is generated from a
 hash of the maps content - in this case the name suffix
 is _hhhhkfmgmk_:
 
@@ -174,7 +174,7 @@ kustomize build $OVERLAYS/staging |\
   grep -B 2 -A 3 kiwi
 ```
 
-Run kustomize again to see the new configMap names:
+Run kustomize again to see the new ConfigMap names:
 
 <!-- @grepStagingName @test -->
 ```
@@ -182,9 +182,9 @@ kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
 ```
 
-Confirm that the change in configMap content resulted
+Confirm that the change in ConfigMap content resulted
 in three new names ending in _khk45ktkd9_ - one in the
-configMap name itself, and two in the deployment that
+ConfigMap name itself, and two in the deployment that
 uses the map:
 
 <!-- @countHashes @test -->