9. Configuration, Secrets and Persistent Storage

Introduction: State in an Otherwise Ephemeral Platform

Containers are deliberately replaceable. A container image should be immutable, and a failed container should normally be recreated rather than repaired. This design provides consistency and rapid recovery, but it creates an important architectural question: where should configuration, credentials, and durable application data live?

Kubernetes answers this question through several related abstractions. ConfigMaps hold non-confidential configuration; Secrets represent sensitive values; PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) provide durable storage; and StorageClasses together with the Container Storage Interface (CSI) enable automated provisioning. These mechanisms allow an application to remain stateless at the container layer while preserving the state that must survive restarts, rescheduling, upgrades, and failures.

The distinction between configuration, secret material, and application data is more than a matter of object type. Each category has different confidentiality, integrity, availability, lifecycle, ownership, backup, and compliance requirements. A database password may need strict access controls and rotation. A feature flag may require rapid versioning and rollout. A customer database may require replication, point-in-time recovery, and geographically separate backups. Treating all three simply as “files mounted into a container” leads to weak design.

This chapter develops a practical and analytical framework for managing these concerns in Kubernetes. It explains the Kubernetes object model, storage provisioning, encryption, external secret systems, stateful workload design, protection of data, and the organizational decisions required to operate these capabilities responsibly.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Distinguish configuration, secrets, ephemeral data, and persistent application state.

2. Create and consume ConfigMaps and Secrets using environment variables and mounted volumes.

3. Explain the security limitations of ordinary Kubernetes Secrets and the role of encryption at rest.

4. Evaluate native, external, and cloud-integrated secret-management approaches.

5. Describe PVs, PVCs, StorageClasses, CSI drivers, access modes, reclaim policies, and dynamic provisioning.

6. Select an appropriate storage design for stateful workloads.

7. Design backup, restoration, recovery, and data-protection processes.

8. Identify common operational, security, governance, and compliance risks.

9. Apply these concepts to a realistic Kubernetes migration and architecture decision.

The Configuration–Secret–State Model

A useful design model classifies information according to both sensitivity and persistence.

Configuration determines how software behaves but is not normally confidential. Examples include a service endpoint, logging level, cache duration, or feature flag. Configuration should be versioned, reviewable, and deployable independently where appropriate.

Secrets are values whose disclosure could damage confidentiality, integrity, or availability. Examples include database passwords, API tokens, private keys, and TLS certificates. A secret is not merely a configuration value with a different file extension; it requires stronger access control, auditing, rotation, and handling procedures.

Ephemeral state is temporary data that can be discarded without violating business requirements. Examples include a local cache, a transient work directory, or an intermediate build artifact. Such data may use a container filesystem or an `emptyDir` volume.

Persistent state must survive container replacement and usually node failure. Examples include database files, uploaded documents, message queues, and transaction logs. Persistent state requires a storage system, recovery policy, integrity controls, capacity management, and an identified owner.

A second distinction concerns the source of truth. Kubernetes should not automatically become the authoritative system for every kind of data. A Git repository may be the source of truth for non-sensitive configuration; a dedicated secrets manager may own credentials; and a managed database or storage service may own business data. Kubernetes often acts as a delivery and consumption plane rather than the ultimate repository.

ConfigMaps: Delivering Non-Confidential Configuration

A ConfigMap is a Kubernetes object containing key-value configuration data. It may be created declaratively or generated from files and literals. For example:

```yaml

apiVersion: v1

kind: ConfigMap

metadata:

name: orders-config

namespace: commerce

data:

LOG_LEVEL: "info"

CACHE_TTL_SECONDS: "300"

application.yaml: |

orders:

timeout: 2s

retryLimit: 3

```

A Pod can consume these values as environment variables:

```yaml

envFrom:

• configMapRef:

name: orders-config

```

or selectively:

```yaml

env:

• name: LOG_LEVEL

valueFrom:

configMapKeyRef:

name: orders-config

key: LOG_LEVEL

```

It can also mount the data as files:

```yaml

volumes:

• name: configuration

configMap:

name: orders-config

containers:

• name: orders

image: example/orders:2.4

volumeMounts:

• name: configuration

mountPath: /etc/orders

readOnly: true

```

The choice between environment variables and files depends on application behavior. Environment variables are convenient and widely supported, but many applications read them only at startup. Mounted ConfigMap files can be updated by Kubernetes, although applications must detect and reload changes; Kubernetes does not automatically reconfigure an application that has already read its settings. A `subPath` mount generally does not receive subsequent updates, which is an important operational detail.

ConfigMaps are not intended for confidential data. Base64 encoding, sometimes seen in YAML manifests, is not encryption. Configuration should be validated before deployment, and a change-management process should establish whether updates require a rolling restart, an explicit reload, or no restart at all.

Secrets: Representation Is Not Protection

A Kubernetes Secret stores data such as passwords, tokens, keys, and certificates. The common manifest representation uses base64 encoding:

```yaml

apiVersion: v1

kind: Secret

metadata:

name: orders-db

namespace: commerce

type: Opaque

data:

username: b3JkZXJz

password: Y2hhbmdlLW1l

```

The encoded values are easily reversible. Therefore, the existence of a Secret object does not, by itself, mean that the value is protected from administrators, backups, compromised control-plane components, or users with excessive RBAC permissions.

Secrets may be consumed as environment variables or mounted files:

```yaml

env:

• name: DB_PASSWORD

valueFrom:

secretKeyRef:

name: orders-db

key: password

```

A file-based approach is often preferable for certificates, private keys, and applications that support file permissions or rotation. Secret volumes are presented to the container through an in-memory mechanism on many platforms, but applications must still avoid logging their contents or copying them into less protected locations.

Secret types provide semantic guidance. `kubernetes.io/tls` is commonly used for TLS certificates and private keys; `kubernetes.io/dockerconfigjson` can hold registry authentication; and `Opaque` is used for generic data. The type does not substitute for access control.

Secret security controls

A mature secret design combines several controls:

• Least-privilege RBAC: permit a workload to read only the specific Secret objects it requires.
• Namespace and service-account boundaries: do not give a general-purpose service account broad access to all secrets.
• Encryption at rest: configure the API server or managed Kubernetes service to encrypt stored Secret data in the backing data store.
• Transport protection: use authenticated and encrypted communication to the API server and external secret providers.
• Audit logging: record access and administrative changes without recording secret values.
• Rotation: replace credentials on a defined schedule and after suspected exposure.
• Redaction: prevent values from appearing in logs, command histories, crash dumps, images, manifests, and support tickets.
• Admission and policy controls: reject risky manifests, such as secrets embedded in container images or workloads using unapproved service accounts.

Encryption at rest typically uses an envelope model: data is encrypted with a data-encryption key, while that key is protected by a key-encryption key managed by a key-management service or equivalent mechanism. Key rotation and recovery procedures must be designed together; encryption that cannot be restored during an incident is an availability failure.

External Secret Systems and the Separation of Duties

For small environments, Kubernetes Secrets may be adequate when encryption, RBAC, audit, and rotation are properly implemented. Larger or regulated organizations often place authoritative secrets in systems such as a cloud secret manager, HashiCorp Vault, or another enterprise key-management platform. These systems commonly provide centralized policy, dynamic credentials, leasing, automatic rotation, approval workflows, and detailed audit trails.

Three integration patterns are common.

1. Synchronizing operator pattern: an operator watches a custom resource and creates or updates a Kubernetes Secret from an external provider. Applications continue to consume ordinary Kubernetes Secrets.

2. Direct injection pattern: an agent, sidecar, CSI provider, or admission mechanism retrieves secret material at Pod startup or during its lifetime and presents it to the application.

3. Application retrieval pattern: the application authenticates directly to the external system and obtains credentials through an API.

Each pattern has trade-offs. Synchronization is compatible with existing applications but creates a copy in Kubernetes. Direct injection may reduce persistence in the cluster but adds runtime dependencies. Application retrieval provides flexibility but requires application changes and careful identity design.

Workload identity is preferable to long-lived static credentials. The Pod should authenticate through a platform identity, such as a cloud workload identity or a Kubernetes service-account federation mechanism, and receive only the permissions needed for its role. The security boundary should therefore be based on workload identity, namespace, environment, and resource—not on a shared password distributed to many Pods.

External secret systems also create availability dependencies. If an application needs a secret only at startup, temporary provider unavailability may prevent new replicas from launching. If it retrieves secrets continuously, provider outages may affect running workloads. This requires explicit decisions about caching, startup behavior, failover, and emergency access.

Persistent Storage as a Layered Architecture

Kubernetes persistent storage is best understood as a relationship among four layers:

1. The application requests storage through a PersistentVolumeClaim.

2. A PersistentVolume represents an allocated storage resource.

3. A StorageClass describes how suitable storage should be provisioned.

4. A CSI driver translates Kubernetes storage operations into the APIs of a storage platform.

A PVC expresses a consumer’s requirements without requiring the application team to know the details of the underlying disk or storage array:

```yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: orders-data

namespace: commerce

spec:

accessModes:

• ReadWriteOnce

resources:

requests:

storage: 100Gi

storageClassName: fast-ssd

```

A StorageClass may support dynamic provisioning:

```yaml

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: fast-ssd

provisioner: csi.example.com

reclaimPolicy: Delete

volumeBindingMode: WaitForFirstConsumer

allowVolumeExpansion: true

parameters:

tier: performance

```

When a Pod uses the PVC, the CSI driver can create the corresponding storage resource. This is dynamic provisioning. By contrast, an administrator may create a PV manually for an existing or specially controlled storage resource; this is static provisioning.

CSI and storage operations

The Container Storage Interface standardizes how storage vendors integrate with container orchestration platforms. A CSI driver may implement operations such as creating and deleting volumes, attaching them to nodes, mounting them into Pods, expanding capacity, and taking snapshots. The driver usually consists of controller and node components, often deployed by a vendor or platform team.

CSI improves portability of the Kubernetes storage model, but it does not make all storage systems equivalent. Performance, failure behavior, snapshot consistency, encryption, topology, and access semantics remain provider-specific. A driver must be evaluated as part of the complete data-protection architecture rather than selected solely because it supports the CSI label.

Access modes and topology

Access modes describe how a volume may be mounted, but their exact availability depends on the storage implementation. Common modes include:

• ReadWriteOnce (RWO): read-write mounting by a single node.
• ReadOnlyMany (ROX): read-only mounting by multiple nodes.
• ReadWriteMany (RWX): read-write mounting by multiple nodes.
• ReadWriteOncePod (RWOP): read-write mounting by a single Pod, where supported.

RWO does not necessarily mean only one Pod can ever use the volume; it primarily describes node-level attachment semantics. Applications requiring concurrent writers need storage and filesystem behavior that genuinely supports that access pattern. A replicated database should not be made active-active merely because a volume offers RWX.

Storage topology matters in zonal or regional clusters. A volume may be attached only within a particular failure domain. `WaitForFirstConsumer` allows scheduling information to influence volume provisioning, reducing the risk that a volume is created in a location where the eventual Pod cannot run. Storage design must therefore consider node labels, zones, anti-affinity, and failure domains.

Reclaim policies and lifecycle

A PV commonly has a reclaim policy of `Delete` or `Retain`. `Delete` removes the underlying storage when the claim is released, which is convenient for disposable environments but dangerous for valuable data. `Retain` preserves the volume for deliberate recovery or reassignment but requires operational cleanup and secure handling. The policy should reflect data classification and recovery requirements, not merely administrator convenience.

The lifecycle of a PVC is independent from the lifecycle of a Pod. Deleting a Deployment does not necessarily delete its claim. This is valuable for recovery, but it can also create abandoned volumes and continuing costs. Organizations should monitor claims, ownership, age, utilization, and deletion events.

Stateful Workloads and Design Choices

A stateful application is not simply a Deployment with a PVC. It has identity, ordering, durable data, recovery semantics, or membership behavior that must be preserved. Kubernetes provides the StatefulSet controller for workloads in which stable network identity and per-replica storage are important:

```yaml

volumeClaimTemplates:

• metadata:

name: data

spec:

accessModes: ["ReadWriteOnce"]

storageClassName: fast-ssd

resources:

requests:

storage: 200Gi

```

Each replica can receive a distinct claim, such as `data-database-0`. This supports a model in which each database member owns its storage. StatefulSet, however, does not turn an ordinary process into a reliable distributed database. Replication protocols, quorum, fencing, leader election, consistency, failover, and backup remain application responsibilities.

At the architectural level, teams should choose among three strategies:

1. Managed stateful service: use a cloud or enterprise database service when operational maturity, reliability, and support are more important than infrastructure control.

2. Operator-managed stateful workload: use a database operator that understands clustering, upgrades, backups, and failover.

3. Self-managed StatefulSet: appropriate when the team has strong storage, database, and Kubernetes expertise and accepts the operational burden.

A stateful design should answer: What is the unit of failure? How is data replicated? What happens if a node, zone, storage system, or control plane fails? Can a new replica reconstruct itself? What is the recovery point objective (RPO), and what is the recovery time objective (RTO)? How are schema changes coordinated with application deployment? Who owns restoration testing?

Data Protection: Backups, Snapshots and Recovery

High availability is not backup. Replication can copy accidental deletion, corruption, ransomware, or an invalid schema migration to every replica. Data protection therefore requires independent recovery mechanisms.

A sound protection strategy may include:

• application-consistent database backups;
• CSI volume snapshots where supported;
• export of critical object metadata and configuration;
• geographically or administratively separate backup copies;
• encryption in transit and at rest;
• retention rules aligned with legal and business requirements;
• documented restoration procedures;
• periodic recovery exercises.

A storage snapshot is usually fast and space-efficient, but it may not be application-consistent unless coordinated with the database. A filesystem snapshot taken during an in-flight transaction may produce a technically valid but logically inconsistent result. Database-native backups, write-ahead-log archiving, quiescing, or operator-supported backup workflows may be required.

Recovery should be tested rather than inferred from successful backup jobs. A meaningful test restores data into an isolated environment, verifies integrity, measures elapsed time, and confirms that the application can use the restored data. Backup monitoring should check not only whether a job ran, but whether the resulting artifact is complete, retrievable, within retention, and restorable.

An Illustrative Case: Migrating an Order Platform

Background

A fictional retailer, Northstar Commerce, operates an order platform in virtual machines. The platform includes a stateless API, a PostgreSQL database, a document-upload service, and a reporting worker. The organization is migrating the platform to a managed Kubernetes cluster to improve deployment frequency and standardize operations across environments.

Situation and problem

The initial migration plan places database passwords in Git-managed YAML, stores uploaded documents on container filesystems, and runs PostgreSQL as a three-replica Deployment using one shared network volume. The plan appears simple but creates several risks: credentials may be exposed in repository history, uploaded documents disappear when Pods are recreated, and database replicas may concurrently write to storage without a valid replication design. The organization also has an RPO of fifteen minutes and an RTO of two hours for orders.

Analysis

The API configuration is mostly non-confidential and can be represented through a ConfigMap. Database credentials and payment-provider tokens are secrets and should be sourced from an external secret manager through workload identity. Uploaded documents are durable business data and require object storage with versioning and lifecycle controls, rather than a local container filesystem. PostgreSQL requires either a managed database or a PostgreSQL operator with a well-understood replication and backup model.

The existing shared-volume design confuses storage access with database replication. RWX access would not make independent PostgreSQL processes safe. The platform team also discovers that a `Delete` reclaim policy is used by the default StorageClass, which is unsuitable for production database claims.

Approach and solution

Northstar adopts the following design:

• API settings are delivered through a versioned ConfigMap and validated during deployment.
• Database and payment credentials are stored in an enterprise secret manager. An external-secrets integration synchronizes only the required values, with namespace-scoped RBAC and rotation procedures.
• The API uses object storage for uploaded documents and stores document metadata in PostgreSQL.
• PostgreSQL is initially moved to a managed service. If it is later operated in Kubernetes, an approved database operator and dedicated StorageClass will be required.
• Production database storage uses encrypted SSD-backed volumes, topology-aware provisioning, and a `Retain` policy.
• Backups include frequent database backups and transaction-log archiving, with copies in a separate account or region.
• Restoration is tested quarterly, and the measured recovery process is documented in the incident runbook.
• Admission policies reject manifests containing known secret patterns and require approved service accounts and StorageClasses.

Outcome

The migration separates deployment configuration from credential management and separates application data from container lifecycle. The API can scale horizontally without sharing local state. The database has a defined recovery architecture rather than merely multiple replicas. The organization also gains ownership records for claims, backup schedules, secret rotation, and restoration testing.

Learning points

The principal lesson is that Kubernetes objects are mechanisms, not complete operating models. A ConfigMap does not provide configuration governance; a Secret does not guarantee confidentiality; a PVC does not guarantee backup; and a StatefulSet does not create database correctness. Reliable architecture emerges only when resource definitions are combined with identity, policy, storage capabilities, operational procedures, and tested recovery.

Risks, Limitations and Common Mistakes

Several errors recur in production environments. Storing plaintext or base64-encoded credentials in Git creates a persistent exposure even after a later correction. Granting a service account permission to read all Secrets in a namespace magnifies the impact of one compromised Pod. Injecting secrets as environment variables can expose them through diagnostic output or process inspection. Assuming that changing a Secret automatically reloads an application causes stale credentials and failed rotations.

Storage failures are also frequently misunderstood. A PVC request does not guarantee a particular performance level unless the StorageClass and provider support it. A snapshot is not necessarily an application-consistent backup. A replicated volume is not the same as a replicated application. A retained volume can preserve data, but without metadata, credentials, and restoration instructions it may not produce a usable service.

Capacity management deserves attention. Full disks can stop databases, corrupt filesystems, or prevent new replicas from starting. Teams should monitor requested capacity, actual utilization, inode consumption where relevant, I/O latency, throughput, queue depth, and expansion events. Storage expansion should be tested before it is urgently needed.

Governance must address data residency, retention, legal discovery, privacy, access reviews, separation of duties, and secure deletion. Sensitive data should not be copied into development clusters merely for convenience. Production backups may contain more information than production applications and therefore require equivalent or stronger protection.

Emerging Practices and Professional Guidance

Kubernetes storage is increasingly integrated with cloud-native data services, policy engines, and automated backup platforms. Secret delivery is moving toward short-lived credentials, workload identity, and dynamic access rather than manually distributed static passwords. CSI drivers increasingly support snapshots, cloning, expansion, encryption integration, and topology-aware placement, although feature support must be verified for the specific provider and version.

GitOps is useful for declarative configuration, but secret values should be handled through encrypted manifests, external references, or a controlled secret-management workflow. Policy-as-code can enforce approved registries, storage classes, reclaim policies, encryption requirements, and restrictions on privileged access. Automation should reduce human error without hiding important lifecycle decisions.

The most dependable professional practice is to create a data contract for every stateful component. The contract identifies the data owner, classification, source of truth, access pattern, capacity, performance needs, RPO, RTO, backup method, retention, encryption, restoration test frequency, and decommissioning procedure. This turns storage from an infrastructure detail into an explicit service responsibility.

Best-Practice Checklist

Before deploying a production workload, verify that:

• configuration is separated from secrets and persistent business data;
• Secrets are protected by least-privilege RBAC and encryption at rest;
• external secret access uses workload identity where possible;
• secret rotation and application reload behavior are documented;
• the StorageClass matches performance, topology, encryption, and lifecycle needs;
• reclaim policy is deliberately selected;
• stateful workloads use a supported replication and failover model;
• backups are independent, encrypted, retained appropriately, and tested;
• storage capacity and performance are monitored;
• recovery procedures include all required metadata, credentials, and dependencies;
• data access and administrative activity are auditable;
• development and test environments do not receive unnecessary production data.

Chapter Summary

Kubernetes separates the delivery of non-confidential configuration, sensitive credentials, and durable application data through ConfigMaps, Secrets, and persistent storage abstractions. ConfigMaps support declarative configuration but do not automatically reload applications. Secrets provide a structured delivery mechanism, yet base64 encoding is not encryption; effective protection requires RBAC, encryption at rest, auditing, rotation, and careful workload identity. External secret systems improve central governance and dynamic credential management but introduce integration and availability considerations.

Persistent storage is organized through PVCs, PVs, StorageClasses, and CSI drivers. Dynamic provisioning reduces manual work, while access modes, topology, reclaim policies, and provider capabilities determine actual behavior. StatefulSets provide stable identity and per-replica claims but do not replace database-aware replication, backup, or recovery design. Finally, high availability must be distinguished from backup. Reliable stateful platforms require application-consistent protection, tested restoration, explicit RPO and RTO targets, and governance over data access and lifecycle.

Key Terms

ConfigMap: A Kubernetes object used to store non-confidential configuration data.

Secret: A Kubernetes object intended to represent sensitive data such as passwords, tokens, or keys.

Encryption at rest: Protection of stored data so that unauthorized access to the underlying storage does not reveal its contents.

Envelope encryption: A method in which data keys encrypt data and a separate key protects the data keys.

RBAC: Role-Based Access Control; a mechanism that grants permissions according to roles assigned to identities.

Workload identity: A platform identity assigned to a workload so it can access authorized services without static credentials.

PersistentVolume: A Kubernetes representation of provisioned storage available to workloads.

PersistentVolumeClaim: A workload request for storage capacity and access characteristics.

StorageClass: A Kubernetes description of a storage tier and its provisioning behavior.

CSI: Container Storage Interface, a standard for integrating storage systems with container orchestrators.

Dynamic provisioning: Automatic creation of storage when a suitable PVC is requested.

Static provisioning: Administrator-created allocation of storage represented by a PV.

Access mode: A declared pattern describing how a volume may be mounted, such as RWO or RWX.

Reclaim policy: The rule determining what happens to storage after its claim is released.

StatefulSet: A Kubernetes controller for workloads requiring stable identity and persistent, ordinally associated storage.

RPO: Recovery Point Objective; the maximum acceptable amount of data loss measured in time.

RTO: Recovery Time Objective; the maximum acceptable time to restore service.

Volume snapshot: A point-in-time representation of a storage volume, subject to provider and consistency limitations.

Envelope secret: A secret-management approach in which applications or operators retrieve protected values from an external system rather than storing authoritative values in Kubernetes.

Review Questions

Short Answer Questions

1. Why is base64 encoding in a Secret not equivalent to encryption?

2. What is the difference between a ConfigMap and a Secret?

3. What role does a StorageClass play in dynamic provisioning?

4. Define RPO and RTO.

5. Why does a StatefulSet not, by itself, make a database highly available?

Long Answer Questions

1. Explain the Kubernetes configuration–secret–state model and show how each category should be managed differently.

2. Describe the architecture and operational implications of CSI-based dynamic provisioning.

3. Compare native Kubernetes Secrets, synchronized external secrets, direct injection, and application-level retrieval.

4. Discuss the factors that should guide the selection of a managed database, an operator-managed database, or a self-managed StatefulSet.

5. Develop a complete backup and restoration strategy for a production database running on Kubernetes.

Analytical / Application Questions

1. A team stores credentials in Git, mounts a shared RWX volume to three database Pods, and relies on volume replication as its backup. Identify the design flaws and propose a corrected architecture.

2. A workload uses a zonal RWO volume and sometimes remains Pending after a node failure. Analyze the likely topology issue and recommend investigation and design actions.

3. Design a secret and persistent-storage strategy for a payment service with strict access controls, a fifteen-minute RPO, a one-hour RTO, and quarterly credential rotation. Justify the choices you make.

22. Multiple Choice Questions with Answers

Question 1

A team stores a database password in a Kubernetes Secret using the usual manifest encoding. Which statement is correct?

A. The password is protected because base64 encoding is a form of encryption.

B. The password is reversible from the encoded value, so additional controls such as RBAC and encryption at rest are required.

C. The password can be read only by the cluster administrator.

D. The password is automatically rotated whenever the Pod restarts.

Correct Answer: B. The password is reversible from the encoded value, so additional controls such as RBAC and encryption at rest are required.

Question 2

Which design is most appropriate for a non-confidential logging level that should be reviewed and changed independently of the container image?

A. A ConfigMap referenced by the workload

B. A TLS private key stored in the image

C. A database volume mounted read-write by every Pod

D. A password embedded in the Deployment command

Correct Answer: A. A ConfigMap referenced by the workload

Question 3

What is the primary purpose of a StorageClass in Kubernetes?

A. To define application-level database replication

B. To describe storage provisioning characteristics and connect claims with a provisioner

C. To encrypt every file written by an application

D. To guarantee that all volumes support concurrent writers

Correct Answer: B. To describe storage provisioning characteristics and connect claims with a provisioner

Question 4

Why can a volume snapshot be insufficient as the sole backup method for a database?

A. Snapshots can never be restored to another volume.

B. Snapshots always delete the original volume.

C. A snapshot may not be application-consistent during active transactions.

D. Snapshots are available only for ConfigMaps.

Correct Answer: C. A snapshot may not be application-consistent during active transactions.

Question 5

A workload must use a secret manager without distributing long-lived cloud credentials to every Pod. Which approach best supports this requirement?

A. Store the credentials in a public ConfigMap.

B. Use workload identity with narrowly scoped access to the external secret system.

C. Place the credentials in the container image.

D. Grant every namespace administrator access to all secrets.

Correct Answer: B. Use workload identity with narrowly scoped access to the external secret system.

Question 6

What does the `Retain` reclaim policy generally accomplish for a PersistentVolume?

A. It automatically deletes the underlying storage when the claim is released.

B. It preserves the storage for deliberate recovery or cleanup after the claim is released.

C. It converts the volume into a ConfigMap.

D. It ensures that the volume can be mounted by unlimited Pods.

Correct Answer: B. It preserves the storage for deliberate recovery or cleanup after the claim is released.

Question 7

Which statement best describes a StatefulSet?

A. It automatically provides database correctness and distributed consensus.

B. It provides stable identity and commonly per-replica storage, while application replication remains a separate concern.

C. It is used only for stateless web servers.

D. It prevents all data loss without backups.

Correct Answer: B. It provides stable identity and commonly per-replica storage, while application replication remains a separate concern.

Question 8

A PVC remains Pending because its volume is being provisioned in a zone incompatible with the scheduled Pod. Which StorageClass feature can help coordinate provisioning with scheduling?

A. ReadOnlyMany

B. WaitForFirstConsumer

C. Opaque secret type

D. RetainOnly

Correct Answer: B. WaitForFirstConsumer

Question 9

Which practice most directly reduces the impact of a compromised application Pod?

A. Granting its service account read access to every Secret in the namespace

B. Using least-privilege RBAC so it can read only the required secrets

C. Duplicating all production secrets in every namespace

D. Writing secret values into application logs for diagnosis

Correct Answer: B. Using least-privilege RBAC so it can read only the required secrets

Question 10

Why is replication not a substitute for backup?

A. Replication cannot improve availability.

B. Replicas may reproduce accidental deletion, corruption, or a faulty migration.

C. Replicated systems cannot use persistent volumes.

D. Backup systems do not support encryption.

Correct Answer: B. Replicas may reproduce accidental deletion, corruption, or a faulty migration.