Configuration and Storage Management solve the problem of how to give your applications the settings they need to run and the disk space they need to save files, without locking you into one machine or one environment. For the KCNA exam, you must understand how Kubernetes provides ConfigMaps, Secrets, Volumes, and PersistentVolumes to decouple configuration and storage from your application code, making your system portable and secure.
Jump to a section
A simple way to picture Configuration and Storage Management
When your company moves into a new office, the first thing you need is a kitchen so everyone can make coffee and store lunch.
Building separate mini-kitchens in every single cubicle would be a huge waste of space and money. Instead, you set up one shared kitchen with a big fridge, a cupboard for mugs, and a toaster. The fridge is your PersistentVolume: it stores food (data) even after you go home at night. The shelves in the cupboard act like a Volume: they give you temporary storage space during the day, but everything gets cleared out after closing time. Now, you also have a locked drawer for your personal snacks. That drawer is your Secret: it holds sensitive things (like your password to the coffee machine app). And the whiteboard on the wall that tells everyone how to adjust the thermostat is a ConfigMap: it stores non-sensitive setup instructions that everyone can read. Without these shared structures, you'd either starve (lose data) or waste resources (expensive empty spaces). This system lets you share resources intelligently while keeping your crisps safe.
So in Kubernetes, ConfigMaps and Secrets are like your whiteboard and locked drawer: they provide configuration and sensitive data separately. Volumes and PersistentVolumes are like temporary shelf space versus a long-term fridge: one lives and dies with your container, the other stays alive beyond it.
In Kubernetes, every application (or container) needs two basic things to work properly: a way to know its own settings, and a place to store data. Let's break down each piece.
First, think about configuration. When you install a new phone app, you usually go through a setup wizard where you enter your Wi-Fi password, language preference, and email address. Those details are your configuration. In the old way of doing things, developers would just hard-code these settings directly into the application's code. But that is a terrible idea for two reasons. First, if the Wi-Fi password changes, you have to rewrite the code. Second, if you want to use the same app in a different environment — say, a test version versus a live version — you need completely different settings. ConfigMap is Kubernetes' solution to this. A ConfigMap is an API object (a flexible resource you create using a command-line tool or a YAML file) that stores non-confidential configuration data as key-value pairs. Think of it as a settings file that lives outside your container. Your pod (the smallest deployable unit in Kubernetes, which runs one or more containers) can read these values as environment variables or as files on a special volume mount. This means you can change settings without rebuilding your container image. For example, you might have a ConfigMap with a key 'database-url' and a value 'http://test-db:5432' for testing, and a different ConfigMap with 'http://prod-db:5432' for production. You simply tell your pod which ConfigMap to use, and the settings appear automatically.
Second, there are Secrets. Secrets are almost identical to ConfigMaps in structure — they are also key-value pairs stored as API objects — but the values are secret. They are base64-encoded (a simple way to represent binary data as plain text, but not encryption; it is just obfuscation) by default, and you can optionally encrypt them at rest. Secrets hold things like database passwords, API tokens, or SSH keys. You never, ever want to put a real password into a YAML file that you commit to a source code repository (like GitHub). By using a Secret, you separate sensitive data from your application code. The pod requests the Secret, and Kubernetes delivers it — but only to authorised pods, and only to the specific namespace where the pod runs. Kubernetes also avoids writing Secrets to disk by default; it keeps them in memory only. This is a fundamental security practice.
Now let's move to storage. Containers are designed to be ephemeral: they start, they work, they crash, and they are replaced. Any data saved inside a container's own filesystem is destroyed when the container is removed. That is clearly unacceptable for any application that needs to keep user uploads, databases, or log files. Volumes solve this. A Volume in Kubernetes is a directory that is accessible to all containers within a pod and survives container restarts. However, a standard Volume does not survive pod deletion. If the pod is destroyed, the Volume is destroyed with it. There are many types of Volumes: emptyDir (a temporary empty directory that starts fresh with each pod), hostPath (which mounts a directory from the physical node's filesystem), and many others for specific cloud providers.
PersistentVolumes (PV) and PersistentVolumeClaims (PVC) take this further by decoupling storage from the pod lifecycle entirely. A PersistentVolume is a piece of storage in the cluster that has been provisioned by an administrator. Think of it as a reserved storage unit in a warehouse: it has a certain capacity (say, 100 GB) and a certain type of access mode (like 'ReadWriteOnce', meaning one pod can write to it, or 'ReadWriteMany', meaning many pods can read and write simultaneously). A Kubernetes cluster has a pool of these PersistentVolumes available. When a pod needs storage, it does not directly ask for a PV by name. Instead, it creates a PersistentVolumeClaim (PVC). A PVC is like a request form: 'I need 50 GB of fast storage that I can read and write from a single pod.' Kubernetes' control plane (the brain of the cluster, made of components like the API server and scheduler) looks at the pool of PVs, finds one that matches the request (size, access mode, speed), and binds the PVC to that PV. This process is called binding. Once bound, the pod can use the PVC as a volume. If the pod is deleted, the PVC still exists, and a new pod can claim the same PVC and access the same data. This is how stateful applications like databases persist data in Kubernetes. The administrator can also use StorageClass, which defines different 'tiers' of storage (for example, fast SSD storage versus slow HDD storage), and the PVC can request a specific StorageClass. This allows automated provisioning: if no PV matches, the cluster can create a new one dynamically using a provisioner (a plugin that talks to your cloud provider to spin up a new disk).
Why does all this matter? In the old world, you had a server, you configured it manually, and you stored files on its local hard drive. If the server failed, you lost everything. In cloud-native Kubernetes, you treat everything as disposable except your configuration and your data. ConfigMaps and Secrets make your containers stateless (they do not care which environment they run in). PVs and PVCs make your data persistent even if containers fly away. This design allows you to scale applications up and down automatically, move workloads across regions, and patch servers without downtime. The KCNA exam wants you to understand these objects, how they interact, and the security implications of each.
Make a ConfigMap
You create a YAML file or use 'kubectl create configmap' to store key-value pairs, like 'database-url: http://mydb:5432'. This keeps configuration separate from your container image.
Make a Secret
You create a YAML file with a 'kind: Secret' and encode the value with base64 (or use 'kubectl create secret generic') to store sensitive data like 'password: cHJldGVzdDEyMw=='.
Inject ConfigMap/Secret into a pod
In the pod's deployment YAML, add a 'containers.env' section that references the ConfigMap key, or add a 'volumes' section to mount the Secret as a file. This makes the configuration available to the container.
Create a PersistentVolume claim
Write a PVC YAML requesting storage (e.g., 10 GB, ReadWriteOnce). Kubernetes will try to bind it to an existing PV that matches, or trigger dynamic provisioning if a StorageClass is specified.
Mount the PersistentVolume claim to a pod
In the pod spec under 'volumes', reference the PVC by name, then mount it to a path inside the container (e.g., '/data'). The pod can now read and write data that persists beyond the pod's lifetime.
Check binding status
Use 'kubectl get pvc' to see if the PVC is 'Bound' or 'Pending'. If 'Pending', check 'kubectl describe pvc' to see why no matching PV was found.
Imagine you work for an online retail company that sells custom-printed T-shirts. You have a Kubernetes cluster running in two different cloud regions (one in Europe, one in the US) for resilience. Your core application has three parts: a web front-end that shows the catalogue, a backend API that handles orders, and a database that stores customer profiles and order history.
Step 1: Configuring the application. You do not want to build a separate container image for the European region and another for the US. The only difference is the URL of the payment gateway (one for Europe, one for the US) and the chosen language for the front-end. You create two ConfigMaps: one called 'europe-config' and one called 'us-config'. Each ConfigMap has keys like 'payment-api-url' and 'language'. Your deployment YAML file references the correct ConfigMap based on the region. This is a one-line change in the deployment manifest. If the payment gateway changes, you update the ConfigMap and restart the pods. No container rebuilds, no new images.
Step 2: Storing secrets securely. Your backend API needs a password to connect to the database. You create a Secret called 'db-password' with a key 'password' and a base64-encoded value. You also store the API key for your payment provider in a separate Secret called 'payment-api-key'. These Secrets are created in a namespace that only the backend team has access to, enforced by RBAC (Role-Based Access Control). The deployment for the backend API mounts this Secret as an environment variable. Internally, engineers never see the real password in logs or code repositories.
Step 3: Handling persistent data. The database for customer profiles is a PostgreSQL database running in a single pod (for this example, though in production you would use a StatefulSet). This pod needs permanent storage so that if the pod crashes and Kubernetes reschedules it to another node, the data is not lost. You create a PVC called 'postgres-data' requesting 500 GB of fast SSD storage with a ReadWriteOnce access mode. The cluster automatically provisions a matching PV from your cloud provider's SSD tier. When the database pod starts, it uses this PVC. The pod writes all its data to that PVC.
Step 4: Handling temporary data. Your web front-end generates temporary cached images of T-shirt designs. These are not critical and do not need to survive pod restarts. You use an emptyDir Volume for this cache. It is fast and local to the node. When the pod is deleted, the cache disappears. This saves you from paying for expensive persistent storage for disposable data.
Step 5: Scaling and failure scenarios. One day, the database pod's node fails. Kubernetes reschedules the database pod onto a different node. Because the PVC is bound to a PV that exists independently on the network storage, the new pod simply mounts the same PV and continues working exactly where it left off. The customers do not notice a disruption. Meanwhile, the web front-end pods have replicas in both regions. When traffic spikes, you increase the replica count from 3 to 10. Each new pod reads the same ConfigMap and Secret, so they all behave identically. The new pods use emptyDir Volumes for their caches, so no coordination is needed between them.
What does the IT professional do concretely? They write YAML files defining ConfigMaps, Secrets, PVCs, and StorageClasses. They use kubectl (the Kubernetes command-line tool) to create, update, and examine these objects. They monitor PVC binding status with 'kubectl get pvc'. They rotate Secrets by creating a new version and updating the deployment to reference the new Secret name. They troubleshoot a pod that fails to start because it cannot find a ConfigMap or because its PVC is still pending. They set up backups for PVs using volume snapshots. They choose appropriate access modes for PVs based on whether multiple pods need simultaneous write access. They design storage classes to match cost and performance requirements: cheap spinning disks for logs, fast SSDs for databases, and so on.
The KCNA exam will expect you to know the difference between a Volume and a PersistentVolume. A Volume lives and dies with the pod. A PersistentVolume lives beyond the pod. Even beginners need to grasp that the standard Volume that comes with every pod (like the container's own filesystem) is not persistent. This is a common mistake. The exam also tests the concept of 'decoupling' storage and configuration from the application lifecycle. Real-world engineers use this daily to achieve zero-downtime deployments, multi-environment setups, and compliance with security standards.
The KCNA exam tests your ability to distinguish between the four key storage and configuration objects and to understand how they interact. Here is exactly what you need to know.
First, exam questions will ask you to match each object to its purpose. You must know:
ConfigMap: stores non-sensitive configuration data like URLs, feature flags, environment names.
Secret: stores sensitive data like passwords, tokens, SSH keys, but is structurally similar to ConfigMap.
Volume: provides ephemeral storage scoped to the pod's lifetime. Common types are emptyDir (for scratch data) and hostPath (for node-specific data).
PersistentVolume: cluster-wide storage resource that exists independently of pods, provisioned by an administrator or dynamically via StorageClass.
PersistentVolumeClaim: a request for storage made by a pod that binds to a matching PV.
Second, questions will test the security difference between ConfigMap and Secret. Traps include: 'Which object is encrypted by default?' The answer is that Secrets are base64-encoded but not encrypted by default (unless you enable encryption at rest). Beginners often assume Secrets are automatically encrypted; they are not. The exam also tests that ConfigMap data is stored in plain text in etcd (the cluster's key-value store). Another trap: 'Can you store a password in a ConfigMap?' Technically yes, but do not, because it is not designed for secrets. The correct answer is to use a Secret.
Third, storage lifecycle questions appear frequently. You will be asked: 'What happens to data in an emptyDir Volume when the pod is deleted?' Answer: the data is lost forever. 'What happens to data in a PersistentVolume when the pod is deleted?' Answer: the data remains available because the PV is independent. The exam can also ask: 'What happens if a PVC requests 100 GB but no PV of that size exists?' Answer: the PVC remains in a 'Pending' state until a matching PV is created or a provisioner creates one dynamically.
Fourth, access modes are a specific exam focus. You must remember the three standard access modes:
- ReadWriteOnce (RWO): only one node (or one pod on a node) can mount the volume as read-write. - ReadOnlyMany (ROX): many nodes can mount the volume as read-only. - ReadWriteMany (RWX): many nodes can mount the volume as read-write. The exam loves to test whether you know that RWO is the default for most cloud providers and that not every volume type supports RWX (e.g., standard AWS EBS volumes only support RWO).
Fifth, the concept of static versus dynamic provisioning is tested. Static: an admin creates PVs manually. Dynamic: a PVC references a StorageClass, and a provisioner automatically creates a PV. The exam may ask: 'What StorageClass property makes dynamic provisioning possible?' The answer is the 'provisioner' field in the StorageClass definition.
Sixth, the exam sometimes presents a scenario where a pod cannot start because of a missing ConfigureMap or Secret. You need to diagnose that the pod's 'Pending' status is due to a missing object. The correct answer is to check 'kubectl describe pod [pod-name]' and look for events like 'Error: configmap not found'.
Finally, be aware of the difference between environment variables and volume mounts for ConfigMaps and Secrets. A ConfigMap can be injected as environment variables (which are set at pod creation and cannot change during the pod's life) or as a volume mount (where files are updated automatically if the ConfigMap changes). The exam may ask which method supports live updates. The answer is volume mounts, because the kernel polls the file for changes. Environment variables are static.
To memorise: think of the lifecycle rule — ConfigMap and Secret are externalised settings that live in the cluster; Volume is temporary storage attached to a pod; PersistentVolume is permanent storage independent of the pod. Understand which objects survive what event. That is 90% of the exam content on this objective.
ConfigMaps store non-sensitive configuration data as key-value pairs, while Secrets store sensitive data like passwords and API tokens, and both live outside the container image.
A standard Volume is ephemeral and is deleted when the pod is removed, whereas a PersistentVolume survives pod deletion and is managed independently.
A PersistentVolumeClaim is a request for storage that must bind to a matching PersistentVolume before it can be used by a pod.
Secrets are base64-encoded, not encrypted by default; enable encryption at rest in etcd for real security.
If a ConfigMap or Secret is injected as an environment variable, changes require pod recreation; if mounted as a volume, file updates are live but the application must watch for them.
The three standard access modes for PersistentVolumes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), and ReadWriteMany (RWX), and not all storage types support every mode.
These come up on the exam all the time. Here's how to tell them apart.
ConfigMap
Stores non-sensitive data like URLs, feature flags, environment names.
Data is in plain text in etcd by default.
Can be updated and referenced in pods as env vars or volume mounts.
Secret
Stores sensitive data like passwords, API tokens, SSH keys.
Data is base64-encoded by default (not encrypted) but can be encrypted at rest.
Same injection methods as ConfigMap, but recommended for secrets only.
Volume
Ephemeral: data lives as long as the pod, deleted with it or on node failure.
Created inline in a pod spec (e.g., emptyDir, hostPath).
No independent lifecycle; tightly coupled to the pod.
PersistentVolume
Persistent: data survives pod deletion and node failures.
Provisioned by administrator or dynamically via StorageClass, exists independently.
Accessed via a PersistentVolumeClaim, binds to a PV.
Environment Variable Injection
ConfigMap/Secret values are set as environment variables at pod start.
Changes to the ConfigMap/Secret do not update running pods.
Best for static configuration that rarely changes.
Volume Mount Injection
ConfigMap/Secret is mounted as a file system directory inside the container.
If the ConfigMap/Secret is updated, the files update automatically (application must watch for updates).
Best for configuration that changes frequently or needs to be watched for updates.
Static Provisioning
Administrator manually creates PersistentVolume objects beforehand.
Cluster has a fixed pool of PVs; PVC binds to one that matches.
Requires planning and manual management of storage resources.
Dynamic Provisioning
Uses a StorageClass with a provisioner (e.g., cloud provider plugin).
No pre-created PVs; the provisioner creates a PV automatically when a PVC is created.
More flexible and automated; scales with demand.
Mistake
Secrets are automatically encrypted at rest in Kubernetes.
Correct
By default, Secrets are only base64-encoded (not encrypted) and stored in plain text in etcd unless you explicitly enable encryption at rest via a configuration flag.
The word 'Secret' implies encryption, so beginners assume Kubernetes handles it automatically. The base64 encoding looks like garbled text, which feels secure, but it can be decoded instantly.
Mistake
A PersistentVolumeClaim creates permanent storage that is immediately available to any pod.
Correct
A PVC must first be bound to a matching PersistentVolume before it can be used. The binding process may take time, and if no PV matches, the PVC remains 'Pending'.
People think claims are like a cloud volume that spins up instantly and is globally available. They forget the binding step and the need for a matching PV or StorageClass.
Mistake
ConfigMaps and Secrets can be updated while a pod is running and the new values take effect automatically.
Correct
If ConfigMaps or Secrets are injected as environment variables, the change only applies to newly created pods. Only if they are mounted as volumes do the files update live, but the application must watch for file changes.
The term 'update' implies universal live reload. Beginners do not differentiate between different injection methods (env vars vs. volume mounts).
Mistake
A hostPath Volume is safe to use in a multi-node cluster for data that must persist.
Correct
hostPath mounts a directory from the node's filesystem. If the pod moves to a different node, the data is left behind on the old node, so it is not persistent across node failures.
The word 'host' suggests something stable and permanent, but the host (the node) can change. Beginners confuse hostPath with node-level persistence, not realising it is node-specific.
Mistake
You can store any kind of configuration data in ConfigMaps, including binary files larger than 1 MB.
Correct
ConfigMaps are limited to storing key-value pairs where the value is a string or byte sequence, and the total data size is limited (typically 1 MB in etcd). Binary files over 1 MB should be stored as separate objects or in a Volume.
Beginners think of ConfigMaps as a general-purpose configuration dump without size or format constraints, because the term 'configuration' implies no limits.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Both store key-value pairs, but ConfigMaps are for non-sensitive data (like URLs), while Secrets are for sensitive data (like passwords). Secrets are base64-encoded by default and have better security defaults.
No, a PersistentVolume is independent of the pod's lifecycle. Even if the pod is deleted, the PV remains and can be claimed by a new pod, as long as the PVC is not deleted.
If you inject the ConfigMap as a volume mount, the file will update automatically (the application must watch for changes). If you inject it as environment variables, you must delete and recreate the pod.
Technically yes, but it is a security risk because ConfigMap data is stored in plain text in etcd. Always use a Secret for passwords, tokens, or any sensitive information.
It means the PVC has not yet been bound to a PersistentVolume. This usually happens because there is no existing PV that matches the requested size, access mode, or storage class, or because no dynamic provisioner is available.
Use ReadWriteOnce (RWO). This allows only one node (or one pod on a node) to mount the volume as read-write, which is typical for single-instance databases like PostgreSQL.
You've finished Configuration and Storage Management. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?