the time to Secrets too. Besides the actual data encoding (which is Base64 for Secrets), there is no technical difference for the use of ConfigMaps and Secrets. Once a ConfigMap is created and holding data, we can use the keys of a ConfigMap in two ways: The file in a mounted ConfigMap volume is updated when the ConfigMap is updated via the Kubernetes API. So, if an application supports hot reload of configuration files, it can immediately benefit from such an update. However, with ConfigMap entries used as environment variables, updates are not reflected because environment variables can’t be changed after a process has been started. In addition to ConfigMap and Secret, another alternative is to store configuration directly in external volumes that are then mounted. The following examples concentrate on ConfigMap usage, but they can also be used for Secrets. There is one big difference, though: values for Secrets have to be Base64 encoded. A ConfigMap resource contains key-value pairs in its  data  section, as shown in Example 19-1. ConfigMaps can be accessed as environment variables and as a mounted file. We recommend using uppercase keys in the ConfigMap to indicate an EnvVar usage and proper filenames when used as mounted files. Example 19-1. ConfigMap resource apiVersion : v1 kind : ConfigMap metadata : name : random-generator-config data : PATTERN : Configuration Resource application.properties : | # Random Generator config log.file=/tmp/generator.log server.port=7070 EXTRA_OPTIONS : "high-secure,native" SEED : "432576345" 152  |  Chapter 19: Configuration Resource • As a reference for  environment variables , where the key is the name of the envi‐ ronment variable. • As  files  that are mapped to a volume mounted in a Pod. The key is used as the filename.