Firestore secures data at rest with Google-managed encryption by default, but that protection only covers the bytes sitting on disk. The moment your application reads a field back out, it is plaintext again. For sensitive values like payment card numbers, that default model is not enough, and the Professional Cloud Architect exam expects you to know what to reach for instead.
The answer the exam wants is deterministic encryption, and it is worth understanding why this specific flavor of encryption shows up in Firestore architecture questions.
Deterministic encryption is an encryption scheme where the same plaintext input always produces the same ciphertext output. If I encrypt the card number 4111-1111-1111-1111 today and again tomorrow with the same key, I get the same encrypted blob both times.
That property sounds mundane until you think about what it lets you do. Because identical inputs map to identical encrypted values, a database can perform equality comparisons on the ciphertext directly. You can ask Firestore "find me the document where the encrypted card number equals this encrypted value" without ever decrypting anything. The comparison happens on encrypted bytes, and the answer is still correct.
That is the whole point. You get the privacy of encrypted storage and the queryability of plaintext, at least for equality checks.
Firestore is built for low-latency reads. A typical workload looks up a document by a field value, expects an answer in tens of milliseconds, and returns it to a user-facing application. Decrypting every candidate document to find a match would destroy that latency profile and force you to pull far more data out of Firestore than you actually need.
Deterministic encryption sidesteps that problem. The application encrypts the lookup value once, queries Firestore for documents whose encrypted field matches, and reads only the matches. Duplicate detection works the same way. If two users submit the same card number, the encrypted values collide, and you can flag the duplicate without ever holding the plaintext for comparison.
This is exactly the pattern the exam is testing when it presents a Firestore scenario involving sensitive data plus equality lookups.
One detail worth being precise about: the encryption is applied in your application code, before the data reaches Firestore. Firestore itself does not offer a deterministic encryption feature you flip on. You bring your own encryption library, your own key, and you encrypt the field on the way in and decrypt it on the way out.
The flow looks like this. A user submits a card number. Your application code applies deterministic encryption using a key managed in Cloud KMS or an equivalent service. The encrypted value is what gets written to the Firestore document. When the application later needs to look up that record, it encrypts the query value with the same key and queries against the stored ciphertext.
Firestore is just storing bytes. The cryptography is your responsibility, which means key management is also your responsibility.
Because the same key produces the same ciphertext for the same input, the key becomes the single most sensitive piece of the system. If it leaks, the determinism that makes the scheme useful also makes it easy for an attacker to build a lookup table and reverse encrypted values back to plaintext.
That is why key rotation matters here, especially under compliance regimes like PCI DSS for payment data. You rotate the key on a schedule, re-encrypt existing data under the new key, and retire the old one. Cloud KMS handles the mechanics of versioned keys and rotation policies, but the application has to be aware of which key version each stored value was encrypted under so it can decrypt or re-encrypt correctly.
Deterministic encryption is not the strongest form of encryption available. Non-deterministic schemes add randomness, so the same plaintext encrypts to different ciphertexts each time. That is more secure against pattern analysis, because an attacker who sees your encrypted database cannot tell which records share a value.
The cost is that you lose the ability to query by encrypted value. You would have to decrypt every candidate to compare it, which defeats the latency story that drove you to Firestore in the first place.
For a Professional Cloud Architect question framed around Firestore, payment data, and equality lookups, deterministic encryption is the answer. The exam is asking you to recognize that the use case requires queryable encrypted data, and that this specific scheme is what enables it.
Deterministic encryption produces consistent ciphertext for the same plaintext input, which lets Firestore perform equality comparisons on encrypted fields. The encryption happens in application code outside Firestore, the keys live in Cloud KMS, and key rotation is required for compliance. The trade-off is reduced randomness compared to non-deterministic encryption, but that trade-off is worth it when the workload demands fast duplicate detection or low-latency lookups against sensitive fields.
If a Professional Cloud Architect scenario describes a Firestore-backed system storing card numbers or similar sensitive identifiers and asks how to enable secure equality queries, deterministic encryption is the pattern being tested.
My Professional Cloud Architect course covers deterministic encryption in Firestore alongside the rest of the databases material.
