Associate Cloud Engineer · 20% of the exam

Configuring access and security: free practice questions

5 sample questions from our 50-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Google Cloud exam.

1. A junior team member creates a service account `ci-robot@my-project.iam.gserviceaccount.com` for CI/CD pipelines. You discover that they also created and downloaded a user-managed service account key for this account. According to Google's security best practices and common audit requirements, what is the primary concern with this approach, and what is the recommended alternative?

  • A. User-managed keys are more secure because they are not rotated automatically; this is a best practice
  • B. User-managed keys have no built-in expiration and are harder to audit and rotate compared to short-lived credentials from Workload Identity or service account impersonation, so you should use Workload Identity or OAuth2-based token exchange instead✓ Correct
  • C. User-managed keys are fine if they are stored in Secret Manager; the risk is eliminated by encryption
  • D. User-managed keys must be rotated monthly by policy; as long as rotation happens, the risk is acceptable
Explanation

The correct answer is option 2. Google explicitly recommends *against* user-managed service account keys due to the security risks: they do not expire, are difficult to audit at scale, cannot be easily rotated, and if compromised, pose a persistent threat. The recommended approaches are: (1) Workload Identity for workloads on GKE, (2) service account impersonation, or (3) short-lived tokens from GCP's token exchange mechanisms. Option 1 is dangerously wrong—automatic rotation is a security *benefit*, not a drawback. Option 3 is incorrect; storing a key in Secret Manager is still using a user-managed key and does not mitigate the underlying risks. Option 4 is wrong; even with rotation, user-managed keys lack the auditability and short lifetime of better alternatives.

2. You are configuring IAM for a project where different teams need different permissions. Team A needs to manage Firewall rules, and Team B needs to manage Route resources. Which of the following approaches best follows the principle of least privilege while avoiding unnecessary custom role creation?

  • A. Assign roles/editor to both teams; it includes all network permissions and is the simplest approach
  • B. Create a custom role combining compute.firewalls.* and compute.routes.* permissions for each team
  • C. Assign roles/compute.networkAdmin to Team A (includes firewall permissions) and roles/compute.networkAdmin to Team B (includes route permissions)✓ Correct
  • D. Assign roles/compute.securityAdmin to Team A for firewall management and use roles/compute.admin for Team B (includes route permissions)
Explanation

The correct answer is option 3. Both teams need to be assigned roles/compute.networkAdmin, which includes permissions for both Firewall and Route management. While this means both teams technically have access to both resource types, it is the predefined role that covers network management and is simpler than custom roles. The key is that predefined roles should be used when they reasonably fit the use case. Option 1 is wrong because Editor is far too broad (includes permissions for compute, storage, database, etc.) and violates least privilege. Option 2 is incorrect; creating a custom role is unnecessary complexity when a predefined role exists that covers the needed permissions. Option 4 is incorrect; roles/compute.securityAdmin is for security policy management (not firewalls directly), and roles/compute.admin is overly broad for just route management.

3. A developer on your team needs to list Cloud Storage buckets in a project but must NOT be able to read or modify bucket contents or any other resources. Which predefined IAM role should you grant them at the project level?

  • A. roles/storage.objectViewer
  • B. roles/storage.legacyBucketReader
  • C. roles/storage.admin
  • D. roles/viewer✓ Correct
Explanation

roles/viewer (Project Viewer) grants read-only access to all project resources, including the ability to list Cloud Storage buckets, without any write permissions — satisfying least privilege for this task. roles/storage.objectViewer allows reading object data and metadata inside buckets but does NOT grant permission to list buckets at the project level. roles/storage.legacyBucketReader is a bucket-level role (not project-level) and grants read access to a specific bucket's metadata and objects. roles/storage.admin grants full control over all Storage resources, violating least privilege.

4. A service account in your project is attached to a Compute Engine instance. When the instance executes a gcloud command to access a Cloud Storage bucket in another project, it fails with PERMISSION_DENIED. The instance has the roles/editor role in its own project. What is the MOST likely cause?

  • A. The service account lacks permissions in the target project✓ Correct
  • B. The instance must have the roles/owner role instead
  • C. Firewall rules are blocking the connection
  • D. The service account's key has expired
Explanation

The correct answer is that the service account lacks permissions in the target project. Service account permissions are project-scoped; having roles/editor in the home project does not grant access to resources in other projects. The target project's IAM policy must explicitly grant the service account a role with bucket access. roles/owner is not required and doesn't solve cross-project access. Firewall rules do not restrict Cloud Storage API calls made via authenticated credentials. Service account attached to instances use the Compute Engine metadata service, which automatically refreshes tokens, so key expiration is not the issue.

5. A service account named `batch-processor@my-project.iam.gserviceaccount.com` is attached to a Compute Engine instance. The instance runs a script that calls `gcloud pubsub subscriptions pull` to consume messages. When the script executes, it receives a PERMISSION_DENIED error. You have confirmed the service account has the `roles/pubsub.subscriber` role. What is the most likely cause?

  • A. The service account key has expired and needs to be rotated.
  • B. The Compute Engine instance is not running in the same region as the Pub/Sub subscription.
  • C. The service account must be explicitly granted the Editor role; Pub/Sub Subscriber alone is insufficient.
  • D. Workload Identity is misconfigured; the pod identity binding is missing or incorrect.
  • E. The service account is attached to the instance, but application default credentials are not being used properly by the gcloud command.✓ Correct
Explanation

The correct answer is option 4. When a Compute Engine instance has a service account attached, applications running on that instance must use Application Default Credentials (ADC) to authenticate. The gcloud command should automatically use ADC when the service account is attached, but if the environment isn't set up correctly or if user credentials are taking precedence, it may fail. This is a common configuration issue. Option 1 is incorrect because service account keys attached to instances don't expire; the metadata service provides time-limited tokens. Option 2 is incorrect because Pub/Sub subscriptions are project-scoped resources, not region-specific in terms of IAM access. Option 3 is incorrect because Pub/Sub Subscriber is the correct minimal role for this operation; Editor would be excessive. Option 4 is the most likely cause for this specific error pattern.

45 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free