diff --git a/examples/configGeneration.md b/examples/configGeneration.md
index b719c19b2..13f112cc5 100644
--- a/examples/configGeneration.md
+++ b/examples/configGeneration.md
@@ -23,14 +23,12 @@ 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 @testAgainstLatestRelease -->
-
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -92,7 +90,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:
 
@@ -102,26 +100,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](/../../issues/242).
 
 ### How this works with kustomize
 
-The _staging_ [variant] here has a configMap [patch]:
+The _staging_ [variant] here has a ConfigMap [patch]:
 
 <!-- @showMapPatch @testAgainstLatestRelease -->
 
@@ -133,7 +131,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 @testAgainstLatestRelease -->
 
@@ -156,15 +154,15 @@ 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 configMap name is suffixed by _-v1_, per the
+The ConfigMap name is suffixed by _-v1_, per the
 `nameSuffix` 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 _5276h4th55_:
 
@@ -190,7 +188,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 @testAgainstLatestRelease -->
 
@@ -199,9 +197,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 _c2g8fcbf88_ - 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 @testAgainstLatestRelease -->