Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Manage Secure Connectivity and Access Auditing is the practice of encrypting database connections in transit and recording who accessed data and controls. Cloud SQL (opens in a new tab) protects connections with network controls plus SSL/TLS encryption, while Cloud Audit Logs (opens in a new tab) record administrative operations on the instance. Engine-level logs record SQL operations inside the database that control-plane audit logs do not capture.
Secure database connections with SSL/TLS in Cloud SQL protect data moving between database clients and database instances from interception or alteration. Cloud SQL encrypts and authenticates all data in transit at one or more network layers when data moves outside physical boundaries controlled by Google or on behalf of Google. Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but might not be encrypted by default, so internal traffic may still need SSL based on threat model.
Clients reach a Cloud SQL for PostgreSQL instance through an authorized static IP address with a PostgreSQL client or through Cloud SQL Proxy, and both paths still benefit from transit encryption. SSL can be configured for intra-zone connections when internal traffic also requires encryption. Because encryption at rest with 256-bit Advanced Encryption Standard (AES-256) or better is automatic, SSL/TLS closes the remaining gap for data moving over networks.
Auditing access with Cloud Audit Logs answers who did what, where, and when for Google Cloud resources. For Cloud SQL, Cloud Audit Logs audit administrative and maintenance operations done on an instance, such as creating users, changing instance settings, and enabling Identity and Access Management (IAM) database authentication. Login information for IAM database users can be viewed in audit logs, which helps identify failed logins and unauthorized access attempts.
Centralized auditing depends on collecting the right logs and keeping them long enough for review. Sharing audit logs from Cloud Identity brings user login events from the Google Admin console into Google Cloud for central management, while enabling Data Access audit logs and auditing of administrator activity increases visibility into reads and configuration changes. Exporting logs to a log sink supports long-term storage and retention for compliance, while Access Transparency logs record access by Google support and engineering personnel alongside Access Approval, which requires explicit approval before Google employees access data.
Database-engine audit signals in Cloud SQL record SQL operations performed inside the database, which Cloud Audit Logs alone do not capture. The engine mechanism depends on the database type, so PostgreSQL and MySQL use different tools to track data manipulation language (DML) and data definition language (DDL) activity.
The following mechanisms map each engine to its audit tool and captured activity:
| Engine | Audit mechanism | What it captures |
|---|---|---|
| Cloud SQL for PostgreSQL | pgAudit extension | SQL operations performed against a given database instance |
| Cloud SQL for MySQL | Slow-query, general, and error logs enabled with instance FLAGS | DML/DDL operations, connection and query activity, and server errors |
For MySQL, the slow-query log and general log are enabled through instance FLAGS, and retention for these logs should be managed according to business needs. For PostgreSQL, pgAudit tracks statement-level operations needed to review user activity inside tables. Together, Cloud Audit Logs show control-plane changes to the instance, while pgAudit or MySQL logs show what users did inside the database.
Exam tip: Cloud Audit Logs track administrative operations on the Cloud SQL instance, while pgAudit and MySQL slow-query, general, and error logs track SQL operations inside the database.
Granular authorization and role-based access control (RBAC) in Google Cloud means granting no more access than a principal needs by mapping cloud-level roles to database-level privileges. Cloud SQL (opens in a new tab) uses Identity and Access Management (IAM) to control who can reach a project, folder, or instance, while the database engine controls what that identity can do to schemas, tables, and views. BigQuery (opens in a new tab) uses layered grants from organization down to tables and views to shrink access to the lowest needed level. A principal must pass both cloud and database layers to read or change data.
IAM authorization for databases is built from principals, roles, and resources. Permissions are never granted directly to a person; permissions are grouped into roles, and roles are granted to principals on a resource through an allow policy. When a principal holds multiple roles, the effective permissions are the union of all of the roles.
Cloud SQL IAM policies use three principal types:
A role granted on an organization, folder, or project is inherited by all child resources. By default, a Cloud SQL IAM binding applied at the project level gives permissions on all Cloud SQL instances in that project, so scoping the binding to the lowest needed level is central to least privilege.
Cloud roles for databases come in predefined, custom, and basic forms with different levels of granularity. Cloud SQL provides predefined roles designed for Cloud SQL resources, including the Cloud SQL Instance User role that contains the cloudsql.instances.login permission required to log in to an instance. Custom roles contain a customer-specified list of permissions and are used when predefined roles do not match the needed task or when role definitions must remain unchanged over time.
Legacy basic roles such as Owner, Editor, and Viewer still exist but do not provide the same fine-grained control. A basic role grants access across Google Cloud rather than only for Cloud SQL, so a principal receives far more permissions than needed for database work. Choose a predefined role for common database tasks, choose a custom role when least privilege requires a narrower permission set, and avoid basic roles for database-only access.
Mapping an IAM role to database privileges in Cloud SQL requires two separate grants because IAM login and database authorization are enforced by different systems. IAM verifies identity with an access token and checks the cloudsql.instances.login permission on the instance, while the MySQL or PostgreSQL engine checks its own GRANTs or roles on databases, tables, and columns. A principal who can log in but has no database privileges still cannot read or write data, and a principal with database privileges but no IAM login permission cannot connect through IAM database authentication.
Access is provisioned in an ordered sequence:
cloudsql.instances.login, typically at the project level for all instances or more narrowly when supported.The instance depends on the IAM allow policy for connection, and the data depends on the engine-level grant for use. Removing either layer revokes effective access, which is why administrators manage both together.
Individual accounts versus group authentication describes two ways to manage IAM database authentication in Cloud SQL. Built-in authentication uses a database username and password stored in the engine, while IAM database authentication uses a short-lived IAM access token tied to the Google identity. Individual IAM management adds each user and service account to the instance and maintains privileges separately, which gives precise control but grows harder to maintain as teams change.
Group authentication assigns IAM roles and database privileges once to a Cloud Identity group, and all users and service accounts in that group inherit both the IAM login permission and the database privileges. Adding or removing a person from the group automatically changes what that person inherits without editing every instance. Choose individual bindings when a few distinct identities need different privileges, and choose group bindings when a team shares the same job function and should gain and lose access together.
The following options compare credential type and how access is granted:
| Option | Credential | How access is granted |
|---|---|---|
| Built-in authentication | Database username and password | Privileges are granted directly to the database user inside the engine |
| IAM authentication individually | IAM access token for the user or service account | IAM login role is bound to each identity, then database privileges are granted to each identity on the instance |
| IAM authentication by group | IAM access token inherited through group membership | IAM login role and database privileges are granted to the Cloud Identity group, then inherited by all members |
Layered granularity in BigQuery is achieved by granting a role at the lowest resource level that still allows the job to be done. A BigQuery role granted on an organization, folder, or project applies to all BigQuery resources inside that container, including every dataset, table, view, and routine. A role granted at the dataset level provides access to only that specific dataset without giving access to other datasets in the same project, and finer grants can target individual resources within datasets such as tables, views, and routines, plus resources such as connections, saved queries, and pipelines.
This layering directly implements least privilege because moving the binding down the hierarchy shrinks the blast radius. A principal who only needs one dataset receives a dataset-level role rather than a project-level role that would expose every dataset in the project. BigQuery predefined roles support common patterns, while custom roles support exact permission sets when predefined roles are too broad or when new permissions added to predefined roles must not automatically expand access.
Exam tip: The cloudsql.instances.login permission allows connection to a Cloud SQL instance but does not grant SELECT, INSERT, or other data privileges; database privileges must still be granted inside the engine.
Authentication mechanisms determine how a database client proves its identity to Cloud SQL, AlloyDB for PostgreSQL (opens in a new tab), and Spanner before it can run queries. Cloud SQL (opens in a new tab) and AlloyDB support both built-in and Identity and Access Management (IAM) methods, while Spanner uses IAM authentication for clients. Built-in database authentication verifies a username and password stored inside the database, while IAM database authentication verifies a Google Cloud principal with a short-lived token.
Built-in database authentication is password authentication managed inside the database engine itself. The client connects with a database username and password, and authorization inside the database is determined with GRANT or REVOKE statements. User creation, password rotation, and privilege changes are manual on each instance, and network encryption with SSL is not required by this method. Choose built-in authentication when the application needs simple database-local accounts or must coexist with existing password-based logins.
IAM database authentication is token-based authentication that reuses Google Cloud identities instead of database passwords. The principal is a user account or service account for applications, the role grants login permission, and the resource is the AlloyDB cluster or Cloud SQL instance. A principal needs alloydb.instances.login for AlloyDB, included in the AlloyDB Client role (roles/alloydb.client), or cloudsql.instances.login for Cloud SQL, included in the Cloud SQL Instance User role. IAM policy bindings are applied at the project level, so the principal receives login rights for instances in that project.
IAM database authentication provides three related benefits for Cloud SQL and AlloyDB:
Tokens are valid for only one hour, and login with IAM database authentication can only be performed over an SSL connection. For AlloyDB, TLS 1.3 protects traffic between the database instance and clients, and the server certificate is generated automatically by AlloyDB.
Individual and group IAM management are two ways to scope who can obtain an IAM database token for Cloud SQL and AlloyDB. Individual IAM authentication adds specific users or service accounts to the cluster or instance, which is useful for direct grants to a few accounts. Group IAM authentication adds a Cloud Identity group to the cluster or instance, and all members of that group inherit the ability to authenticate without adding each account at the database level.
Group membership controls both login and database privileges through inheritance. When a user joins a group that already has IAM login permission, the user gains the ability to sign in to the AlloyDB cluster or Cloud SQL instance and automatically inherits database privileges granted to the group. AlloyDB creates a database account for that principal on first sign-in, while Cloud SQL creates the account after first login, and each person still signs in with individual credentials so audit logs show which account performed each action. When a user leaves the group, the user loses inherited database privileges, although propagation takes time and the user may still sign in if another group still grants login permission.
Cloud SQL enforces specific group limits and separation between account types. A Cloud SQL instance supports a maximum of 200 IAM groups, changes to Cloud Identity group membership take about 15 minutes to propagate in addition to IAM propagation time, and an account cannot exist as both an individual IAM user and a group member on the same instance. AlloyDB group authentication is in Preview for new clusters and follows the same pattern of granting roles once to the group and managing access by adding or removing members.
Automatic and manual IAM database authentication are two ways to deliver the temporary token from IAM to the database for Cloud SQL and AlloyDB. With automatic IAM database authentication, an intermediary connector requests and manages access tokens on behalf of the client, so the application passes only the IAM database username and the connector submits the token in the password field. With manual IAM database authentication, the IAM principal signs in to Google Cloud, explicitly requests the access token, and passes the token as the password using the email address as the username.
The connector path depends on the service but follows the same flow from client to IAM to database. For Cloud SQL, automatic authentication requires a Cloud SQL connector such as the Cloud SQL Auth Proxy or the Go, Java, or Python connectors. For AlloyDB, automatic authentication uses the AlloyDB Auth Proxy or an AlloyDB Language Connector, which authorizes the connection with IAM and protects it with mutual TLS. The Auth Proxy runs as a client-side proxy that upgrades connections to TLS 1.3, while Language Connectors are client libraries that connect to a proxy server on the AlloyDB cluster.
Manual connections can use a direct database connection or a connector, but the token must be refreshed by the caller. Because OAuth 2.0 tokens expire after one hour, new connections after that time fail unless a fresh token is supplied. Automatic authentication is strongly recommended for long-lived processes and applications that rely on connection pooling because the connector requests and refreshes tokens to keep pooled connections stable. If context-aware access is used in the IAM configuration, a connector cannot be used with IAM database authentication and the client must connect directly to the instance instead.
Choosing authentication means matching credential lifecycle, management scale, and encryption requirements to the workload running on Cloud SQL, AlloyDB, or Spanner. Built-in authentication keeps access local to one database with manual password handling, while IAM authentication centralizes identity in Google Cloud and requires encrypted connections and token handling.
The following options compare method, encryption, and management:
| Authentication option | Authentication method | Network encryption | User management |
|---|---|---|---|
| Built-in database authentication | Password | SSL not required | Manual per instance |
| IAM database authentication, individual | Temporary authentication token | SSL required | Centralized through IAM |
| IAM database authentication, group | Temporary authentication token | SSL required | Centralized through IAM and Cloud Identity groups |
Choose built-in authentication when the application has a small, stable set of database-local accounts or must support legacy password logins alongside IAM users. Choose individual IAM authentication when a few human users or service accounts need audited, short-lived access without extra passwords. Choose group IAM authentication when teams change often, because adding a user to the Cloud Identity group grants inherited roles and database privileges and removing the user revokes them. For Cloud SQL, IAM access also depends on the cloudsql_iam_authentication flag for MySQL or the cloudsql.iam_authentication flag for PostgreSQL; the flag is enabled by default for instances created in the console, does not block existing password users, but disabling it removes access for previously added IAM users.
Exam tip: IAM database tokens are valid for only one hour, so use automatic authentication with the Auth Proxy or Language Connectors for pooling and long-lived apps; manual tokens fail for new connections after expiry.
cloudsql.instances.login permission allows connection to a Cloud SQL instance but does not grant data privileges, which must still be granted inside the database engine.Last updated