Task 4.2: Managing service accounts.

• ACreate a dedicated service account with Storage Object Viewer on that bucket and attach it to the VM

  Correct

  A dedicated service account with one narrow grant gives the app exactly the access it needs and nothing else.

• BCreate a key for a new service account and store it on the VM's disk for the application to use

  Incorrect

  A downloaded key is a long-lived secret; attaching the account to the VM provides credentials without any key.

• CRemove the Editor role from the default service account and give it Storage Object Viewer on the project

  Incorrect

  Other VMs that share the default account may need other access, and a project-wide grant still covers every bucket.

• DKeep the default service account and narrow the VM's access scopes to read-only Cloud Storage

  Incorrect

  Scopes are a legacy mechanism; the default account would still hold Editor, and other VMs using it keep that access.

Give each workload its own service account with the smallest grant on the smallest resource. The default Compute Engine service account is often broad and shared by many VMs.

• AThe Service Account User role on app-sa for the engineer

  Correct

  Attaching a service account to a resource needs the actAs permission on that account, which this role contains.

• BThe Service Account Key Admin role on app-sa for the engineer

  Incorrect

  Key administration lets the engineer create keys, which is not what attaching an account needs and adds risk.

• CThe Service Account Admin role on the project for the engineer

  Incorrect

  Service Account Admin creates and manages service accounts; it does not include the actAs permission.

• DThe Compute Admin role on the project for app-sa

  Incorrect

  The error is about the engineer's permission on the service account, not about what the service account can do.

Attaching a service account lets a resource act with that account's access, so Google Cloud checks that the person attaching it may act as the account. Grant Service Account User on the specific account.

• ACreate a key for the deployer service account and store it as an encrypted secret in the GitHub repository

  Incorrect

  A stored key is exactly the long-lived credential security forbids.

• BCreate a workload identity pool with a GitHub OIDC provider and an attribute condition for example-org/web

  Correct

  The provider trusts GitHub's OIDC tokens, and the attribute condition rejects tokens from any other repository.

• CCreate an API key restricted to the Cloud Run Admin API and pass it to the workflow as a secret

  Incorrect

  API keys identify a project for some APIs; they cannot authorize deployments as an IAM principal.

• DGrant the principals of that repository access to the deployer service account or the needed roles

  Correct

  Federated identities need IAM grants, either directly or through permission to impersonate a service account.

• ECreate a workforce identity pool and add GitHub as its identity provider

  Incorrect

  Workforce pools sign in people; workloads such as CI pipelines use workload identity pools.

Workload Identity Federation exchanges a CI system's own token for short-lived Google Cloud credentials. Attribute conditions narrow which external workloads are trusted.

• AGrant the admin Service Account Admin on the project and reset the account's credentials

  Incorrect

  Service Account Admin manages accounts; it does not let the admin act as one, and credentials are not reset this way.

• BGrant the admin Token Creator on terraform-sa and run gcloud with --impersonate-service-account

  Correct

  Token Creator lets the admin get access tokens for that account, and the flag makes gcloud call APIs as that account.

• CGrant terraform-sa's roles to the admin's own account directly so that gcloud runs with the same access

  Incorrect

  The admin would then always hold these permissions, rather than using them only while acting as the account.

• DGrant the admin Service Account User on terraform-sa and run gcloud auth activate-service-account

  Incorrect

  activate-service-account needs a key file, which is forbidden, and Service Account User is for attaching accounts to resources.

With Token Creator on one service account, a person can run gcloud as that account through --impersonate-service-account, so no key has to be downloaded.

• AEnable Workforce Identity Federation and map each Pod to a user in a workforce identity pool

  Incorrect

  Workforce Identity Federation signs in people from an external IdP, not Kubernetes workloads.

• BGrant the Pub/Sub Subscriber role to the service account that the cluster's nodes run as

  Incorrect

  Every Pod on those nodes would share the node identity, so workloads would not have their own identities.

• CCreate a service account key, store it in a Kubernetes Secret and mount it into the Pods

  Incorrect

  This is the key-in-a-Secret pattern the team wants to avoid.

• DUse Workload Identity Federation for GKE and grant the role to the Pods' Kubernetes ServiceAccount

  Correct

  Workload Identity Federation for GKE lets IAM grant roles to a Kubernetes ServiceAccount, so its Pods get credentials without keys.

Workload Identity Federation for GKE gives each Kubernetes ServiceAccount its own IAM identity. It is the recommended way for GKE workloads to call Google Cloud APIs.

• ADisable the service account until the team confirms its use

  Correct

  A disabled account cannot authenticate, and it can be enabled again with its roles and identity intact.

• BDelete the service account and create a new one with the same name if needed

  Incorrect

  A recreated account with the same name is a new identity, so it does not get the old account's role bindings back.

• CDelete only the user-managed keys of the service account

  Incorrect

  Workloads with the account attached still get tokens without keys, so the calls may continue.

• DRemove the Service Account User role from everyone on the account

  Incorrect

  This stops new resources from being attached to it, but anything already using it keeps working.

Disabling is the safe, reversible way to stop a service account. Google also recommends disabling an account before deleting it to confirm nothing still needs it.

• AUse the cloud-platform access scope and control access with IAM

  Correct

  Both IAM roles and access scopes must allow a call; the default scopes give only read access to storage.

• BOpen egress firewall rules to storage.googleapis.com on port 443

  Incorrect

  The error is an authorization failure, not a network block.

• CCreate a key for the service account and copy it onto the VM

  Incorrect

  A key adds a long-lived secret instead of fixing the scopes.

• DGrant the service account Storage Admin on the whole project

  Incorrect

  A broader role does not help while the scopes still block writes.

Access scopes are a legacy layer on top of IAM. Use the cloud-platform scope and let IAM decide what the service account can do.

• AA workforce identity pool principal

  Incorrect

  Federated principals use principal:// identifiers, not this format.

• BA user-managed service account created by a developer in the project

  Incorrect

  User-managed accounts use the name@PROJECT_ID.iam.gserviceaccount.com format.

• CA Google Workspace user in the developer domain

  Incorrect

  Users have regular email addresses, not this service account format.

• DThe Compute Engine default service account of the project

  Correct

  The default Compute Engine service account uses the format PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Recognizing default service accounts in policies helps spot broad grants that should be narrowed.

• AAn OAuth client ID for the appliance

  Incorrect

  OAuth clients are for apps that sign users in, not access-key based tools.

• BAn HMAC key for the service account

  Correct

  HMAC keys authenticate requests to the Cloud Storage XML API, which S3-compatible tools use.

• CA signed URL for each backup file

  Incorrect

  A per-file link does not suit an ongoing backup tool that keeps writing new objects.

• DAn API key restricted to Cloud Storage

  Incorrect

  API keys bound to a service account serve a few APIs such as the Gemini API; an S3-compatible tool needs an access ID and secret instead.

Interoperability with S3-style tools runs through the XML API and HMAC keys, which should be tied to a service account and rotated.

• ADisable the service account, create a key, then enable the account

  Incorrect

  Disabling the account stops the tool and is not part of rotation.

• BDelete the old key, then create a new key and update the tool

  Incorrect

  The tool fails between deleting the old key and deploying the new one.

• CCreate a new key, update the tool to use it, then delete the old key

  Correct

  Rotation replaces keys with new ones; creating the new key first avoids a gap.

• DKeep the same key and change only its display name every 90 days

  Incorrect

  Renaming is not rotation; the same secret stays in use.

Rotate keys by overlapping them briefly: new key in, old key out.

• AReplace it with a new billing-export-sa that has the same roles

  Correct

  A service account's ID cannot be changed after creation, so a new account must replace it.

• BDisable tmp-test-sa and enable it again under the new name

  Incorrect

  Disabling and enabling an account does not change its ID.

• CChange only the display name and treat the account as renamed

  Incorrect

  The email address, which other systems use, would still contain the old ID.

• DRename tmp-test-sa in place with gcloud iam service-accounts update

  Incorrect

  You can update a display name, but not the account's ID.

Choose service account IDs carefully; changing one means migrating to a new account.