Google ACE Configuring Access and Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a service account and assign it to the instance using gcloud compute instances set-service-account after creation

  Why it's wrong here

  The gcloud compute instances set-service-account command can only change the service account on an existing instance, and only while the instance is stopped. If the instance is running, you must stop it, change the service account, and start it again, which makes this unsuitable as the initial creation approach. More importantly, this command is not a substitute for specifying the service account at instance creation; it's a modification workflow, not the primary setup workflow.

• ✗

  Use the default compute engine service account and grant it roles/storage.objectAdmin

  Why it's wrong here

  Using the default compute engine service account and granting it roles/storage.objectAdmin (or any additional role) is an anti-pattern because the default service account is typically pre-bound to the project editor role, giving it far broader permissions than needed. Adding storage.objectAdmin on top of that expands the blast radius; if the instance is compromised, the attacker inherits those excessive privileges. Best practice is to create a custom service account with the minimum roles required, not to augment the default one.

• ✗

  Create a service account, download a JSON key, and store it on the instance's local disk

  Why it's wrong here

  Downloading a JSON key and storing it on the instance's local disk is explicitly discouraged by Google for workloads on Compute Engine. A JSON key is a long-lived credential that can be exfiltrated if the instance is compromised, and it requires manual rotation and secure storage on the VM. Instead, when a service account is attached to an instance, the metadata server provides automatically rotated OAuth2 tokens, so no key files are ever needed on the instance.

• ✓

  Create a service account, grant it the required roles, and specify it when creating the instance using the --service-account flag

  Why this is correct

  Creating a dedicated service account, granting it only the IAM roles the application needs, and passing it via the --service-account flag at instance creation time is the Google-recommended pattern. This attaches the identity to the instance without ever downloading a key, so the instance authenticates through the metadata server's short-lived OAuth tokens. It ensures least privilege and avoids the security risk of storing long-lived credentials on the VM.

Go deeper

Related to this question