Firestore access control on Google Cloud is one of those topics that looks straightforward on the surface but trips people up on the Professional Cloud Architect exam because the role names do not match the product name. You manage Firestore through Datastore roles. That history quirk matters for the exam, and it matters when you are wiring up IAM in production.
Firestore evolved from Datastore, and the IAM roles kept their original names even after the rebrand. When you grant access to a Firestore database in Google Cloud, you are picking from roles prefixed with roles/datastore.*. There is no roles/firestore.admin in the predefined role list, and that catches people off guard when they search the IAM console for the first time.
I cover this on the Professional Cloud Architect material because it is the kind of detail that shows up in scenario questions. A question will describe a team needing read-write access to Firestore data, and the correct answer will reference Datastore User. If you do not know the mapping, you will second-guess yourself.
Four predefined Datastore roles handle Firestore access at the database level.
Datastore Admin grants full control. Anyone with this role can manage the database, read and write data, configure indexes, and perform administrative operations. This is the role you give to platform engineers who own the Firestore deployment.
Datastore User grants read and write access to data without administrative privileges. Application service accounts typically get this role. They need to query and update documents, but they do not need to create indexes or change database settings.
Datastore Viewer grants read access to Firestore data and metadata. Use this for monitoring tools, auditing workflows, or analysts who need to inspect data without modifying it.
Datastore Index Admin grants the ability to manage Firestore indexes without broader access to the underlying data. This is a narrow role for teams that handle index optimization separately from application development.
Firestore can also be reached through broader Firebase roles. This matters because Firestore is part of the Firebase product family, and projects that use multiple Firebase services often grant access at the Firebase level rather than picking individual product roles.
Firebase Admin provides full control over all Firebase services in the project, including Firestore. A user with this role can do everything Datastore Admin can do, plus they can manage Authentication, Cloud Functions, Hosting, and other Firebase products.
Firebase Viewer grants read-only access across all Firebase products, including Firestore. This is the equivalent of Datastore Viewer for someone who needs visibility across the whole Firebase project.
When the Professional Cloud Architect exam presents a Firestore access scenario, look at two things. First, what is the principal trying to do. Read-only, read-write, or administrative. Second, what is the scope. Just Firestore, or Firestore plus other Firebase products.
If a service account needs to write documents to Firestore and nothing else, Datastore User is the right answer. If a developer needs full control of the database and the indexes, Datastore Admin works. If a security team needs read-only visibility across Firestore plus Cloud Functions and Authentication, Firebase Viewer is the better fit because it spans the whole Firebase surface.
The trap on the exam is picking a role that is too broad. Firebase Admin technically works for someone who needs to manage Firestore, but it grants far more than necessary. The principle of least privilege applies, and exam questions reward the narrowest role that satisfies the requirement.
My Professional Cloud Architect course covers Firestore predefined roles alongside the rest of the databases material.
