GCP ACE Configuring access and security: 77 practice questions

12 of the 77 Configuring access and security questions in the Certsqill GCP ACE bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for GCP ACE? Take the free 5-min readiness check →

1. The action is denied because an IAM Deny policy takes: What happens?

1. The action is allowed because the Folder-level roles/editor grant includes storage.objects.create, and Folder grants inherit down

   Incorrect. While IAM allow policies do inherit down the hierarchy (Folder editor to Project permissions), IAM Deny policies take precedence over all allow policies. The explicit deny at the Project level overrides the inherited allow from the Folder.
2. The action is denied because an IAM Deny policy takes precedence over allow bindings at any level of the resource hierarchy ✓

   Correct. IAM Deny policies were introduced to explicitly block specific permissions regardless of allow policies. When an IAM Deny policy denies a permission, that deny takes precedence over any allow bindings at any level of the resource hierarchy. The project-level deny on storage.objects.create prevents the action.
3. The action is denied because Project-level policies always override Folder-level policies regardless of deny policies

   Incorrect. In standard IAM allow policy inheritance, more specific (lower in hierarchy) allow policies do not 'override' broader ones - they are additive. The reason the action is denied is specifically because of the IAM Deny policy, not because project policies override folder policies in general.
4. The action is allowed because the Organization-level viewer role provides baseline access that cannot be revoked at lower levels

   Incorrect. IAM allow policies are additive and inherited (you can't revoke an inherited allow via another allow), but IAM Deny policies can explicitly block permissions at any level. The deny policy overrides the viewer role's permissions.

IAM Deny policies explicitly block permissions and take precedence over all allow bindings regardless of where in the resource hierarchy the allow was granted.

2. Workload Identity Federation: What is the Google-recommended alternative?

1. Use a user-managed service account key file rotated every 30 days by a Cloud Scheduler job

   Incorrect. Rotating keys reduces exposure but still requires creating, distributing, and managing JSON key files; Workload Identity removes keys entirely and is fundamentally safer.
2. Grant the GKE node's default service account broad Cloud Storage read permissions for all Pods

   Incorrect. Granting broad rights to the node's default service account breaks least privilege and gives every Pod on the node the same access, which is a security anti-pattern.
3. Workload Identity Federation, which binds a Kubernetes Service Account to a GCP Service Account ✓

   Correct. Workload Identity is the recommended way for GKE workloads to authenticate to GCP services. It binds a Kubernetes Service Account (KSA) to a GCP Service Account (GSA) without the need to create, distribute, or rotate JSON key files. Pods using the KSA automatically get tokens for the GSA.
4. Store the service account JSON key in Cloud Secret Manager and fetch it at container runtime

   Incorrect. Secret Manager is better than baking keys into images, but it still means managing a downloadable key; Workload Identity eliminates the key file altogether.

Workload Identity binds a Kubernetes Service Account to a GCP Service Account, enabling GKE Pods to authenticate to GCP APIs without managing JSON key files.

3. Customer-Managed Encryption Keys using Cloud KMS: Which encryption option should they configure?

1. Customer-Supplied Encryption Keys (CSEK)

   Incorrect. CSEK allows customers to provide their own AES-256 key directly in API requests for Cloud Storage and Compute Engine persistent disks. However, CSEK is not supported by BigQuery. Additionally, CSEK keys are not stored by Google and must be provided with every request, making it operationally complex.
2. Google-managed encryption keys (default encryption)

   Incorrect. Google-managed encryption is the default for all GCP services and provides strong encryption at rest. However, the customer has no control over the keys — they cannot rotate, view, or revoke them. This does not meet the stated requirement for customer control.
3. Client-side encryption before uploading to Cloud Storage

   Incorrect. Client-side encryption means the customer encrypts data before sending it to GCP. While this gives key control, it requires building and maintaining an encryption layer in the application and does not integrate with BigQuery's native encryption features.
4. Customer-Managed Encryption Keys (CMEK) using Cloud KMS ✓

   Correct. CMEK allows customers to create and manage their own encryption keys in Cloud KMS. GCP services like BigQuery and Cloud Storage are integrated with Cloud KMS — you specify a KMS key at resource creation. Revoking the key renders the data inaccessible, meeting the control requirement.

CMEK via Cloud KMS gives customers control over encryption keys for GCP services, including the ability to revoke access by disabling or destroying the key.

4. Admin Activity audit logs: Which Cloud Audit Log type should they query?

1. Admin Activity audit logs ✓

   Correct. Admin Activity audit logs capture administrative actions that write metadata or configuration, including modifications to IAM policies, security rules, and resource configurations. They are always enabled, cannot be disabled, and are retained for 400 days. Modifying Firestore security rules is an administrative write action.
2. System Event audit logs

   Incorrect. System Event audit logs record Google-generated administrative actions, such as automatic maintenance operations (e.g., live migration of VMs) that are not triggered by user actions. Modifying security rules is a user-initiated action, not a system event.
3. Policy Denied audit logs

   Incorrect. Policy Denied audit logs (a subtype of Data Access logs) record when access was denied by a VPC Service Controls or IAM Deny policy. They do not record successful configuration changes like modifying security rules.
4. Data Access audit logs

   Incorrect. Data Access audit logs capture API calls that read metadata, configurations, or user-provided data (DATA_READ, DATA_WRITE, ADMIN_READ sub-types). Modifying security rules is a configuration change (an admin action), not a data read/write operation on user data.

Admin Activity audit logs capture all administrative writes (configuration and metadata changes), are always enabled, and are retained for 400 days.

5. VPC Service Controls with a service perimeter drawn around: Which security control addresses this?

1. IAM Conditions on the BigQuery and Cloud Storage resources restricting every request by its source IP range

   Incorrect. IAM Conditions can filter by IP but must be applied per resource, and they do not stop valid credentials being used from an unauthorized project. VPC Service Controls enforce an API-level perimeter across all protected resources.
2. VPC Service Controls with a service perimeter drawn around the projects holding BigQuery and Cloud Storage ✓

   Correct. VPC Service Controls create an API-level perimeter around GCP services in specified projects. Requests to BigQuery or Cloud Storage from outside the perimeter are blocked, preventing exfiltration even if IAM is misconfigured or credentials leak.
3. Cloud Armor security policies attached to the Cloud Storage buckets in order to filter incoming API requests

   Incorrect. Cloud Armor provides DDoS protection and WAF rules for external HTTP(S) load balancer traffic. It does not govern BigQuery or Cloud Storage API calls and is not an exfiltration control.
4. Organization Policy constraints applied to block data export from the BigQuery and Cloud Storage services

   Incorrect. Organization Policies govern resource configuration, such as restricting external IPs or regions. They cannot block service API requests based on the calling project or originating network.

VPC Service Controls create API-level security perimeters that block requests to GCP services from outside authorized projects and networks, preventing data exfiltration.

6. IAM Conditions combining a request.time date/time: Which IAM feature enables time-bound and expiring access?

1. Enable Cloud Identity-Aware Proxy for Cloud Storage and attach a time-based conditional access policy to it

   Incorrect. Cloud IAP guards application access for App Engine, GKE, and Compute Engine workloads. It does not control Cloud Storage API access this way and is not the right tool for time-bounded bucket access.
2. Create a temporary service account for the contractor that is set to expire after thirty days

   Incorrect. Service accounts do not expire on their own; you would have to track and delete it manually. IAM Conditions provide automatic expiry through the request.time attribute.
3. IAM Conditions combining a request.time date/time expression with an access expiry-date condition too ✓

   Correct. IAM Conditions attach conditional expressions to role bindings. The request.time attribute restricts access to the 9 AM to 5 PM weekday window and an expiry date automatically ends access, all without manually adding and removing bindings.
4. Use IAM Deny policies carrying a time-based condition to block access outside of business hours

   Incorrect. The requirement is to grant time-bounded, expiring access, which IAM Conditions on the allow binding handle directly. Using Deny policies for the time window adds unnecessary complexity.

IAM Conditions on role bindings support time-based expressions (business hours) and expiry dates for automated, time-bounded access control.

7. Grant the developer: How is this configured?

1. Grant the developer the roles/iam.serviceAccountTokenCreator role on the service account, then use the gcloud --impersonate-service-account flag or ADC impersonation ✓

   Correct. roles/iam.serviceAccountTokenCreator lets a principal create tokens for a service account. The developer runs gcloud with --impersonate-service-account or sets ADC impersonation, so no key file is ever downloaded.
2. Create a custom IAM role that includes the serviceaccounts.getAccessToken permission, bind it to the developer on the service account, and have them mint tokens for it

   Incorrect. serviceaccounts.getAccessToken is the underlying permission, but the predefined roles/iam.serviceAccountTokenCreator already grants it and is the recommended, auditable choice rather than a hand-built custom role.
3. Download the service account's JSON key file, hand it to the developer, and have them set the GOOGLE_APPLICATION_CREDENTIALS variable to that key path locally

   Incorrect. This is exactly the key-file approach the security team wants to avoid. Long-lived key files are a risk if mishandled, whereas impersonation achieves the same result without a downloadable key.
4. Grant the developer the roles/iam.serviceAccountUser role on the service account so they can attach it and automatically impersonate it when they run the app

   Incorrect. roles/iam.serviceAccountUser lets a principal attach a service account to a resource, such as running a VM as it. It does not grant token creation; roles/iam.serviceAccountTokenCreator is required for impersonation.

roles/iam.serviceAccountTokenCreator enables service account impersonation via gcloud or ADC without creating downloadable key files.

8. gcloud storage buckets get-iam-policy gs: Which sequence of gcloud commands should they use?

1. gcloud projects get-iam-policy [PROJECT_ID], then gcloud projects add-iam-policy-binding [PROJECT_ID] --member='user:[EMAIL]' --role='roles/storage.objectViewer' --condition=None

   Incorrect. gcloud projects commands manage project-level IAM, which applies broadly to every resource in the project. The task needs bucket-scoped IAM, which requires bucket-level commands.
2. gcloud storage buckets get-iam-policy gs://[BUCKET], then gcloud storage buckets add-iam-policy-binding gs://[BUCKET] --member='user:[EMAIL]' --role='roles/storage.objectViewer' ✓

   Correct. gcloud storage buckets get-iam-policy reads the bucket's current IAM policy, and gcloud storage buckets add-iam-policy-binding adds a single binding atomically without editing the full policy document.
3. gcloud beta iam policies get [BUCKET_ID], then gcloud beta iam policies add-binding [BUCKET_ID] --member='user:[EMAIL]' --role='roles/storage.objectViewer' --condition=None

   Incorrect. gcloud iam policies is not the command namespace for Cloud Storage bucket IAM. Bucket IAM is managed with gcloud storage buckets commands, not generic gcloud iam commands.
4. gsutil iam get gs://[BUCKET_NAME], then gsutil iam ch user:[EMAIL]:roles/storage.objectViewer gs://[BUCKET_NAME] to append the new read-access binding

   Incorrect. gsutil iam get and gsutil iam ch are valid but legacy; the question uses the gcloud CLI. The current preferred commands are gcloud storage buckets get-iam-policy and add-iam-policy-binding.

Cloud Storage bucket IAM is managed with gcloud storage buckets get-iam-policy and add-iam-policy-binding for reading and modifying bucket-level permissions.

9. The Editor role grants broad write access to most GCP APIs: Why is this a concern, and what is the recommended

1. The Editor role grants broad write access to most GCP APIs; create a dedicated service account with only the permissions needed ✓

   Correct. The default Compute Engine service account with Editor violates least privilege, so any process on the VM could modify most GCP resources. The fix is a dedicated service account granted only the roles the workload needs.
2. The default account is the real concern, so simply disable it completely to strip away every last bit of GCP API access from the VM

   Incorrect. Disabling the default service account removes all GCP API access, which is usually too restrictive since the app likely needs some. The right fix is a purpose-specific account with minimum permissions.
3. The service account attached at VM creation can never be changed later, so the VM has to be deleted and then recreated cleanly

   Incorrect. The service account on a Compute Engine VM can be changed after creation once the instance is stopped. Deleting and recreating the VM is unnecessary.
4. The risk is that other projects can reach this VM because the default service account is shared across the entire organization

   Incorrect. The default Compute Engine service account is per-project ([email protected]), not shared organization-wide. The real risk is the overly broad Editor role.

The default Compute Engine service account with Editor role violates least privilege; create a dedicated SA with only required permissions.

10. Set a rotation period on the CryptoKey: What is the correct way to configure automatic key rotation in Cloud K

1. Set a rotation period on the CryptoKey (e.g., 7776000 seconds = 90 days); Cloud KMS automatically creates new key versions on this schedule ✓

   Correct. Cloud KMS supports automatic key rotation at the CryptoKey level. Setting the rotation period creates new key versions automatically; the new version becomes primary for new encryptions while old versions remain active for decrypting existing data.
2. Create a Cloud Scheduler cron job that calls the Cloud KMS API every 90 days to add a new key version and then repoint each bucket to it manually

   Incorrect. Building a Cloud Scheduler and Cloud KMS API integration duplicates functionality Cloud KMS already provides natively through a rotation period, adding needless complexity and points of failure.
3. Rely on Cloud KMS default behavior, which rotates every CryptoKey automatically on a 90-day cycle with no explicit rotation configuration

   Incorrect. Cloud KMS does not rotate keys automatically by default; you must set an explicit rotation period on each CryptoKey that requires scheduled rotation, otherwise no new versions are created.
4. Configure the rotation period on the parent key ring so the 90-day schedule applies uniformly to every CryptoKey contained in that ring

   Incorrect. Rotation is configured per CryptoKey, not on the key ring. Key rings are organizational containers scoping location and namespace, and they expose no rotation-period setting to inherit.

Cloud KMS automatic key rotation is configured per CryptoKey via a rotation period; Cloud KMS creates new key versions on schedule while old versions remain for decryption.

11. Create a Google Group: What is the most scalable and maintainable approach to managing this access?

1. Create a shared service account holding roles/bigquery.dataViewer and distribute its exported JSON key to all 150 developers so they authenticate as that account

   Incorrect. Sharing a service account key among users is a security anti-pattern that creates an unauditable shared credential, making it impossible to attribute actions to individuals who should use their own identities.
2. Grant roles/bigquery.dataViewer individually to each of the 150 developer user accounts and update every binding by hand whenever someone joins or leaves

   Incorrect. Maintaining 150 individual bindings forces an IAM policy update every time a developer joins or leaves, which does not scale and steadily bloats the project's IAM policy with churn.
3. Create a Google Group (e.g., [email protected]), grant roles/bigquery.dataViewer to the group at the project level, and manage team membership in the group ✓

   Correct. Using Google Groups for IAM bindings is the recommended practice at scale. Granting a role to a group means one binding; adding or removing users from the group automatically updates their access without touching the IAM policy, reducing churn.
4. Grant roles/bigquery.admin to each of the 150 developers at the project level so they retain broad access and never lose the ability to read a dataset

   Incorrect. roles/bigquery.admin allows deleting datasets and managing IAM, far exceeding read-only viewing, so granting it to everyone grossly violates least privilege for a data-viewing need.

Using Google Groups for IAM bindings enables scalable access management — grant once to the group and manage membership rather than individual IAM bindings.

12. roles/viewer is a basic role that grants read access: What is the primary concern with this approach?

1. roles/viewer applied at the project level does not propagate down to Cloud Storage buckets, so the data team members would still be completely unable to list or read any of the objects stored inside those buckets

   Incorrect. Project-level IAM bindings inherit to all resources including Cloud Storage buckets, so roles/viewer does grant storage.objects.list and storage.objects.get across the project's buckets.
2. roles/viewer can be granted only to service accounts and never to human user principals, so attempting to assign this basic role to individual data team members would be rejected by IAM

   Incorrect. Any IAM role, basic roles included, can be granted to users, groups, or service accounts; there is no rule restricting basic roles to service accounts only.
3. roles/viewer is far too restrictive for the data team because a read-only role blocks members from creating, updating, or deleting any of the resources they rely on for their daily work

   Incorrect. The senior engineer's concern is that the role is too broad, not too narrow; least-privilege reasoning is about granting the minimum access needed, so 'too restrictive' misstates the issue.
4. roles/viewer is a basic (primitive) role that grants read access to all services in the project, violating least privilege by granting more access than needed for each team member's specific job ✓

   Correct. Basic roles (Owner, Editor, Viewer) are coarse-grained and span every GCP service; roles/viewer grants read across Compute Engine, Cloud Storage, BigQuery, Cloud SQL, Secret Manager, and more, exceeding what any individual needs.

Basic roles like roles/viewer are overly broad, granting read access to all GCP services in a project regardless of what each team member actually needs.

Other GCP ACE domains

• Deploying and implementing a cloud solution — 158 questions →
• Planning and configuring a cloud solution — 108 questions →
• Ensuring successful operation of a cloud solution — 96 questions →
• Setting up a cloud solution environment — 61 questions →
• All 500 GCP ACE questions →