When the Professional Cloud Architect exam asks about Firestore performance, the question is rarely about indexes or pricing. It is about whether you understand how to fetch data with the fewest API calls. The answer almost always involves two concepts that travel together: key objects and batch get operations.
A key object uniquely identifies a single entity in Firestore. It has two parts: the kind, which is the type of entity, and either a numeric ID or a string name. So client.key("Task", 12345) points at a specific Task entity by its numeric ID, and client.key("User", "john_doe") points at a specific User entity by its string name. Both forms are valid identifiers.
The reason key objects matter is that they let Firestore go directly to an entity without running a query. A query searches across entities of a given kind and applies filters. A key lookup skips all of that and pulls the exact entity you asked for. It is the difference between asking the database to find something and telling the database where it already is.
If you already have several keys in hand, the natural next move is to retrieve all of them at once. That is what batch get does. Instead of calling Firestore once per key and paying the network round trip every time, you assemble a list and send it in a single request.
keys = [
client.key("Task", 12345), # Key for Task with ID 12345
client.key("Task", 67890), # Key for another Task with ID 67890
client.key("User", "john_doe") # Key for User with name "john_doe"
]
# Perform a batch get operation
entities = client.get_multi(keys)
The client app builds a list of key objects, hands it to get_multi, and Firestore returns all the matching entities in one response. Three lookups, one API call. The flow on the wire is a single batch request out and a single batch response back, regardless of how many keys are in the list.
The efficiency gain comes from three places. First, fewer API calls means less overhead per request, since each call carries authentication, headers, and connection setup costs that do not scale with the number of entities you actually want. Second, latency drops because Firestore processes the request in one operation rather than handling sequential queries that each wait for the previous response. Third, this approach scales well when an application needs to retrieve large numbers of entities at once, which is the common case in real workloads.
The catch, and the thing that distinguishes batch get from a query, is that batch get only works when the application already knows the entity IDs. If you need to find entities matching a filter, batch get does not help, because you do not yet have the keys. Batch get is the right tool when the keys are already in memory, in a session, or returned from a prior lookup.
Exam questions on Firestore efficiency tend to describe a scenario where an application is making many individual reads and the architect needs to reduce latency or API call volume. The trap answer is to add caching or change the database. The right answer, when the IDs are already known, is to combine the lookups into a single batch get request using key objects. If you see a scenario with known entity IDs and a goal of reducing API calls or improving retrieval performance, batch get is what the question is testing.
The mental model I would lock in for the Professional Cloud Architect exam is this: when the application has the keys, use a batch get. When it needs to discover entities by their attributes, use a query. The two are not interchangeable, and Firestore performance questions almost always come down to which one fits the scenario.
My Professional Cloud Architect course covers efficient data retrieval in Firestore alongside the rest of the databases material.
