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.

• ✗

  Hardcode the secret in the application configuration file

  Why it's wrong here

  Hardcoding a secret into a configuration file stores it in plaintext, making it visible to anyone with read access to the application's source code or filesystem. This approach also lacks audit logging, versioning, and automatic rotation, leaving the credential valid indefinitely if not manually changed. It violates the principle of least privilege and increases the blast radius of a leak.

• ✗

  Create a new service account with the secretAccessor role, create a key, and store it on the instance

  Why it's wrong here

  Creating a new service account and downloading a key file to store on the instance exposes a long-lived, static credential that can be stolen or accidentally committed to source control. The default Compute Engine service account already has an identity tied to the instance via the metadata server, enabling short-lived OAuth2 tokens without any key material on disk. This option needlessly introduces key management overhead and a persistent security risk.

• ✗

  Grant the roles/editor role to the default compute engine service account

  Why it's wrong here

  The Editor role grants extensive permissions across all resources in the project, including the ability to create, modify, and delete Compute Engine instances, Cloud Storage objects, and even Secret Manager secrets. This far exceeds what the application needs and violates least privilege, potentially allowing an attacker who compromises the instance to perform destructive actions on the entire project. In particular, it would allow modifying IAM policies or deleting the very secrets the application relies on.

• ✓

  Grant the roles/secretmanager.secretAccessor role to the compute engine default service account

  Why this is correct

  Granting the roles/secretmanager.secretAccessor role to the Compute Engine default service account is the correct approach because it gives the instance's identity the minimum permission needed to access secret versions. The instance authenticates through the metadata server, so no long-lived keys are stored on the instance. This makes it the most secure and operationally simple method, and it aligns with Google's recommended practice of using IAM roles on service accounts rather than embedding credentials.

Go deeper

Related to this question