Firestore handles indexing in a way that is mostly invisible until it isn't. Single-field indexes are created automatically for every field in every document. That works fine for small documents and simple queries. The moment you start querying across multiple fields, Firestore needs composite indexes, and the math behind those indexes can get out of hand quickly. The Professional Cloud Architect exam tests whether you understand the cost and performance implications of this, and whether you know how to manage indexes manually when defaults are not sufficient.
To answer a query that filters or orders by multiple fields, Firestore needs an index that covers exactly those fields in that order. Without it, the query fails. Firestore handles single-field indexing automatically, but for queries that span more than one field you need a composite index, and Firestore will build entries for every combination of values that exists in your data.
Take a jobListing document with five fields. Industry has six possible values across categories like Tech, Finance, Healthcare, Education, Government, and Consulting. Job Type has four values: Full-time, Part-time, Contract, Internship. Experience Level has four values from Entry through Executive. Location covers 300 cities. Salary Range has five buckets from $40k to $120k+. If you want to support filtering across all of these in a single composite index, the math is unforgiving.
6 industries x 4 job types x 4 experience levels x 300 cities x 5 salary ranges equals 144,000 combinations. Each one becomes an entry in the index. Multiply that by the number of documents that match each combination and you get an index that is dramatically larger than the underlying collection itself.
Two things go wrong when an index explodes. The first is storage cost, because every index entry takes space and Firestore bills for index storage the same way it bills for document storage. The second is write latency. Every time you insert or update a document, Firestore has to update every index entry that document touches. If a single document write triggers updates across thousands of composite index entries, your write throughput drops and your costs climb.
The default behavior of automatic single-field indexing is fine for most documents. The danger is in composite indexes that combine many high-cardinality fields. A field with 300 distinct values like Location is the kind of thing that drives the combinatorial blow-up, and combining several such fields in one composite index is what produces the explosion.
The fix is to be deliberate about which composite indexes you actually need. Firestore lets you define indexes in a configuration file, typically YAML, and you only declare the combinations your application queries. If your app never filters by Industry plus Location plus Salary together, you do not need that composite index. If it only filters by Industry plus Job Type, you only declare that one.
You can also exempt specific fields from automatic indexing. If a field is never used as a filter or sort key, exempting it from indexing reduces both storage and write overhead. This matters most for fields that contain large strings or arrays, because those generate disproportionately large index entries.
The standard workflow uses gcloud. Once you have your indexes.yaml file defining the indexes you want, you deploy with:
gcloud firestore indexes create indexes.yamlFor composite indexes specifically, the command is:
gcloud firestore indexes composite create indexes.yamlIf you run a query that needs a composite index that does not exist, Firestore returns an error and includes a link in the error message that takes you directly to the console with a pre-filled index definition. That is convenient for development, but in production you want indexes defined in version-controlled YAML and deployed through your normal release process.
Professional Cloud Architect exam questions on Firestore indexing tend to fall into a few categories. One is recognizing the symptoms of an exploding index from a scenario description. If a question describes Firestore costs growing faster than the document count or writes slowing down as the application matures, exploding indexes are a likely culprit. The remediation is manually configuring the index file to exclude unused composite indexes and exempt high-cardinality fields that are not used in queries.
Another category involves recognizing when a composite index is needed. If a query filters or orders by multiple fields and the question shows the query failing, the answer is to create a composite index covering those fields. The keyword composite in the gcloud command matters because it distinguishes index creation for multi-field queries from single-field configuration.
The Professional Cloud Architect exam also expects you to know that index management is a per-database concern, defined declaratively in YAML, and applied through gcloud or Terraform rather than through ad-hoc console clicks. The configuration file model is the same pattern Google uses across many services, and Firestore indexing is one of the cleaner examples of it.
My Professional Cloud Architect course covers Firestore exploding indexes and composite index design alongside the rest of the databases material.
