Access to data in AlloyDB depends on two separate layers, and a common Professional Cloud Database Engineer exam scenario tests whether you understand the gap between them. The first layer is Cloud IAM, which controls who can reach the AlloyDB resource in Google Cloud. The second layer is the set of permissions inside the database engine itself, which controls who can read or change the actual tables. A user can be fully set up at the IAM layer and still be unable to run a query, because the two layers grant different things.
Consider a user who already has the alloydb.databaseUser IAM role assigned. That role is the first step, because it lets the identity connect to the AlloyDB resource within Google Cloud. On top of that, the alloydb.iam_authentication flag is enabled on the instance. This is the configuration that allows the database to recognize and validate IAM-based identities, so the user can authenticate using their Google Cloud identity rather than a separate database password.
With both of those in place, you might expect the user to be able to read data. Instead, when they try to select from a table, they get a Permission denied error. The setup looks complete at the IAM layer, and the authentication path works, but the query is still blocked.
The reason is that IAM roles only control access to the Google Cloud resource, not the objects inside the database engine. The alloydb.databaseUser role and the IAM authentication flag get the identity connected and recognized, but they say nothing about which schemas and tables that identity is allowed to read. Table-level access lives entirely inside the database, and it is governed by standard database privileges rather than by IAM. So an identity that has connected successfully can still lack the privilege to read any given table.
To fix it, you issue a GRANT command inside the database for the specific schema and table that user needs. This is a standard database privilege grant, separate from anything you do in IAM.
GRANT SELECT ON schema.table TO user;Once that grant is in place, the user can read the table, because they now have both the IAM access that lets them connect and the database privilege that lets them query the object. If a user needs broader access than a single read, you grant the additional privileges they require on a wider scope. The following grants read and write privileges across every table in a schema at once.
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA schema TO user;The pattern is the same in both cases. You name the privileges, you name the object or scope they apply to, and you name the user receiving them.
The Professional Cloud Database Engineer exam uses scenarios like this to confirm that you can separate the two layers of access. When a user can connect and authenticate but still cannot read data, the missing piece is a database-level GRANT, not another IAM role. Full access to data in AlloyDB comes from combining Cloud IAM roles with standard database permissions. The IAM side gets the identity to the resource and validates it, and the GRANT inside the database authorizes the specific reads and writes. If you can recognize that a Permission denied error after a correct IAM setup points to a missing in-database grant, you can usually pick the right answer apart from options that add more IAM access instead.
Our Professional Cloud Database Engineer course covers granting SELECT permissions in AlloyDB alongside IAM database authentication and least-privilege role selection, with practice questions that drill these distinctions.
