Configuring access and security

A reporting service account needs to read objects from a single Cloud Storage bucket that holds nightly exports. It must never write, delete, or change bucket configuration. Following least privilege, which predefined role should be granted on that bucket?

• AGrant roles/editor at the project level so the service account inherits object read access to the bucket along with the other permissions the reporting job may later require.
• BGrant roles/storage.objectViewer on the bucket so the account can read and list objects there without any permission to modify or remove them.check_circle Correct
• CGrant roles/storage.objectAdmin on the bucket so the account can list and read the exported objects while Cloud Storage handles the reporting access it needs.
• DGrant roles/storage.admin on the bucket so the account has a role dedicated to Cloud Storage rather than a broad basic role at the project level.

Why A is wrong: Tempting because Editor certainly includes reading objects, but it is a basic role spanning almost every service in the project, which massively over-grants for a read-only bucket task.

Why B is correct: Correct: objectViewer grants exactly get and list on objects for that bucket, matching the read-only need with no write, delete, or admin capability.

Why C is wrong: Tempting because it is scoped to the bucket, but objectAdmin also allows creating, overwriting, and deleting objects, which exceeds the stated read-only requirement.

Why D is wrong: Tempting because it is a service-specific role, but storage.admin confers full control over buckets and objects including deletion and IAM changes, far beyond reading exports.

To let a team manage objects in one Cloud Storage bucket called reports-2026, an engineer granted the team roles/storage.objectAdmin at the project level. The team can now modify objects in every bucket in that project, which breaches least privilege. You must restrict them to reports-2026 while keeping their ability to manage objects there. What should you do?

• ARemove the project-level binding and grant roles/storage.objectAdmin on the reports-2026 bucket instead, so the team manages only that bucket's objects.check_circle Correct
• BAdd a second objectAdmin binding on the reports-2026 bucket, since a binding closer to the resource takes precedence and narrows the effective scope to that bucket.
• CChange the project-level binding from objectAdmin to roles/storage.objectViewer, so the team keeps a Cloud Storage role but with tighter permissions overall.
• DLeave the project binding in place and create IAM deny policies on each of the other buckets to block object writes everywhere except reports-2026.

Why A is correct: Correct: deleting the project binding stops the inherited project-wide access, and a bucket-level binding then confines objectAdmin to reports-2026, matching the requirement precisely.

Why B is wrong: Tempting because it sounds like a more specific binding wins, but IAM bindings are additive rather than overriding, so the project-level grant would remain and the team would still reach every bucket.

Why C is wrong: Tempting because it reduces the permission set, but objectViewer is read-only across the whole project, so the team loses the object management it legitimately needs on reports-2026.

Why D is wrong: Tempting because deny policies can subtract access, but maintaining a deny for every other bucket, plus each new bucket, is fragile and misses the simpler fix of scoping the allow correctly.

A team wants to hand a downstream service account permission to generate signed blobs on behalf of an upstream service account, using short-lived credentials rather than a key. Which role must be granted on the upstream service account?

• AService Account Admin, which manages the lifecycle of service accounts and therefore can sign on their behalf.
• BService Account User, which attaches the account to workloads and lets attached code sign requests without a token.
• CWorkload Identity User, which federates external identities and thereby covers internal signing between two service accounts.
• DService Account Token Creator, which allows the caller to request short-lived tokens and signed artefacts for the target service account.check_circle Correct

Why A is wrong: Service Account Admin creates, updates, and deletes service accounts but does not grant the ability to mint tokens or sign blobs as them, so it does not satisfy the requirement.

Why B is wrong: Service Account User permits deploying resources that run as the account, but it does not confer the token-generation permission needed to sign on demand from another identity.

Why C is wrong: Workload Identity User binds an external or Kubernetes identity to a service account; it is not the role that authorises one Google service account to sign as another.

Why D is correct: roles/iam.serviceAccountTokenCreator authorises generateAccessToken and signBlob against the target account, providing keyless signing with credentials that expire automatically.

A developer runs a local script that must authenticate as a service account for a one-off task, and your policy forbids downloading keys. Which approach lets the script authenticate while keeping the keyless posture?

• ARegister a new user-managed key through the console and store it in the developer's password manager for reuse.
• BConfigure the gcloud CLI to impersonate the service account so calls are authorised with short-lived credentials from the developer's own identity.check_circle Correct
• CGrant the developer the Service Account User role and rely on it to sign requests directly as the service account.
• DAdd the developer to a Google group that owns the service account, which then shares its permanent credential automatically.

Why A is wrong: Storing a key in a password manager still creates a long-lived exported credential, which violates the keyless policy no matter how carefully it is held.

Why B is correct: The impersonate-service-account setting makes gcloud request short-lived tokens on the developer's behalf, so the script acts as the service account without any key file existing.

Why C is wrong: Service Account User permits attaching the account to resources, but on its own it does not let a local CLI mint tokens to sign requests, so the script would still lack credentials.

Why D is wrong: Group membership can convey IAM roles, but service accounts do not distribute a shared permanent credential to members, so no usable authentication results from this alone.

An administrator plans to create a custom IAM role so it can be reused across several projects under one folder. At which levels of the resource hierarchy can a custom role be created?

• AAt the folder level only, so that every project beneath the folder inherits the same custom role definition automatically.
• BAt the billing account level, because custom roles are scoped to the account that pays for the resources they govern.
• CAt the project level only, because a custom role defined anywhere else would conflict with the predefined roles Google maintains organisation-wide.
• DAt either the organisation level or the project level, depending on how widely the administrator wants the role to be available.check_circle Correct

Why A is wrong: Custom roles cannot be created at the folder level at all, so a folder-only answer is incorrect even though folders do play a role in policy inheritance.

Why B is wrong: Billing accounts are not a location for defining custom roles; role creation is tied to the organisation and project scopes, not to who pays for usage.

Why C is wrong: This wrongly rules out organisation-level custom roles, which are supported; there is no conflict with predefined roles, so restricting creation to projects is inaccurate.

Why D is correct: Custom roles can be defined at the organisation level, making them available to all projects in the organisation, or at the project level for use within that single project.