
Explanation:
The error message indicates that Terraform is unable to access the Cloud Storage bucket where the state file is supposed to be stored, due to a permissions issue (Error 403). This is a common scenario when the service account used by Cloud Build does not have the necessary permissions to access the bucket. Option A suggests using local state, which is not a Google-recommended practice for production environments as it lacks the benefits of remote state like locking and collaboration. Option B suggests creating a storage bucket, but the error is about permissions, not the absence of a bucket. Option C suggests granting the roles/owner role, which is overly permissive and against the principle of least privilege. Option D is the correct approach as it grants the Cloud Build service account the necessary permissions (roles/storage.objectAdmin) to access the state file bucket, following Google-recommended practices by applying the principle of least privilege.
Ultimate access to all questions.
No comments yet.
You are deploying a Cloud Build job that executes Terraform code upon a Git branch update. During testing, the job fails with the following error in the logs:
Initializing the backend...
Error: Failed to get existing workspaces: querying Cloud Storage failed: googleapi: Error 403
Initializing the backend...
Error: Failed to get existing workspaces: querying Cloud Storage failed: googleapi: Error 403
To resolve this issue while adhering to Google-recommended practices, what steps should you take?
A
Change the Terraform code to use local state.
B
Create a storage bucket with the name specified in the Terraform configuration.
C
Grant the roles/owner Identity and Access Management (IAM) role to the Cloud Build service account on the project.
D
Grant the roles/storage.objectAdmin Identity and Access Management (IAM) role to the Cloud Build service account on the state file bucket.