What documented procedure should a customer use for this PostgreSQL 18 role lifecycle on Cloud SQL?
- A database is owned by an existing custom NOLOGIN role. If I create a fresh built-in operator with just that role in the Admin API’s
databaseRoles, what direct role attributes and membership options does the operator receive? Can I obtain inherited owner privileges with SET and ADMIN disabled on that membership? If the operator also needs direct CREATEROLE, which supported operation and customer-controlled principal can grant it without granting broader administrator privileges? - The operator creates a restricted monitoring login and grants it CONNECT. PostgreSQL records the database owner as the grantor and automatically gives the creator administrative membership in the new login. Can an independent Cloud SQL administrator delete the temporary operator through the Admin API while preserving the monitoring role, its OID and the owner-issued CONNECT? What dependencies or permission checks could prevent deletion, and how can the administrator verify the outcome?
- After that operator is gone, which customer-controlled principal can disable new logins for the SQL-created monitoring role, and which permissions are needed to close only its existing sessions if required? Is there a documented, reversible control-plane operation equivalent to ALTER ROLE NOLOGIN for a built-in PostgreSQL user?
References to official guidance for the required Google Cloud IAM permissions and the separate PostgreSQL privileges would help. The goal is to preserve the original NOLOGIN owner and avoid a standing provisioning administrator.