Storage practice questions

A DevOps team needs to provide persistent storage to a set of pods that all require read-write access to the same data simultaneously. Which volume type should they use?

Trap 1: hostPath

A hostPath volume mounts a file or directory from the host node's filesystem directly into your Pod. While this allows sharing data between pods on the exact same node, it fails to provide a shared storage solution for pods scheduled across different nodes in a multi-node cluster, and it poses significant security risks.

Trap 2: emptyDir

An emptyDir volume is created when a Pod is assigned to a node and exists only as long as that Pod is running on that node. Because its lifecycle is strictly tied to the hosting Pod, it cannot persist data across Pod restarts or deletions, nor can it be shared with other Pods running elsewhere in the cluster.

Trap 3: PersistentVolumeClaim with ReadWriteOnce

A PersistentVolumeClaim with the ReadWriteOnce (RWO) access mode restricts volume mounting to a single node at a time for read-write operations. If the DevOps team deploys multiple pods across different nodes, only the pods on the first node to claim the volume will be able to write to it, causing scheduling or mounting failures for the others.

A
PersistentVolumeClaim with ReadWriteMany
A PersistentVolumeClaim configured with the ReadWriteMany (RWX) access mode allows a volume to be mounted as read-write by many nodes concurrently. This is the correct choice for enabling multiple pods distributed across different nodes in a cluster to simultaneously access and modify the same persistent storage backend.
B
hostPath
Why wrong: A hostPath volume mounts a file or directory from the host node's filesystem directly into your Pod. While this allows sharing data between pods on the exact same node, it fails to provide a shared storage solution for pods scheduled across different nodes in a multi-node cluster, and it poses significant security risks.
C
emptyDir
Why wrong: An emptyDir volume is created when a Pod is assigned to a node and exists only as long as that Pod is running on that node. Because its lifecycle is strictly tied to the hosting Pod, it cannot persist data across Pod restarts or deletions, nor can it be shared with other Pods running elsewhere in the cluster.
D
PersistentVolumeClaim with ReadWriteOnce
Why wrong: A PersistentVolumeClaim with the ReadWriteOnce (RWO) access mode restricts volume mounting to a single node at a time for read-write operations. If the DevOps team deploys multiple pods across different nodes, only the pods on the first node to claim the volume will be able to write to it, causing scheduling or mounting failures for the others.

Question 2hardmultiple choice

A company is migrating a stateful application to Kubernetes. The application requires persistent storage that is 'zone-aware' to survive a single zone failure and must provide the highest possible I/O performance. Which storage solution best meets these requirements?

Trap 1: Use a network filesystem (NFS) server running as a single pod with…

Running an NFS server as a single pod introduces a critical single point of failure for the entire storage solution. While the underlying regional Persistent Disk offers data redundancy, the NFS server pod itself is not highly available; if it fails, all applications relying on it lose access to storage until it recovers. Furthermore, network file systems inherently add latency compared to block storage directly attached to a node.

Trap 2: Create a StorageClass with WaitForFirstConsumer binding and…

Configuring a StorageClass with volumeBindingMode: WaitForFirstConsumer ensures that a PersistentVolume is provisioned in the same zone where the consuming pod is scheduled. While this helps with zone affinity and prevents premature volume binding in an unsuitable zone, it does not inherently provide zone resilience for the data itself or guarantee high performance. The underlying storage type, not the binding mode, determines data replication and performance characteristics.

Trap 3: Deploy a StatefulSet with a local SSD on each node and use a…

Utilizing local SSDs on each node with a DaemonSet for replication is problematic because local SSDs are ephemeral and tied directly to a specific node; if that node fails, the data is lost unless the custom replication mechanism has successfully synchronized it. Managing data replication across nodes and zones with a DaemonSet is extremely complex, error-prone, and typically less reliable or performant than platform-managed regional storage solutions. This approach lacks inherent zone resilience and adds significant operational overhead.

A
Use a network filesystem (NFS) server running as a single pod with a PersistentVolume backed by a regional Persistent Disk
Why wrong: Running an NFS server as a single pod introduces a critical single point of failure for the entire storage solution. While the underlying regional Persistent Disk offers data redundancy, the NFS server pod itself is not highly available; if it fails, all applications relying on it lose access to storage until it recovers. Furthermore, network file systems inherently add latency compared to block storage directly attached to a node.
B
Create a StorageClass with WaitForFirstConsumer binding and volumeBindingMode: WaitForFirstConsumer
Why wrong: Configuring a StorageClass with volumeBindingMode: WaitForFirstConsumer ensures that a PersistentVolume is provisioned in the same zone where the consuming pod is scheduled. While this helps with zone affinity and prevents premature volume binding in an unsuitable zone, it does not inherently provide zone resilience for the data itself or guarantee high performance. The underlying storage type, not the binding mode, determines data replication and performance characteristics.
C
Use a StorageClass that provisions regional Persistent Disks with replication across two zones
A StorageClass provisioning regional Persistent Disks with replication across two zones directly addresses the requirements for a stateful application. Regional PDs automatically replicate data synchronously between two zones within a region, ensuring high availability and resilience against single zone failures. This design provides both robust data durability and high performance, making it ideal for critical stateful workloads that demand continuous operation and data integrity.
D
Deploy a StatefulSet with a local SSD on each node and use a DaemonSet to manage replication
Why wrong: Utilizing local SSDs on each node with a DaemonSet for replication is problematic because local SSDs are ephemeral and tied directly to a specific node; if that node fails, the data is lost unless the custom replication mechanism has successfully synchronized it. Managing data replication across nodes and zones with a DaemonSet is extremely complex, error-prone, and typically less reliable or performant than platform-managed regional storage solutions. This approach lacks inherent zone resilience and adds significant operational overhead.

Question 3easymultiple choice

A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?

Trap 1: The pod's YAML has a syntax error

If the Pod's YAML manifest contained a syntax error, the Kubernetes API server would reject the creation request entirely during the validation phase. In this scenario, the Pod object would never be instantiated in the cluster. This differs from a Pod that successfully registers but is blocked from starting due to an unbound storage dependency.

Trap 2: The pod is using a hostPath volume

A hostPath volume mounts a file or directory from the host node's filesystem directly into the Pod. This type of volume bypasses the PersistentVolumeClaim and PersistentVolume subsystem entirely, as it is defined directly within the Pod's volume specification. Therefore, a PVC issue cannot block a Pod that relies solely on hostPath storage.

Trap 3: The node has insufficient CPU resources

Insufficient CPU resources on a node will cause the scheduler to mark the Pod as unschedulable, resulting in a FailedScheduling event. However, this resource constraint does not impact the lifecycle or binding process of a PersistentVolumeClaim. PVC binding occurs independently of node CPU capacity, meaning a PVC can successfully bind even if no nodes have the resources to run the Pod.

A
The PersistentVolumeClaim's storage class does not exist or cannot provision a volume
When a PersistentVolumeClaim references a non-existent or misconfigured StorageClass, the dynamic volume provisioner cannot fulfill the request. Consequently, the PVC remains stuck in a Pending state indefinitely. Because the Pod's volume mount depends on a successfully bound PVC, the Kubernetes scheduler cannot assign the Pod to a node, preventing it from starting.
B
The pod's YAML has a syntax error
Why wrong: If the Pod's YAML manifest contained a syntax error, the Kubernetes API server would reject the creation request entirely during the validation phase. In this scenario, the Pod object would never be instantiated in the cluster. This differs from a Pod that successfully registers but is blocked from starting due to an unbound storage dependency.
C
The pod is using a hostPath volume
Why wrong: A hostPath volume mounts a file or directory from the host node's filesystem directly into the Pod. This type of volume bypasses the PersistentVolumeClaim and PersistentVolume subsystem entirely, as it is defined directly within the Pod's volume specification. Therefore, a PVC issue cannot block a Pod that relies solely on hostPath storage.
D
The node has insufficient CPU resources
Why wrong: Insufficient CPU resources on a node will cause the scheduler to mark the Pod as unschedulable, resulting in a FailedScheduling event. However, this resource constraint does not impact the lifecycle or binding process of a PersistentVolumeClaim. PVC binding occurs independently of node CPU capacity, meaning a PVC can successfully bind even if no nodes have the resources to run the Pod.

Question 4hardmultiple choice

A cluster administrator needs to provide storage to a pod that must read and write files, but the data does not need to persist beyond the pod's lifecycle. Which volume type should be used?

Trap 1: hostPath

While a hostPath volume mounts a file or directory from the host node's filesystem directly into your Pod, it persists independently of the Pod's lifecycle. If the Pod is deleted or rescheduled to another node, the data remains on the original host, which violates the requirement for temporary, Pod-lifecycle-bound storage. Additionally, using hostPath introduces security risks and couples the Pod to a specific node's filesystem structure.

Trap 2: configMap

A configMap is designed to inject non-confidential configuration data, such as environment variables or read-only configuration files, into a container. It is mounted as a read-only volume by default and cannot be used as a general-purpose read-write storage medium for application data or temporary scratch space. Attempting to write to a mounted ConfigMap volume will result in a read-only filesystem error.

Trap 3: PersistentVolumeClaim

A PersistentVolumeClaim (PVC) is used to request durable, long-term storage backed by a PersistentVolume (PV) that exists independently of any Pod's lifecycle. If a Pod utilizing a PVC is deleted, the underlying volume and its data persist according to the PV's reclaim policy (such as Retain or Delete). This introduces unnecessary overhead and resource allocation for temporary storage needs that should be bound strictly to the Pod's execution span.

A
hostPath
Why wrong: While a hostPath volume mounts a file or directory from the host node's filesystem directly into your Pod, it persists independently of the Pod's lifecycle. If the Pod is deleted or rescheduled to another node, the data remains on the original host, which violates the requirement for temporary, Pod-lifecycle-bound storage. Additionally, using hostPath introduces security risks and couples the Pod to a specific node's filesystem structure.
B
emptyDir
An emptyDir volume is created when a Pod is assigned to a node and exists solely for the lifetime of that Pod on that node. It provides a clean, read-write directory that is automatically deleted when the Pod terminates, making it the ideal choice for transient scratch space, multi-container sharing, or caching. Since the data does not need to survive Pod deletion, this lightweight, ephemeral storage mechanism perfectly satisfies the requirements.
C
configMap
Why wrong: A configMap is designed to inject non-confidential configuration data, such as environment variables or read-only configuration files, into a container. It is mounted as a read-only volume by default and cannot be used as a general-purpose read-write storage medium for application data or temporary scratch space. Attempting to write to a mounted ConfigMap volume will result in a read-only filesystem error.
D
PersistentVolumeClaim
Why wrong: A PersistentVolumeClaim (PVC) is used to request durable, long-term storage backed by a PersistentVolume (PV) that exists independently of any Pod's lifecycle. If a Pod utilizing a PVC is deleted, the underlying volume and its data persist according to the PV's reclaim policy (such as Retain or Delete). This introduces unnecessary overhead and resource allocation for temporary storage needs that should be bound strictly to the Pod's execution span.

Question 5mediummultiple choice

A team is designing a storage solution for a Cassandra cluster on Kubernetes. Each pod must have its own dedicated storage, and the cluster must be able to scale up and down dynamically. Which Kubernetes resource should be used to manage the storage?

Trap 1: ReplicaSet with emptyDir volumes

ReplicaSets are designed for stateless workloads and do not guarantee stable network identities or persistent storage bindings. Using emptyDir volumes means that any data written by Cassandra is strictly tied to the Pod's lifecycle; if a Pod is deleted or rescheduled, its data is permanently lost, violating Cassandra's durability requirements.

Trap 2: DaemonSet with hostPath volumes

While DaemonSets run a pod on every node, coupling Cassandra to hostPath volumes creates a tight, fragile dependency on specific physical nodes. If a node fails or undergoes maintenance, the Cassandra pod cannot be rescheduled to another node while retaining access to its local data, leading to potential data loss and cluster degradation.

Trap 3: Deployment with a single PersistentVolume shared by all pods

Deployments are intended for stateless applications and cannot dynamically provision unique volumes per replica. Forcing multiple Cassandra instances to share a single PersistentVolume using ReadWriteMany access mode will cause severe file lock conflicts, data corruption, and performance degradation, as Cassandra's storage engine expects exclusive access to its data directory.

A
ReplicaSet with emptyDir volumes
Why wrong: ReplicaSets are designed for stateless workloads and do not guarantee stable network identities or persistent storage bindings. Using emptyDir volumes means that any data written by Cassandra is strictly tied to the Pod's lifecycle; if a Pod is deleted or rescheduled, its data is permanently lost, violating Cassandra's durability requirements.
B
DaemonSet with hostPath volumes
Why wrong: While DaemonSets run a pod on every node, coupling Cassandra to hostPath volumes creates a tight, fragile dependency on specific physical nodes. If a node fails or undergoes maintenance, the Cassandra pod cannot be rescheduled to another node while retaining access to its local data, leading to potential data loss and cluster degradation.
C
StatefulSet with a volumeClaimTemplate
StatefulSets are specifically designed for stateful applications like Cassandra that require stable network identifiers and persistent, dedicated storage. By utilizing a volumeClaimTemplate, Kubernetes automatically provisions a unique PersistentVolumeClaim (PVC) for each Pod replica, ensuring that even if a Pod is rescheduled, it reconnects to its exact corresponding volume.
D
Deployment with a single PersistentVolume shared by all pods
Why wrong: Deployments are intended for stateless applications and cannot dynamically provision unique volumes per replica. Forcing multiple Cassandra instances to share a single PersistentVolume using ReadWriteMany access mode will cause severe file lock conflicts, data corruption, and performance degradation, as Cassandra's storage engine expects exclusive access to its data directory.

Question 6easymulti select

Which TWO statements about PersistentVolume (PV) and PersistentVolumeClaim (PVC) binding are correct?

Trap 1: A PVC can be bound to a PV that has been released and is pending…

When a PVC is deleted, its bound PV transitions to the Released phase, meaning it still contains data from the previous claim. To protect data integrity, Kubernetes prevents new PVCs from binding to a Released volume until the administrator manually reclaims it or the configured ReclaimPolicy (such as Recycle or Delete) completes its execution.

Trap 2: A PV can be bound to multiple PVCs simultaneously if it has…

Although a ReadWriteMany access mode allows multiple Pods to mount the same volume concurrently, the binding relationship between a PV and a PVC is strictly one-to-one. Once a PersistentVolume is bound to a specific PersistentVolumeClaim, it is marked as Bound and becomes unavailable to satisfy any other claims, regardless of its underlying access capabilities.

Trap 3: A PV can only be bound to a PVC that requests exactly the same…

Incorrect. The PersistentVolume must provide at least as much storage as requested by the PVC, but the amounts do not need to be exactly equal. The PVC can request less storage than the PV provides.

A
A PVC can be bound to a PV that has been released and is pending reclamation
Why wrong: When a PVC is deleted, its bound PV transitions to the Released phase, meaning it still contains data from the previous claim. To protect data integrity, Kubernetes prevents new PVCs from binding to a Released volume until the administrator manually reclaims it or the configured ReclaimPolicy (such as Recycle or Delete) completes its execution.
B
A PV can be bound to multiple PVCs simultaneously if it has ReadWriteMany access mode
Why wrong: Although a ReadWriteMany access mode allows multiple Pods to mount the same volume concurrently, the binding relationship between a PV and a PVC is strictly one-to-one. Once a PersistentVolume is bound to a specific PersistentVolumeClaim, it is marked as Bound and becomes unavailable to satisfy any other claims, regardless of its underlying access capabilities.
C
A PVC will remain in Pending state if no PV matches its storage request and no StorageClass is defined
When a PersistentVolumeClaim (PVC) is created, the control plane's volume controller attempts to bind it to an existing static PersistentVolume (PV) that satisfies its capacity and access mode requirements. If no suitable pre-provisioned PV is available and there is no StorageClass configured to trigger dynamic provisioning, the PVC cannot transition to the Bound state and will remain indefinitely in a Pending status.
D
A PV can only be bound to a PVC that requests exactly the same amount of storage
Why wrong: Incorrect. The PersistentVolume must provide at least as much storage as requested by the PVC, but the amounts do not need to be exactly equal. The PVC can request less storage than the PV provides.
E
A PVC can be bound to a PV with a different access mode if the PV supports multiple modes
A PersistentVolume can be configured with multiple access modes, such as ReadWriteOnce and ReadWriteMany. A PersistentVolumeClaim requesting only a single access mode can successfully bind to this PV as long as its requested mode is included in the PV's supported list, even if the PV offers broader capabilities than the claim requires.

Question 7mediummulti select

Which THREE of the following are valid ways to provide storage to a pod in Kubernetes?

Trap 1: AWS Elastic Block Store (EBS) directly

Kubernetes pods cannot directly reference or provision cloud provider-specific storage like an AWS EBS volume using its raw ID within a pod specification. Kubernetes abstracts underlying infrastructure details through its PersistentVolume and PersistentVolumeClaim API objects. To utilize EBS, it must first be provisioned as a PersistentVolume or dynamically provisioned via a CSI driver and then requested by a pod through a PersistentVolumeClaim.

Trap 2: Docker volume

While Kubernetes uses container runtimes like Docker, it does not directly expose or utilize Docker's internal volume management mechanisms within its pod specifications. Kubernetes employs its own robust volume API, which includes types like emptyDir, hostPath, and PersistentVolumeClaim, to manage storage for pods. Therefore, attempting to specify a 'Docker volume' directly in a Kubernetes pod definition is not a valid or recognized volume type.

A
hostPath
A `hostPath` volume mounts a file or directory from the host node’s filesystem directly into the pod, satisfying the requirement for storage by providing a persistent, node-local data source without relying on a remote or network-backed volume plugin. This mechanism is valid because Kubernetes permits node-level filesystem access for pods that need to read or write host data, such as log collectors or daemon sets.
B
emptyDir
An emptyDir volume provides a temporary, ephemeral directory that is created when a pod is scheduled onto a node. Its contents are preserved across container restarts within the same pod but are deleted permanently when the pod terminates or is removed from the node. This makes it suitable for temporary data, scratch space, or inter-container communication within a single pod's lifecycle.
C
AWS Elastic Block Store (EBS) directly
Why wrong: Kubernetes pods cannot directly reference or provision cloud provider-specific storage like an AWS EBS volume using its raw ID within a pod specification. Kubernetes abstracts underlying infrastructure details through its PersistentVolume and PersistentVolumeClaim API objects. To utilize EBS, it must first be provisioned as a PersistentVolume or dynamically provisioned via a CSI driver and then requested by a pod through a PersistentVolumeClaim.
D
Docker volume
Why wrong: While Kubernetes uses container runtimes like Docker, it does not directly expose or utilize Docker's internal volume management mechanisms within its pod specifications. Kubernetes employs its own robust volume API, which includes types like emptyDir, hostPath, and PersistentVolumeClaim, to manage storage for pods. Therefore, attempting to specify a 'Docker volume' directly in a Kubernetes pod definition is not a valid or recognized volume type.
E
PersistentVolumeClaim
A PersistentVolumeClaim (PVC) is a request for storage by a user, acting as an abstraction layer that decouples a pod's storage needs from the underlying storage implementation. It allows pods to consume persistent storage resources without needing to know the specifics of the provisioned PersistentVolume or the storage backend. By referencing a PVC, a pod can reliably access persistent data, ensuring data persistence beyond the pod's lifecycle.

Question 8hardmultiple choice

You are a cluster administrator for a multi-tenant Kubernetes cluster. Each tenant runs a set of microservices in their own namespace. The cluster uses a custom CSI driver that provisions storage on a NetApp storage array. Recently, several tenants reported that their pods are stuck in Pending state with events indicating 'failed to provision volume' and 'timeout waiting for a volume to be created'. Upon investigation, you notice that the CSI controller pod is running but has high memory usage, and logs show 'context deadline exceeded' errors when calling the storage array API. The storage array is healthy and responsive to manual API calls from your workstation. Meanwhile, PVCs created in a test namespace with the same StorageClass succeed. What is the most likely cause and the best course of action?

Trap 1: Increase the memory limit of the CSI controller pod to reduce OOM…

The 'context deadline exceeded' error specifically indicates a timeout issue, typically related to network latency, API server responsiveness, or gRPC communication failures, rather than memory exhaustion. Increasing the memory limit of the CSI controller pod would not resolve these timing-related problems, as Out-Of-Memory (OOM) errors manifest as pod restarts due to memory pressure, not as connection timeouts. Therefore, this action misidentifies the root cause.

Trap 2: Restart the CSI controller pod to clear its memory and reset…

While restarting the CSI controller pod might temporarily alleviate issues by clearing transient states or re-establishing gRPC connections, it does not address the fundamental architectural limitations causing the 'context deadline exceeded' errors. The underlying problem of insufficient capacity for concurrent operations or overly long timeouts will persist, leading to a recurrence of the same issues under sustained multi-tenant load. This is a symptomatic fix, not a resolution to the root cause.

Trap 3: Add a network policy to isolate tenant namespaces to reduce load on…

Network policies primarily control ingress and egress IP traffic between pods and network endpoints within the Kubernetes cluster, acting as a firewall. Storage provisioning requests, however, are typically handled via API calls to the Kubernetes API server, which then interacts with the CSI driver's controller service, often using gRPC. Implementing network policies would not reduce the volume of these API-driven storage requests or impact the CSI driver's internal processing capacity or gRPC connection pool issues.

A
Adjust the CSI driver configuration to increase the maximum number of concurrent operations and reduce the request timeout
Increasing the maximum number of concurrent operations allows the CSI driver to process more storage provisioning and attachment requests simultaneously, directly addressing high demand from multiple tenants. Concurrently, reducing the request timeout ensures that stalled or slow operations fail faster, preventing gRPC connection pool exhaustion and freeing up resources for new requests, thereby improving overall responsiveness and resilience under load. This combination optimizes the driver's capacity and failure handling.
B
Increase the memory limit of the CSI controller pod to reduce OOM risk
Why wrong: The 'context deadline exceeded' error specifically indicates a timeout issue, typically related to network latency, API server responsiveness, or gRPC communication failures, rather than memory exhaustion. Increasing the memory limit of the CSI controller pod would not resolve these timing-related problems, as Out-Of-Memory (OOM) errors manifest as pod restarts due to memory pressure, not as connection timeouts. Therefore, this action misidentifies the root cause.
C
Restart the CSI controller pod to clear its memory and reset connections
Why wrong: While restarting the CSI controller pod might temporarily alleviate issues by clearing transient states or re-establishing gRPC connections, it does not address the fundamental architectural limitations causing the 'context deadline exceeded' errors. The underlying problem of insufficient capacity for concurrent operations or overly long timeouts will persist, leading to a recurrence of the same issues under sustained multi-tenant load. This is a symptomatic fix, not a resolution to the root cause.
D
Add a network policy to isolate tenant namespaces to reduce load on the CSI driver
Why wrong: Network policies primarily control ingress and egress IP traffic between pods and network endpoints within the Kubernetes cluster, acting as a firewall. Storage provisioning requests, however, are typically handled via API calls to the Kubernetes API server, which then interacts with the CSI driver's controller service, often using gRPC. Implementing network policies would not reduce the volume of these API-driven storage requests or impact the CSI driver's internal processing capacity or gRPC connection pool issues.

Question 9easymultiple choice

A team is deploying a stateful application that requires persistent storage. The application runs on multiple pods that need to share the same volume. Which volume type should be used?

Trap 1: Create a PersistentVolumeClaim with access mode ReadOnlyMany and…

ReadOnlyMany (ROX) access mode allows multiple nodes to mount a volume concurrently, but only in read-only mode. Since a stateful application typically requires the ability to write and persist its data, using ROX would prevent the application from functioning correctly by denying necessary write operations. This access mode is suitable for distributing static content, not for applications needing to modify shared state.

Trap 2: Create a PersistentVolumeClaim with access mode ReadWriteOnce and…

Creating a PersistentVolumeClaim with ReadWriteOnce (RWO) access mode is incorrect because RWO permits the volume to be mounted as read-write by only a single node, preventing multiple pods on different nodes from sharing it concurrently. This directly contradicts the requirement for multiple pods to share the same volume, implying potential access from various nodes. However, RWO is a common and appropriate choice for stateful applications where a single pod on a single node requires exclusive read-write access to its persistent storage, such as a database instance.

Trap 3: Use a hostPath volume configured on each node where pods are…

Using a hostPath volume is unsuitable for a stateful application requiring shared access across multiple pods, especially if those pods are scheduled on different nodes. A hostPath volume binds data directly to a specific node's filesystem, making it non-portable and inaccessible to pods on other nodes. Furthermore, hostPath volumes lack the robust lifecycle management, dynamic provisioning, and abstraction provided by PersistentVolumes, making them generally inappropriate for production-grade shared storage.

A
Create a PersistentVolumeClaim with access mode ReadOnlyMany and mount it in each pod.
Why wrong: ReadOnlyMany (ROX) access mode allows multiple nodes to mount a volume concurrently, but only in read-only mode. Since a stateful application typically requires the ability to write and persist its data, using ROX would prevent the application from functioning correctly by denying necessary write operations. This access mode is suitable for distributing static content, not for applications needing to modify shared state.
B
Create a PersistentVolumeClaim with access mode ReadWriteMany and use a supported storage class like NFS.
The ReadWriteMany (RWX) access mode is the appropriate choice as it permits multiple nodes to mount the volume concurrently for both read and write operations. This directly supports a stateful application requiring shared, concurrent write access from multiple pods, potentially distributed across different nodes. Utilizing a storage class like NFS is crucial because it natively supports the file-level sharing semantics required for RWX functionality, unlike typical block storage.
C
Create a PersistentVolumeClaim with access mode ReadWriteOnce and mount it in each pod.
Why wrong: Creating a PersistentVolumeClaim with ReadWriteOnce (RWO) access mode is incorrect because RWO permits the volume to be mounted as read-write by only a single node, preventing multiple pods on different nodes from sharing it concurrently. This directly contradicts the requirement for multiple pods to share the same volume, implying potential access from various nodes. However, RWO is a common and appropriate choice for stateful applications where a single pod on a single node requires exclusive read-write access to its persistent storage, such as a database instance.
D
Use a hostPath volume configured on each node where pods are scheduled.
Why wrong: Using a hostPath volume is unsuitable for a stateful application requiring shared access across multiple pods, especially if those pods are scheduled on different nodes. A hostPath volume binds data directly to a specific node's filesystem, making it non-portable and inaccessible to pods on other nodes. Furthermore, hostPath volumes lack the robust lifecycle management, dynamic provisioning, and abstraction provided by PersistentVolumes, making them generally inappropriate for production-grade shared storage.

Question 10mediummultiple choice

An administrator notices that a pod using a PersistentVolumeClaim is stuck in 'Pending' state. The PVC is bound to a PV with the status 'Released'. What is the most likely cause?

Trap 1: The PV's reclaim policy is 'Retain' and the PV must be manually…

When a PersistentVolumeClaim (PVC) is deleted, if its associated PersistentVolume (PV) has a 'Retain' reclaim policy, the PV transitions to a 'Released' state. In this state, the PV is no longer bound to a PVC but still exists, preserving its data. An administrator must manually delete the PV or change its reclaim policy to 'Recycle' or 'Delete' to make it available for new claims, effectively 'recycling' it.

Trap 2: The PV has a faulty disk and needs replacement.

A faulty disk would typically manifest as the PersistentVolume (PV) entering a 'Failed' or 'Error' state, or the pod experiencing I/O errors, rather than a 'Released' status. The 'Released' status specifically indicates that the PV was previously bound to a PersistentVolumeClaim (PVC) that has since been deleted, not a hardware malfunction. There is no information in the problem statement to suggest a physical disk issue.

Trap 3: The StorageClass has an incorrect provisioner.

An incorrect provisioner in a StorageClass would prevent the initial dynamic provisioning and binding of a PersistentVolume (PV) to a PersistentVolumeClaim (PVC) from ever succeeding. Since the problem states a pod *was using* a PV, it implies that the provisioning and binding process completed successfully at some point. Therefore, the issue is not with the StorageClass's provisioner but rather with the PV's state after its usage.

A
The PV's reclaim policy is 'Retain' and the PV must be manually recycled.
Why wrong: When a PersistentVolumeClaim (PVC) is deleted, if its associated PersistentVolume (PV) has a 'Retain' reclaim policy, the PV transitions to a 'Released' state. In this state, the PV is no longer bound to a PVC but still exists, preserving its data. An administrator must manually delete the PV or change its reclaim policy to 'Recycle' or 'Delete' to make it available for new claims, effectively 'recycling' it.
B
The PV has a faulty disk and needs replacement.
Why wrong: A faulty disk would typically manifest as the PersistentVolume (PV) entering a 'Failed' or 'Error' state, or the pod experiencing I/O errors, rather than a 'Released' status. The 'Released' status specifically indicates that the PV was previously bound to a PersistentVolumeClaim (PVC) that has since been deleted, not a hardware malfunction. There is no information in the problem statement to suggest a physical disk issue.
C
The StorageClass has an incorrect provisioner.
Why wrong: An incorrect provisioner in a StorageClass would prevent the initial dynamic provisioning and binding of a PersistentVolume (PV) to a PersistentVolumeClaim (PVC) from ever succeeding. Since the problem states a pod *was using* a PV, it implies that the provisioning and binding process completed successfully at some point. Therefore, the issue is not with the StorageClass's provisioner but rather with the PV's state after its usage.
D
The PV is not bound to any PVC.
Why wrong: While a PersistentVolume (PV) in a 'Released' state is indeed no longer actively bound to a PersistentVolumeClaim (PVC), this statement is an incomplete diagnosis. The 'Released' status specifically indicates that the PV *was* previously bound, and its associated PVC was deleted, triggering the reclaim policy. The critical detail is *why* it's no longer bound, which points to the reclaim policy, not just a general unbound state.

Question 11hardmulti select

Which THREE statements about CSI (Container Storage Interface) are correct?

Trap 1: CSI only works with dynamic provisioning.

Although CSI is most often used with dynamic provisioning through StorageClasses, the interface fully supports static provisioning. An administrator can pre-created a volume on the storage backend and manually define a PersistentVolume using `csi.volumeAttributes` and the `volumeHandle` that identifies the existing backend volume, and the CSI `ControllerPublishVolume` and `NodePublishVolume` RPCs will still attach and mount it when a pod schedules. Thus, CSI does not mandate dynamic provisioning; it simply provides the same standard RPCs for both pre-provisioned and dynamically created volumes.

Trap 2: CSI drivers must be compiled into the Kubernetes binary.

CSI drivers are intentionally out-of-tree and are not compiled into any Kubernetes binary. Instead, they run as separate pod containers (usually a DaemonSet on every node plus a controller sidecar) that expose a gRPC endpoint via a shared hostPath socket. The kubelet and the external-provisioner act as CSI clients that speak over that socket, making the driver a completely pluggable component. This architecture is the foundational reason CSI exists: to decouple storage plugins from the Kubernetes core so drivers can be updated, debugged, and distributed independently.

A
CSI supports both block and file volumes.
The CSI specification defines a standard set of gRPC RPCs that include volume capability negotiation via the `VolumeCapability` field, allowing a single driver to advertise support for both block devices (raw device mappings for databases or VMs) and file systems (e.g., ext4 or xfs mounted into pods). This flexibility is critical because the CSI contract is agnostic to the underlying volume type, so storage vendors can support both modes without Kubernetes knowing the details of how each is implemented.
B
CSI allows storage vendors to develop custom drivers without modifying Kubernetes core.
CSI creates a clean plugin boundary using a set of gRPC RPCs that live outside the Kubernetes codebase, so storage vendors implement their own driver as an independent process, typically packaged as a DaemonSet or sidecar containers. These drivers communicate with kubelet and kube-controller-manager over a Unix socket or TCP endpoint, meaning the Kubernetes core binary and source tree never need to be modified or rebuilt to add a new storage backend. This out-of-tree extensibility model is what allows third-party drivers to be installed dynamically and upgraded independently from Kubernetes releases.
C
CSI supports additional features like volume snapshots and resize.
Beyond the basic lifecycle RPCs for create/delete/attach/detach, the CSI spec defines optional extension RPCs such as `CreateSnapshot`, `DeleteSnapshot`, `ControllerExpandVolume`, and `NodeExpandVolume` that drivers can implement selectively. Kubernetes exposes these capabilities through native API objects like `VolumeSnapshot` and by allowing PersistentVolumeClaim resize, but only when the driver advertises the corresponding capabilities in its `ControllerGetCapabilities` response. This means end users gain features like cloud-backed snapshots and online resizing without relying on vendor-specific commands, yet the driver retains control over how those operations are carried out.
D
CSI only works with dynamic provisioning.
Why wrong: Although CSI is most often used with dynamic provisioning through StorageClasses, the interface fully supports static provisioning. An administrator can pre-created a volume on the storage backend and manually define a PersistentVolume using `csi.volumeAttributes` and the `volumeHandle` that identifies the existing backend volume, and the CSI `ControllerPublishVolume` and `NodePublishVolume` RPCs will still attach and mount it when a pod schedules. Thus, CSI does not mandate dynamic provisioning; it simply provides the same standard RPCs for both pre-provisioned and dynamically created volumes.
E
CSI drivers must be compiled into the Kubernetes binary.
Why wrong: CSI drivers are intentionally out-of-tree and are not compiled into any Kubernetes binary. Instead, they run as separate pod containers (usually a DaemonSet on every node plus a controller sidecar) that expose a gRPC endpoint via a shared hostPath socket. The kubelet and the external-provisioner act as CSI clients that speak over that socket, making the driver a completely pluggable component. This architecture is the foundational reason CSI exists: to decouple storage plugins from the Kubernetes core so drivers can be updated, debugged, and distributed independently.

Question 12hardmultiple choice

You are managing a Kubernetes cluster with 3 worker nodes (node1, node2, node3). A stateful application named 'app-db' uses a StatefulSet with 3 replicas, each requiring a PersistentVolumeClaim (PVC) of 10Gi with access mode ReadWriteOnce. The cluster uses a StorageClass 'fast-ssd' with a CSI driver that provisions volumes on a shared SAN. The StorageClass has reclaim policy 'Delete' and volumeBindingMode 'WaitForFirstConsumer'.

Recently, node1 failed and is unrecoverable. The pod running on node1 (app-db-0) is in 'Pending' state because its PVC is still bound to a PV that exists only on node1's local storage (the CSI driver incorrectly pinned the volume to node1). The other two pods (app-db-1 and app-db-2) are running fine. The application is critical and must be restored as soon as possible. You cannot recover node1.

What is the best course of action to get app-db-0 running again?

Trap 1: Scale down the StatefulSet to 0 replicas, then scale back to 3.

Scaling a StatefulSet down to 0 replicas will terminate all associated pods, including app-db-0. However, the PersistentVolumeClaims (PVCs) created by the StatefulSet, which are bound to the PersistentVolumes (PVs) on the unrecoverable node1, will persist. When scaled back up, the StatefulSet controller will attempt to reuse these existing PVCs, which are still bound to PVs on the failed node, preventing new pods from starting successfully on healthy nodes.

Trap 2: Manually repair node1 and rejoin it to the cluster.

The question explicitly states that node1 is unrecoverable, meaning it cannot be repaired or brought back online. Therefore, any solution relying on the recovery or rejoining of node1 to the cluster is fundamentally infeasible and does not address the problem under the given constraints. This option is a non-starter based on the problem statement.

Trap 3: Delete only the pod app-db-0, and let the StatefulSet recreate it.

Deleting only the app-db-0 pod will cause the StatefulSet controller to immediately recreate it, maintaining its stable identity. However, the recreated pod will still reference its existing PersistentVolumeClaim (PVC), app-db-pvc-app-db-0, which remains bound to the PersistentVolume (PV) provisioned on the unrecoverable node1. Consequently, the new pod will fail to mount its volume, as the underlying storage is inaccessible.

A
Scale down the StatefulSet to 0 replicas, then scale back to 3.
Why wrong: Scaling a StatefulSet down to 0 replicas will terminate all associated pods, including app-db-0. However, the PersistentVolumeClaims (PVCs) created by the StatefulSet, which are bound to the PersistentVolumes (PVs) on the unrecoverable node1, will persist. When scaled back up, the StatefulSet controller will attempt to reuse these existing PVCs, which are still bound to PVs on the failed node, preventing new pods from starting successfully on healthy nodes.
B
Manually repair node1 and rejoin it to the cluster.
Why wrong: The question explicitly states that node1 is unrecoverable, meaning it cannot be repaired or brought back online. Therefore, any solution relying on the recovery or rejoining of node1 to the cluster is fundamentally infeasible and does not address the problem under the given constraints. This option is a non-starter based on the problem statement.
C
Delete only the pod app-db-0, and let the StatefulSet recreate it.
Why wrong: Deleting only the app-db-0 pod will cause the StatefulSet controller to immediately recreate it, maintaining its stable identity. However, the recreated pod will still reference its existing PersistentVolumeClaim (PVC), app-db-pvc-app-db-0, which remains bound to the PersistentVolume (PV) provisioned on the unrecoverable node1. Consequently, the new pod will fail to mount its volume, as the underlying storage is inaccessible.
D
Delete the PVC and PV associated with app-db-0, and let the StatefulSet recreate the PVC and pod.
Deleting both the PersistentVolumeClaim (PVC) and its bound PersistentVolume (PV) for app-db-0 is the correct approach. Upon their deletion, the StatefulSet controller, observing the missing PVC for app-db-0, will automatically provision a new PVC. This new PVC will then trigger the dynamic provisioning of a new PV on an available, healthy node, allowing the StatefulSet to successfully create a new app-db-0 pod that can mount its volume and start correctly.

Question 13easymultiple choice

A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?

Trap 1: The PV's access mode is ReadOnlyMany

A ReadOnlyMany access mode does not block a volume from being mounted; it merely restricts the mounted volume to read-only access for multiple nodes. If the PV were ReadOnlyMany and compatible with the PVC's requested access mode, the kubelet would still perform the attach/mount operation successfully and the pod would run with a read-only filesystem. The error in question is a mount-stage failure, which is independent of access-mode permissions; an incompatible access mode would instead prevent the PVC from binding in the first place, not fail during mounting.

Trap 2: The PV is not created

If the PV were not created, the PVC could never bind, and the pod would be stuck in Pending at scheduling time with an event like '0/1 nodes are available: 1 persistentvolumeclaim ... is unbound' or 'no persistent volumes available for this claim'. The pod would never reach the container-starting phase, so it would not trigger a storage device mount attempt. Since the observed failure is specifically a mount failure that happens after the pod has been scheduled to a node, it proves the PV exists and is already bound to the PVC.

Trap 3: The PVC is unbound

An unbound PVC causes the scheduler to leave the pod unscheduled because the volume cannot be resolved before placement; Kubernetes would report a FailedBinding event or 'pod has unbound immediate PersistentVolumeClaims' rather than attempting to mount anything. The PVC status must be Bound for the kubelet to receive the volume's device path and call mount operations. Because the failure occurs during the mount phase, the PVC has necessarily already been bound to the PV and the pod has been scheduled to a node.

A
The PV's access mode is ReadOnlyMany
Why wrong: A ReadOnlyMany access mode does not block a volume from being mounted; it merely restricts the mounted volume to read-only access for multiple nodes. If the PV were ReadOnlyMany and compatible with the PVC's requested access mode, the kubelet would still perform the attach/mount operation successfully and the pod would run with a read-only filesystem. The error in question is a mount-stage failure, which is independent of access-mode permissions; an incompatible access mode would instead prevent the PVC from binding in the first place, not fail during mounting.
B
The PV is not created
Why wrong: If the PV were not created, the PVC could never bind, and the pod would be stuck in Pending at scheduling time with an event like '0/1 nodes are available: 1 persistentvolumeclaim ... is unbound' or 'no persistent volumes available for this claim'. The pod would never reach the container-starting phase, so it would not trigger a storage device mount attempt. Since the observed failure is specifically a mount failure that happens after the pod has been scheduled to a node, it proves the PV exists and is already bound to the PVC.
C
The PVC is unbound
Why wrong: An unbound PVC causes the scheduler to leave the pod unscheduled because the volume cannot be resolved before placement; Kubernetes would report a FailedBinding event or 'pod has unbound immediate PersistentVolumeClaims' rather than attempting to mount anything. The PVC status must be Bound for the kubelet to receive the volume's device path and call mount operations. Because the failure occurs during the mount phase, the PVC has necessarily already been bound to the PV and the pod has been scheduled to a node.
D
The underlying storage device is still attached to a previous node
Cloud provider disks, such as AWS EBS, GCE Persistent Disk, and Azure Managed Disk, are typically block devices that can be attached to only one node at a time. When a pod using such a PVC is rescheduled or evicted from a previous node, the old kubelet must detach the volume, and Kubernetes' attach/detach controller must mark it as unattached before the new node can attach it. If that detach is still in progress or failed, the new kubelet's mount attempt fails with an error such as 'Multi-Attach error for volume' or 'volume is still attached to node'. This is a transient but common cause of mount failures in environments using ReadWriteOnce volumes, and it is distinct from access-mode or binding problems.

Question 14hardmultiple choice

A team wants to ensure that a pod using a PersistentVolumeClaim (PVC) is scheduled only on nodes that have the underlying storage volume available locally. Which approach should they use?

Trap 1: Use a StorageClass with volumeBindingMode: Immediate

Setting volumeBindingMode: Immediate forces the PersistentVolumeClaim to bind to a PersistentVolume immediately upon creation, before the Pod is scheduled. This prevents the scheduler from evaluating the Pod's node constraints, often resulting in the PV being bound to a node that cannot satisfy the Pod's scheduling requirements.

Trap 2: Use a podAffinity rule to schedule the pod near the storage node

podAffinity is designed to co-locate Pods relative to other running Pods based on labels, rather than binding a Pod to a specific physical node hosting a local storage volume. It cannot target node-specific hardware or local storage resources directly, making it unsuitable for ensuring local volume availability.

Trap 3: Use a PersistentVolume with nodeAffinity in the PV spec

Configuring nodeAffinity within the PersistentVolume specification merely restricts which nodes the volume itself can be attached to. It does not directly dictate the Pod's scheduling behavior or guarantee that the scheduler will place the Pod on the correct node, especially if the volume binding mode is not configured to delay binding.

A
Add a nodeSelector to the pod spec that matches a label present on nodes with local storage
Specifying a nodeSelector in the Pod's specification directly constrains the Kubernetes scheduler to place the Pod only on nodes carrying the designated label. When using local PersistentVolumes, this ensures the Pod is scheduled onto the exact node where the physical storage resides, preventing scheduling failures due to mismatched node placement.
B
Use a StorageClass with volumeBindingMode: Immediate
Why wrong: Setting volumeBindingMode: Immediate forces the PersistentVolumeClaim to bind to a PersistentVolume immediately upon creation, before the Pod is scheduled. This prevents the scheduler from evaluating the Pod's node constraints, often resulting in the PV being bound to a node that cannot satisfy the Pod's scheduling requirements.
C
Use a podAffinity rule to schedule the pod near the storage node
Why wrong: podAffinity is designed to co-locate Pods relative to other running Pods based on labels, rather than binding a Pod to a specific physical node hosting a local storage volume. It cannot target node-specific hardware or local storage resources directly, making it unsuitable for ensuring local volume availability.
D
Use a PersistentVolume with nodeAffinity in the PV spec
Why wrong: Configuring nodeAffinity within the PersistentVolume specification merely restricts which nodes the volume itself can be attached to. It does not directly dictate the Pod's scheduling behavior or guarantee that the scheduler will place the Pod on the correct node, especially if the volume binding mode is not configured to delay binding.

Question 15mediummulti select

Which TWO statements about PersistentVolume (PV) reclaim policies are correct?

Trap 1: Recycle policy: the PV is deleted and data is scrubbed.

Recycle has never deleted the PV; when implemented, it runs a scrubbing operation (historically an `rm -rf` script) on the volume content and then marks the PV as Available again. It is deprecated as of Kubernetes 1.20 and lacks support in modern CSI drivers, so stating that it deletes the PV conflates it with the Delete policy.

Trap 2: Delete policy: the PV remains but the underlying storage is deleted.

The Delete policy removes both the PV API object and the underlying storage in a single operation; the PV cannot survive after its backing storage is deleted because the PV's definition is exactly a handle to that external storage. Leaving the PV behind after destroying the storage would leave a dangling reference and is contrary to how the volume controller implements deletion.

Trap 3: Retain policy: the PV is automatically deleted after 30 days.

Retain imposes no time-based lifecycle; a Released PV persists indefinitely until a human intervenes. There is no built-in '30-day' or any other automatic deletion timer in the Retain policy—only the Delete policy removes resources, and it does so immediately when invoked by the volume controller, not after a delay.

A
Delete policy: both the PV and the underlying storage are deleted.
Under the Delete reclaim policy, the PersistentVolume controller invokes the storage driver's volume-deletion routine, which destroys the backing storage asset (e.g., an EBS volume or GCE PD) and then removes the PV object from the API server. The cluster resource and the external volume are treated as a single unit; one cannot be removed without the other, and the PV does not linger in a Released phase.
B
Recycle policy: the PV is deleted and data is scrubbed.
Why wrong: Recycle has never deleted the PV; when implemented, it runs a scrubbing operation (historically an `rm -rf` script) on the volume content and then marks the PV as Available again. It is deprecated as of Kubernetes 1.20 and lacks support in modern CSI drivers, so stating that it deletes the PV conflates it with the Delete policy.
C
Delete policy: the PV remains but the underlying storage is deleted.
Why wrong: The Delete policy removes both the PV API object and the underlying storage in a single operation; the PV cannot survive after its backing storage is deleted because the PV's definition is exactly a handle to that external storage. Leaving the PV behind after destroying the storage would leave a dangling reference and is contrary to how the volume controller implements deletion.
D
Retain policy: the PV remains in the cluster and the underlying storage is not deleted.
With the Retain policy, after the PVC is deleted the PV moves to the Released phase, but both the PV object and the backing storage remain untouched. The data is left in place so an administrator can manually examine and reclaim it; the PV will not be re-bound to a new PVC until the administrator explicitly deletes the PV and re-creates it with the same storage endpoint if desired.
E
Retain policy: the PV is automatically deleted after 30 days.
Why wrong: Retain imposes no time-based lifecycle; a Released PV persists indefinitely until a human intervenes. There is no built-in '30-day' or any other automatic deletion timer in the Retain policy—only the Delete policy removes resources, and it does so immediately when invoked by the volume controller, not after a delay.

Question 16hardmultiple choice

Refer to the exhibit. A pod is defined with an emptyDir volume using memory medium. The pod is scheduled on a node with 4 GB of RAM. The container writes 3 GB of data to /cache. What will happen?

Exhibit

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: cache
      mountPath: /cache
  volumes:
  - name: cache
    emptyDir:
      medium: Memory

Trap 1: The container will be throttled by the kernel's memory management.

Memory is a non-compressible resource in Linux and Kubernetes, meaning it cannot be throttled like CPU. When a container or node runs out of memory, the kernel's Out-Of-Memory killer immediately terminates the offending process rather than slowing down its execution. Therefore, memory management issues will lead to pod termination or eviction rather than kernel throttling.

Trap 2: The pod will be evicted because emptyDir with memory is not allowed…

Kubernetes does not impose an arbitrary 1 GB limit on memory-backed emptyDir volumes. By default, a tmpfs emptyDir volume can consume up to 50% of the host node's physical memory unless a specific sizeLimit is declared in the pod specification. Since no such limit is configured here, the 3 GB write is fully permissible on a node with 4 GB of RAM.

Trap 3: The pod will be OOMKilled because the emptyDir memory usage exceeds…

There is no default memory limit applied to pods or emptyDir volumes in Kubernetes unless a LimitRange is active in the namespace. Without explicit container memory limits or an emptyDir sizeLimit specified in the manifest, the volume can scale up to the node's available memory capacity. Consequently, the pod will not trigger an Out-Of-Memory kill event simply by writing 3 GB of data.

A
The container will be throttled by the kernel's memory management.
Why wrong: Memory is a non-compressible resource in Linux and Kubernetes, meaning it cannot be throttled like CPU. When a container or node runs out of memory, the kernel's Out-Of-Memory killer immediately terminates the offending process rather than slowing down its execution. Therefore, memory management issues will lead to pod termination or eviction rather than kernel throttling.
B
The pod will be evicted because emptyDir with memory is not allowed to use more than 1 GB.
Why wrong: Kubernetes does not impose an arbitrary 1 GB limit on memory-backed emptyDir volumes. By default, a tmpfs emptyDir volume can consume up to 50% of the host node's physical memory unless a specific sizeLimit is declared in the pod specification. Since no such limit is configured here, the 3 GB write is fully permissible on a node with 4 GB of RAM.
C
The pod will be OOMKilled because the emptyDir memory usage exceeds the default limit.
Why wrong: There is no default memory limit applied to pods or emptyDir volumes in Kubernetes unless a LimitRange is active in the namespace. Without explicit container memory limits or an emptyDir sizeLimit specified in the manifest, the volume can scale up to the node's available memory capacity. Consequently, the pod will not trigger an Out-Of-Memory kill event simply by writing 3 GB of data.
D
The pod will run normally because there is no memory limit and the node has sufficient RAM.
When an emptyDir volume is configured with medium: Memory, Kubernetes mounts a tmpfs filesystem that consumes the host node's RAM. Because the pod has no defined memory limits and the 3 GB of written data fits within the node's 4 GB of physical RAM, the operation completes successfully. The pod will continue to run normally without triggering eviction or OOM termination.

Question 17mediummultiple choice

A DevOps team is deploying a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes in a Kubernetes cluster. Which storage solution should they choose to meet this requirement?

Trap 1: Use an emptyDir volume and share it among pods via a service

An emptyDir volume is strictly bound to the lifecycle of a single Pod and cannot be shared across multiple Pods over a Kubernetes Service. Furthermore, its data is ephemeral and is permanently deleted when the Pod is removed from the node, making it unsuitable for stateful applications requiring persistent, shared storage.

Trap 2: Create a local PersistentVolume on each node and use nodeSelector…

Local PersistentVolumes are inherently bound to specific nodes and only support the ReadWriteOnce access mode. They cannot be concurrently mounted by Pods running on different nodes, which prevents multi-node write access and defeats the purpose of a shared stateful storage solution.

Trap 3: Use a hostPath volume mounted in each pod with the same path on…

A hostPath volume mounts a directory from the host node's filesystem directly into a Pod, which restricts access to that specific node. Because it does not synchronize data across different physical nodes, Pods scheduled on different hosts will see entirely isolated filesystems rather than a unified, shared volume.

A
Use an emptyDir volume and share it among pods via a service
Why wrong: An emptyDir volume is strictly bound to the lifecycle of a single Pod and cannot be shared across multiple Pods over a Kubernetes Service. Furthermore, its data is ephemeral and is permanently deleted when the Pod is removed from the node, making it unsuitable for stateful applications requiring persistent, shared storage.
B
Create a local PersistentVolume on each node and use nodeSelector to pin pods
Why wrong: Local PersistentVolumes are inherently bound to specific nodes and only support the ReadWriteOnce access mode. They cannot be concurrently mounted by Pods running on different nodes, which prevents multi-node write access and defeats the purpose of a shared stateful storage solution.
C
Use a hostPath volume mounted in each pod with the same path on each node
Why wrong: A hostPath volume mounts a directory from the host node's filesystem directly into a Pod, which restricts access to that specific node. Because it does not synchronize data across different physical nodes, Pods scheduled on different hosts will see entirely isolated filesystems rather than a unified, shared volume.
D
Configure a PersistentVolume backed by NFS and a PersistentVolumeClaim with accessModes: ReadWriteMany
Network File System (NFS) is a network-attached storage solution that natively supports the ReadWriteMany (RWX) access mode in Kubernetes. This configuration allows multiple Pods distributed across different nodes in the cluster to simultaneously read from and write to the same persistent volume.

Question 18hardmulti select

Which TWO statements about Kubernetes PersistentVolumes and PersistentVolumeClaims are correct?

Trap 1: A PersistentVolume can only be created by a cluster administrator…

Static provisioning by a cluster administrator is only one way to create PersistentVolumes; dynamic provisioning automatically generates a PV when a PVC requests a StorageClass that has a provisioner configured. The dynamic provisioner (e.g., AWS EBS, GCE PD, or a CSI driver) creates the underlying storage and a matching PV object on demand without administrator intervention. Therefore, the statement is false because it excludes the dynamic provisioning path, which is a common and fundamental mechanism in Kubernetes.

Trap 2: A PVC is a cluster-scoped resource, similar to a PV.

PersistentVolumeClaims are namespace-scoped resources, unlike PersistentVolumes, which are cluster-scoped. A PVC is created inside a specific Kubernetes namespace and can only be referenced by pods in that same namespace, while a PV exists at the cluster level and can be bound by a PVC from any namespace. This distinction affects RBAC permissions and resource management: users granted PVC access in one namespace cannot affect PVCs in another, but a PV's cluster-wide nature requires cluster-level authorization to modify.

Trap 3: A PVC can be deleted while bound to a PV without affecting the PV.

Deleting a PVC that is bound to a PV does not have a universal no-effect outcome because the PV's reclaim policy determines the result. If the reclaim policy is Delete, the PV and its associated underlying storage will be removed when the PVC is deleted. If the policy is Retain, the PV remains in the Released state and can be manually reclaimed, but it is no longer available for binding; in either case, the PV is definitely affected by the deletion.

A
A PVC will bind to a PV that satisfies its requested storage size and access modes.
The PersistentVolume controller pairs a PVC with a PV by evaluating the PVC's requested storage capacity and access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) against the PV's properties. Binding also obeys additional constraints such as storageClassName, volumeMode, and any node-affinity/topology restrictions encoded in the PV, so a PV that matches size and access modes but violates these secondary criteria will not bind. Once a PVC and PV are bound, the relationship is exclusive until the PVC is deleted or the PV is released.
B
A PersistentVolume can only be created by a cluster administrator using static provisioning.
Why wrong: Static provisioning by a cluster administrator is only one way to create PersistentVolumes; dynamic provisioning automatically generates a PV when a PVC requests a StorageClass that has a provisioner configured. The dynamic provisioner (e.g., AWS EBS, GCE PD, or a CSI driver) creates the underlying storage and a matching PV object on demand without administrator intervention. Therefore, the statement is false because it excludes the dynamic provisioning path, which is a common and fundamental mechanism in Kubernetes.
C
A PVC is a cluster-scoped resource, similar to a PV.
Why wrong: PersistentVolumeClaims are namespace-scoped resources, unlike PersistentVolumes, which are cluster-scoped. A PVC is created inside a specific Kubernetes namespace and can only be referenced by pods in that same namespace, while a PV exists at the cluster level and can be bound by a PVC from any namespace. This distinction affects RBAC permissions and resource management: users granted PVC access in one namespace cannot affect PVCs in another, but a PV's cluster-wide nature requires cluster-level authorization to modify.
D
A PVC can be deleted while bound to a PV without affecting the PV.
Why wrong: Deleting a PVC that is bound to a PV does not have a universal no-effect outcome because the PV's reclaim policy determines the result. If the reclaim policy is Delete, the PV and its associated underlying storage will be removed when the PVC is deleted. If the policy is Retain, the PV remains in the Released state and can be manually reclaimed, but it is no longer available for binding; in either case, the PV is definitely affected by the deletion.
E
A PVC can remain in a Pending state indefinitely if no suitable PV is available.
A PVC will remain in the Pending state for as long as no PV meets its requirements, and Kubernetes will not automatically fail or delete it. This behavior is by design: the PersistentVolume controller continuously scans for new matching PVs, so a PVC can wait indefinitely if the required storage is never provisioned. In practice, this often occurs when a PVC requests a non-existent StorageClass or a size that no available PV can satisfy, and it is resolved by creating a suitable PV or adding a dynamic provisioner.

Question 19hardmulti select

Which THREE of the following are valid ways to provide storage to Pods in Kubernetes?

Trap 1: Using a ConfigMap volume

A ConfigMap volume is an API object that injects configuration data into the container as either files or environment variables. When mounted, it is read-only (unless using subPath with individual file mounts) and represents key-value pairs as a filesystem, but it is not designed to store application data or serve as general-purpose storage. ConfigMaps have a 1MB size limit and are meant for non-sensitive configuration, so they are not a valid choice for persistent, durable, or even scratch storage in a pod.

Trap 2: Using a Secret volume

A Secret volume is an API object intended to deliver sensitive data such as passwords, CA certificates, or API keys to containers. When mounted, it exposes the secret's key-value pairs as files in a tmpfs RAM-backed volume, which is neither persistent nor designed for general application data. Secrets are stored with a 1MB size limit and are base64-encoded, but they are configuration-like and cannot be treated as a general storage volume for application logs, databases, or cache files.

A
Using a ConfigMap volume
Why wrong: A ConfigMap volume is an API object that injects configuration data into the container as either files or environment variables. When mounted, it is read-only (unless using subPath with individual file mounts) and represents key-value pairs as a filesystem, but it is not designed to store application data or serve as general-purpose storage. ConfigMaps have a 1MB size limit and are meant for non-sensitive configuration, so they are not a valid choice for persistent, durable, or even scratch storage in a pod.
B
Using an emptyDir volume
An emptyDir volume is an initially empty directory created when a pod is scheduled on a node, and it persists as long as the pod exists on that node. It allows containers within the pod to read and write data, survives container restarts, and is often used for scratch space, caches, or for sharing data between sidecar containers in the same pod. However, its contents are completely deleted when the pod is removed from the node, making it a valid but ephemeral storage option only for temporary data.
C
Using a PersistentVolumeClaim
A PersistentVolumeClaim (PVC) is a user request for storage that abstractly requests durability, capacity, and access mode, and it gets bound to a PersistentVolume either statically or dynamically via a StorageClass. The pod references the PVC as a volume, and the underlying storage (e.g., cloud disk, NFS, or iSCSI) is mounted into the container, allowing data to persist beyond pod restarts and even pod re-scheduling depending on the PV's reclaim policy. This is the proper way to provide durable, persistent storage to an application and is a correct answer for a valid storage method.
D
Using a Secret volume
Why wrong: A Secret volume is an API object intended to deliver sensitive data such as passwords, CA certificates, or API keys to containers. When mounted, it exposes the secret's key-value pairs as files in a tmpfs RAM-backed volume, which is neither persistent nor designed for general application data. Secrets are stored with a 1MB size limit and are base64-encoded, but they are configuration-like and cannot be treated as a general storage volume for application logs, databases, or cache files.
E
Using a hostPath volume
A hostPath volume mounts a specified file or directory from the node's host filesystem directly into the pod, making the pod's storage path correspond to the host's path. This is a valid way to provide storage because the pod can read and write host data, and it is useful for accessing node-level artifacts like the Docker socket or system directories. However, it is node-specific, meaning the pod must run on the exact node where the hostPath exists, and it does not provide Kubernetes-managed durability, so it is not generally recommended for production persistent data storage.

Question 20mediumdrag order

Drag and drop the steps to configure a NetworkPolicy that allows ingress traffic from a specific pod into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Define NetworkPolicy YAML with podSelector and ingress from…

This order is incorrect because while defining the YAML can be done anytime, you cannot apply the policy before the namespace exists; but the namespace must be ensured before applying, not after defining. However, the sequence is still plausible if one defines first and then creates the namespace, but then the apply would fail if the namespace didn't exist at define time? Actually, the define step is just writing the file, so it doesn't require a namespace. The main issue is that applying without ensuring namespace existence would fail. So this order works if the namespace already exists, but it's not the recommended order because you should verify existence first. But it's a common oversight.

Trap 2: Ensure namespace exists, apply using kubectl, define NetworkPolicy…

This order is logically flawed because it attempts to execute the apply command before the NetworkPolicy manifest has actually been defined. Without a valid YAML file containing the podSelector and ingress specifications, the kubectl deployment command will fail immediately due to a missing file or empty input. Defining the resource must always precede its application to the cluster.

Trap 3: Ensure namespace exists, define NetworkPolicy YAML with podSelector…

This sequence is incorrect because it schedules connectivity testing before the NetworkPolicy has been applied to the Kubernetes API server. Testing at this stage is premature and will only reflect the default non-isolated state of the namespace, rather than the intended ingress restrictions. The policy must be actively enforced by the container network interface before any validation tests can yield meaningful results.

A
Ensure namespace exists, define NetworkPolicy YAML with podSelector and ingress from specific pods, apply using kubectl, test ingress connectivity
This sequence represents the correct lifecycle for deploying a NetworkPolicy. The target namespace must exist first to avoid namespace-not-found errors during resource creation. Once the namespace is verified, the NetworkPolicy YAML is defined with the correct selectors, applied to the cluster, and finally validated through connectivity testing to ensure the rules are active and functioning as intended.
B
Define NetworkPolicy YAML with podSelector and ingress from specific pods, ensure namespace exists, apply using kubectl, test ingress connectivity
Why wrong: This order is incorrect because while defining the YAML can be done anytime, you cannot apply the policy before the namespace exists; but the namespace must be ensured before applying, not after defining. However, the sequence is still plausible if one defines first and then creates the namespace, but then the apply would fail if the namespace didn't exist at define time? Actually, the define step is just writing the file, so it doesn't require a namespace. The main issue is that applying without ensuring namespace existence would fail. So this order works if the namespace already exists, but it's not the recommended order because you should verify existence first. But it's a common oversight.
C
Ensure namespace exists, apply using kubectl, define NetworkPolicy YAML with podSelector and ingress from specific pods, test ingress connectivity
Why wrong: This order is logically flawed because it attempts to execute the apply command before the NetworkPolicy manifest has actually been defined. Without a valid YAML file containing the podSelector and ingress specifications, the kubectl deployment command will fail immediately due to a missing file or empty input. Defining the resource must always precede its application to the cluster.
D
Ensure namespace exists, define NetworkPolicy YAML with podSelector and ingress from specific pods, test ingress connectivity, apply using kubectl
Why wrong: This sequence is incorrect because it schedules connectivity testing before the NetworkPolicy has been applied to the Kubernetes API server. Testing at this stage is premature and will only reflect the default non-isolated state of the namespace, rather than the intended ingress restrictions. The policy must be actively enforced by the container network interface before any validation tests can yield meaningful results.