Bigtable instance configuration shows up on the Professional Data Engineer exam in a predictable shape. You get a workload description, sometimes a budget hint, sometimes a latency requirement, and you have to pick the right instance type, storage type, location, and scaling strategy. None of these choices are hard individually, but the exam likes to bundle them into a single scenario where one wrong answer disqualifies the whole option. I want to walk through each of the four configuration decisions the way I think about them when I read a PDE question.
Bigtable offers two instance types and the difference is bigger than it sounds. A Development instance runs on a single node. It is cheap, it has no replication, and it carries no throughput guarantee. The intended use is testing, prototyping, or local experimentation where you do not care if a node restart blocks your workload for a minute. The exam will sometimes describe a team building a proof of concept, evaluating Bigtable for a future migration, or running an internal demo. That is your signal for Development.
A Production instance is the opposite. It supports one or more clusters, with three or more nodes per cluster, replication is available across those clusters, and you get a throughput guarantee. If the question mentions service level objectives, high availability, or any kind of operational workload, the answer is Production. The exam loves to throw in a distractor where Development sounds attractive because of the cost savings. If the scenario describes anything customer-facing or anything with an availability requirement, Development is wrong no matter how good the price looks.
The storage type decision is binary and the rule is almost embarrassingly simple. SSD is the right answer in nearly every scenario. The only time HDD wins is when all three of these are true at once: the dataset is larger than 10 TB, it is accessed infrequently, and latency is not a concern. If even one of those conditions is missing, you pick SSD.
On the exam, this means you are reading the question for disqualifying signals. Any mention of low-latency reads, real-time serving, or interactive queries kills HDD immediately. A workload described as analytical batch processing over a large archive that nobody touches between monthly runs is the rare HDD scenario. If the question does not explicitly call out infrequent access and tolerance for latency, default to SSD and move on. I have seen candidates get tripped up because they assumed cost-optimization always means HDD. Bigtable is not Cloud Storage, and HDD on Bigtable is a narrow optimization.
Bigtable clusters are zonal resources, which has two consequences worth memorizing. First, the zone you pick at creation time cannot be changed later. If you put your cluster in us-central1-a and then realize most of your traffic comes from Europe, you do not move the cluster. You create a new one and migrate, or you add a cluster in a European zone via replication. Second, if the zone goes down, that cluster goes down with it.
The exam framing here is usually about latency or availability. For latency, you place the cluster in a zone close to the services and users that hit it most. If the application runs in europe-west1, the cluster belongs in europe-west1. For availability, you add a second cluster in a different zone as part of the same Bigtable instance and rely on replication. That second cluster might be in a different region entirely if you need geographic redundancy. A question that mentions a region-wide outage tolerance is asking about multi-region replication. A question that mentions tolerating a single zone failure can be answered with two clusters in two zones of the same region.
Bigtable scales horizontally, which is worth saying out loud because the exam sometimes hides a vertical-scaling distractor in the answer choices. You scale by adding nodes, not by making nodes bigger. Each node handles a portion of the data, so adding nodes improves write throughput and lets the cluster absorb more concurrent traffic.
Manual scaling is exactly what it sounds like. You decide when to add or remove nodes. This is the right answer when the workload is predictable, when you want tight control over cost, or when the question describes an operator who plans capacity changes ahead of a known event like a marketing launch.
Automatic scaling is the more common exam answer when the workload is variable. You configure four things: a minimum node count, a maximum node count, a target CPU utilization, and a target storage utilization. The minimum and maximum are hard limits Bigtable will not cross. Bigtable monitors the actual CPU and storage and adds or removes nodes when those metrics drift away from the targets. The exam tests whether you know that autoscaling respects the min and max as hard caps, that it reacts to both CPU and storage signals, and that it works within a single cluster rather than across clusters.
The trick to Bigtable configuration questions on the Professional Data Engineer exam is that they almost always test two or three of these dimensions at once. A scenario might describe a production workload serving real-time reads from a North American user base with bursty traffic. The right answer combines a Production instance, SSD storage, a us-region cluster, and automatic scaling. A wrong answer might get three of the four right and bury HDD in the choice to disqualify it. Read each answer choice for any single disqualifying configuration before you commit.
My Professional Data Engineer course covers Bigtable instance configuration alongside the schema design, replication, and performance-tuning topics that show up next to it on the exam, so you can answer these scenario questions without second-guessing the trade-offs.
