GKE workloads can use several different storage types, and each one has different performance, durability, and cost characteristics. This article covers Persistent Disk, Local SSD, and Hyperdisk: what each one is, when to use which, and how the Associate Cloud Engineer exam tests this.
It does not cover every Hyperdisk tier in depth, the exact IOPS numbers for each option, or how to provision storage with custom CSI drivers. The goal is the ACE exam version, which focuses on the durability and performance distinctions.
Almost every GKE storage decision comes down to two questions.
First: does the data need to survive node failure? If yes, you need persistent storage. If the data can be regenerated or fetched from elsewhere, ephemeral storage is fine.
Second: does the workload need extreme I/O performance? If yes, you need a high-performance option like Local SSD or Hyperdisk. If the workload has normal I/O patterns, standard options are cheaper and sufficient.
The three storage types in this article correspond to three different answers to those two questions.
Persistent Disk is the default and most common option. The data lives independently of any specific node. If a node fails or a pod gets rescheduled, the disk can be reattached to a different node and the data is intact. This is the right choice for stateful workloads where data durability matters more than absolute peak performance.
Persistent Disk comes in a few flavors. Standard Persistent Disk (HDD-backed, cheaper, lower performance) for workloads with modest I/O needs. Persistent SSD (SSD-backed, more expensive, higher performance) for workloads that need consistent low latency. The SSD variant is the right default for most stateful applications, like web servers and small to medium databases.
Persistent Disk is what backs PersistentVolumeClaims in GKE by default. When a StatefulSet declares a volume claim, you typically get a Persistent Disk attached to the pod, and that disk follows the pod's identity across rescheduling.
Local SSD is a different beast. It is physically attached to the node, gives you extremely high I/O and ultra-low latency, and is much faster than Persistent Disk. The catch is that it is ephemeral. If the node is deleted or fails, the data is gone. There is no concept of reattaching a Local SSD to a different node, because it is bound to the physical hardware of the node it is on.
Local SSD is appropriate for workloads where performance matters and durability does not. The classic cases are caching layers, scratch data for high-performance computing, intermediate data during processing pipelines, and similar scenarios where the data can be regenerated or fetched again if a node goes away.
Use Local SSD as a cache or working space, not as a primary store for anything you cannot afford to lose.
Hyperdisk is Google's higher-performance persistent storage line. It is persistent like Persistent Disk, but the performance ceiling is much higher and the IOPS and throughput are tunable independently of the disk size. With Persistent Disk, you typically get more IOPS by making the disk bigger. With Hyperdisk, you can dial in IOPS and throughput as separate parameters.
Hyperdisk comes in a few tiers. Hyperdisk Balanced offers a middle ground between performance and cost, suitable for workloads that are more demanding than Persistent SSD can handle but do not need the very top tier. Hyperdisk Throughput is tuned for sequential, high-bandwidth workloads. Hyperdisk Extreme is for the very highest-performance workloads, like high-end transactional databases and demanding ML training pipelines.
For the ACE exam, the important thing is recognizing that Hyperdisk is the answer when the scenario calls out exceptionally high IOPS or throughput needs that go beyond what standard Persistent SSD can provide.
The decision tree looks like this.
If the data is durable and the performance needs are modest, use Standard Persistent Disk.
If the data is durable and the performance needs are typical (web server, small to medium database), use Persistent SSD.
If the data is durable and the performance needs are exceptional (large database, ML training, high-throughput analytics), use Hyperdisk.
If the data is ephemeral and the performance needs are exceptional (cache, scratch space, temporary high-I/O work), use Local SSD.
If you need shared file access across multiple pods on different nodes, none of the above is right. That is what Filestore is for, but it is a different topic.
A few patterns come up.
The first is the durability question. The scenario describes a stateful workload, often a database, and asks what storage to use. The answer is Persistent Disk (or Hyperdisk if the performance is called out as exceptional). Local SSD is a wrong answer in this case because the data would not survive node failure.
The second is the performance question. The scenario describes a workload that needs extreme I/O for caching or scratch data, where data loss on node failure is acceptable. The answer is Local SSD. The trade-off in the question (high performance, ephemeral) is exactly what Local SSD is for.
The third is the high-end performance question. The scenario calls out very high IOPS or throughput needs that go beyond ordinary database workloads. The answer is Hyperdisk, often Hyperdisk Extreme.
If you see "stateful database" in a GKE storage question, think Persistent Disk. If you see "caching" or "scratch space" with "high I/O," think Local SSD. If you see "extreme performance" or "high-end database," think Hyperdisk.
Persistent Disk is durable, the default, and right for most stateful workloads. Local SSD is fast and ephemeral, right for caching and scratch space. Hyperdisk is durable and high-performance, right for the most demanding workloads.
The Associate Cloud Engineer exam tests this through scenario matching. Identify whether durability is required and how high the performance bar is, and the storage type follows.
My Associate Cloud Engineer course covers GKE storage options in the cluster storage section, alongside Filestore for shared file access and how PersistentVolumeClaims map to the underlying disk types.
