Google Cloud · Associate
Google Cloud Certified - Associate Cloud Engineer
Pools and providers are soft-deleted and only permanently removed after ~30 days. Meanwhile you can't create another with the same ID, so a terraform destroy followed by apply with the same pool_id fails. The way out is to restore it (undelete) and import it, or use a different ID. For ephemeral environments, generate the ID with a suffix.
You can grant roles directly to the federated principal, without a service account. But some APIs have limitations with federated identities, and for those you have to impersonate a service account. This module impersonates: it works with everything and leaves a single place to audit permissions. For that path Google asks you to enable four APIs: IAM, Resource Manager, Service Account Credentials and Security Token Service.
When granting roles to external identities you use the project number, not the project ID: the principalSet is principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/.... Also, an IAM change usually applies within 2 minutes but can take 7 or more.
There are no endpoints to size: the policy reserves one internal IP from the primary range of every subnet in the VPC (except special-purpose ones), so a VPC with many subnets has many entry IPs. What matters for the response is the region of the tunnel or attachment the query arrived on, not the subnet's region. Put the policy on the VPC that has the VPN or Interconnect.
Every bucket has soft delete with 7-day retention unless you change it. An object that lives one hour is billed for that hour plus 7 days of soft delete. In a TTL ingestion bucket that can multiply cost. The module sets it to 0 (disabled) by default and exposes it as an explicit variable.
Same as Azure and S3, it isn't an exact TTL: an object meeting the condition may still exist for a while. If you need a deletion guarantee, do it from the application.
Overwriting an existing object requires storage.objects.delete, which objectCreator lacks. For ingestion that's a feature (a compromised producer can't clobber files), but it breaks clients that retry with the same name. In S3, s3:PutObject does overwrite.
UBLA disables per-object ACLs (equivalent to BucketOwnerEnforced in S3) and is required for IAM Conditions. Public access prevention "enforced" blocks allUsers/allAuthenticatedUsers (equivalent to Block Public Access).
The database user name is the SA email without the .gserviceaccount.com suffix (e.g. api@project.iam), due to PostgreSQL's name length limit. If you create it with the full email, login fails with an error that looks like a permissions problem.
google_sql_user with type CLOUD_IAM_SERVICE_ACCOUNT creates the user from Terraform, and you also need roles/cloudsql.client and roles/cloudsql.instanceUser on the SA. What remains SQL are table permissions (GRANT), same as on the other clouds.
Letra Chica