Google Cloud ACE: Configuring access and security Practice Questions

The correct answer is to check resource-level IAM bindings on the secret. Secret Manager supports resource-level access control in addition to project-level bindings. Even if a service account has the secretAccessor role at the project level, explicit allow policies on individual secrets can further restrict access. If the secret denies the service account, the role grant at the project level won't override it. If the API were disabled, the error would indicate API_NOT_ENABLED. Key storage and disk space are unrelated to Secret Manager access permissions.

roles/compute.viewer is the correct answer because it provides read-only access to Compute Engine resources, including the ability to list and view instances, without modification permissions. This follows the principle of least privilege. roles/compute.instanceAdmin allows full instance management (create, modify, delete), which is excessive for read-only access. roles/editor and roles/owner are primitive roles that grant far too many permissions across all services, violating least privilege principles.

The correct answer is option 2. Organization policy constraints enforced at the organization level apply to all projects within that organization, and the exceptions (allow list) apply only at the level where the constraint is defined or lower. However, the key point is that if a constraint is enforced (blocklist mode) at the organization level, project-level exceptions cannot override it unless explicitly configured in the policy. In this case, the constraint is set to disable service account creation, and an exception at the project level would be needed in the policy itself—just having the exception granted isn't sufficient if the constraint is in enforcement mode at a higher level. Option 1 is incorrect because roles/iam.admin does include permissions to create service accounts (iam.serviceAccounts.create). Option 3 is incorrect because the user has the iam.admin role, which is the correct IAM role for this operation. Option 4 is incorrect and illogical. Option 5 is incorrect because roles/editor is not required; iam.admin is the correct role.

The correct answer is option 2. Workload Identity requires that the Kubernetes Service Account (KSA) be annotated with iam.gke.io/gcp-service-account=<gsa-email> to establish the linkage. Without this annotation, the KSA cannot authenticate as the Google Service Account (GSA), even if IAM bindings are correct. Option 1 is wrong; the names do not need to match exactly (they can be different). Option 3 describes the IAM binding requirement (roles/iam.workloadIdentityUser must be granted), which is necessary but not sufficient; the annotation is the missing piece in this scenario. Option 4 is incorrect; Workload Identity on GKE does not use a Workload Identity Pool (which is a separate federated identity feature). Workload Identity on GKE uses metadata server token exchange.

The correct answer is option 2. Reading secret data (the actual content of a secret version) is classified as a data access operation and is logged in Cloud Audit Logs' Data Access Logs. Admin Activity Logs (option 1) record administrative actions like creating/deleting resources, changing IAM policies, and managing service account keys—not reading data. Data Access Logs capture reads of actual data resources, such as reading BigQuery tables, Cloud Storage objects, or Secret Manager secret versions. System Event Logs (option 3) are a separate category for system-level events and are not relevant here. Option 4 is incorrect because only Data Access Logs are used for this operation.