Task 1.2: Managing service accounts.

• AA new service account key created by a scheduled job each day and written into the repository secret

  Incorrect

  Each key is still an exportable credential stored outside Google Cloud, and nothing stops another branch of the repository from using it.

• BThe key moved into Secret Manager, with the repository's workflow reading it at the start of each run

  Incorrect

  The key is still long-lived, and the workflow would need yet another credential to read Secret Manager.

• CWorkload Identity Federation for GitHub's OIDC tokens, conditioned on repository_id and ref

  Correct

  The workflow exchanges its short-lived GitHub OIDC token for Google credentials, and the attribute condition rejects tokens from other repositories or branches; Google advises the immutable repository ID rather than the name.

• DA workforce identity pool that trusts GitHub, with the deployment role granted to the pool

  Incorrect

  That pool type does not serve pipeline workloads, and granting the whole pool ignores the branch restriction.

Workload Identity Federation lets a deployment pipeline that can present an OIDC token, such as GitHub Actions, get short-lived Google Cloud credentials without a service account key. Attribute mappings expose claims such as repository_id and ref, and an attribute condition limits which tokens the provider accepts; the deployment service account is then granted to the matching principal set.

• AThe managed constraint preventing privileged basic roles for default service accounts

  Correct

  iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts stops default service accounts from ever being granted Editor or Owner, both automatically and manually.

• BThe legacy constraint that turns off the automatic IAM role grants to default service accounts

  Incorrect

  iam.automaticIamGrantsForDefaultServiceAccounts only stops the automatic Editor grant at creation; a developer could still grant Owner by hand.

• CThe managed constraint that disables service account creation

  Incorrect

  Blocking service account creation also stops some services from creating their default service accounts, which the team wants to keep, and it does nothing about role grants.

• DA scheduled script that removes Editor from default service accounts each night

  Incorrect

  A cleanup job is detective and leaves a window every day in which the accounts hold Editor or Owner; it is not a control that prevents the grant.

Organization policy offers two generations of controls here. The newer managed constraint iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts blocks Editor and Owner on default service accounts whether the grant is automatic or manual. Like the other service account constraints, it is not retroactive, so existing grants still have to be removed once.

• AService Account User on project prod-app

  Incorrect

  Service Account User grants actAs to attach service accounts to resources, not to create tokens for them, and at project level it covers every service account in the project.

• BService Account Token Creator on that one service account

  Correct

  Token Creator on the single service account lets the administrator mint short-lived tokens for it, and gcloud's impersonation flag uses them, so no key is needed and no other account is reachable.

• CService Account Token Creator on project prod-app

  Incorrect

  At project level the role lets the administrator impersonate every service account in prod-app, which the requirement rules out.

• DService Account Key Admin on the deploy service account, with keys rotated after use

  Incorrect

  Key Admin lets the administrator create keys, which is the download the requirement forbids, even if the keys are rotated afterwards.

Service account impersonation lets a principal get short-lived credentials for a service account instead of using a key. The permission comes from the Service Account Token Creator role, and granting it on the one service account, rather than on the project, keeps the reach as small as possible.

• AThe workloadIdentityPoolProviders constraint, allowing only https://sts.amazonaws.com

  Incorrect

  Allowing the AWS STS URI admits AWS as a provider type, but any AWS account could still be trusted.

• BAn IAM deny policy on the organization that blocks the workload identity pool admin role for all users

  Incorrect

  Blocking pool administration stops the teams' legitimate use instead of limiting which accounts the pools trust.

• CThe workloadIdentityPoolAwsAccounts constraint on the organization, listing only the company's two AWS account IDs

  Correct

  This constraint limits which AWS accounts workload identity pools may trust, across every project under the policy.

• DAn attribute condition template that every team is asked to copy into its own providers

  Incorrect

  Attribute conditions are set per provider by whoever configures it, so a team could leave the condition out.

Organization policy has list constraints for Workload Identity Federation. The provider constraint (the legacy iam.workloadIdentityPoolProviders, also offered as the managed iam.managed.workloadIdentityPoolProviders) lists the identity provider URIs that pools may use, such as https://sts.amazonaws.com for AWS, and the legacy managed constraint iam.workloadIdentityPoolAwsAccounts lists the AWS accounts that may be trusted. They apply to every pool below the policy, unlike attribute conditions, which each provider sets itself.

• AWorkload Identity Federation for GKE, with roles granted to each application's Kubernetes ServiceAccount

  Correct

  IAM can grant roles to the principal of a Kubernetes ServiceAccount, so Pods using it get those permissions and nothing more.

• BA separate key per application, mounted from a Kubernetes Secret into that application's Pods

  Incorrect

  Mounting keys is exactly the long-lived credential the team rules out.

• CBroader scopes on the node pool's service account, with each application trusted to use only what it needs

  Incorrect

  Every Pod on the node still shares one identity, so applications are not separated.

• DA Kubernetes network policy per application that limits which Google API addresses its Pods can reach

  Incorrect

  Network policies control traffic between Pods and do not give applications different Google Cloud permissions.

With Workload Identity Federation for GKE, Pods authenticate to Google Cloud as their Kubernetes ServiceAccount, which IAM identifies with a principal identifier built from the project's workload identity pool, the namespace and the ServiceAccount name. Roles granted to that principal apply only to Pods using it.

• AA scheduled job that rotates every service account key in the organization each month

  Incorrect

  Rotation limits how long a key is valid, but a leaked key stays usable until the next rotation.

• BThe service account key exposure response constraint, set to DISABLE_KEY on the organization

  Correct

  iam.serviceAccountKeyExposureResponse with DISABLE_KEY makes Google Cloud disable a key it detects as exposed, log the action and notify project owners and security contacts.

• CThe managed constraint that disables service account key creation for all projects

  Incorrect

  Blocking key creation breaks the legacy tool and is not retroactive, so existing keys can still leak.

• DData Access audit logs for IAM, with an alert when a key is used from an unknown address

  Incorrect

  An alert after misuse is detective and still needs a person to disable the key.

Google Cloud watches for exposed service account keys and API keys bound to service accounts, for example in public repositories. The iam.serviceAccountKeyExposureResponse constraint decides what happens: DISABLE_KEY disables the key automatically, and WAIT_FOR_ABUSE does not; since June 2024, DISABLE_KEY is also the behavior when the constraint is not set.

• ADelete every account without a key, because accounts without keys cannot authenticate

  Incorrect

  Accounts attached to resources authenticate without keys, so this would delete accounts that workloads use.

• BDelete accounts that show no activity in the last week and recreate any that turn out to be needed

  Incorrect

  A recreated account with the same name is a new identity, so its old grants do not come back, and a week misses quarterly jobs.

• CRemove all roles from every account and add back roles for whichever workloads fail

  Incorrect

  Stripping roles from everything breaks production first and asks questions later.

• DCheck each account's recent authentication history, then disable idle accounts before deleting

  Correct

  Usage data over the last 90 days shows idle accounts, and disabling first can be undone if a forgotten job still needs one.

Policy Intelligence shows when service accounts and keys were last used to authenticate, over up to 90 days. Google's best practice is to disable a service account that seems unused and delete it only after a waiting period, because a disabled account can be enabled again, while a deleted and recreated account is a different identity.