Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Your enterprise organization is establishing a secure operational framework for service account usage across its development teams. You must configure IAM permissions to support two distinct operational requirements while strictly enforcing the principle of least privilege:
StudyCerts
StudyCertsdevops-leads@example.com) must be able to impersonate a production deployment service account (prod-deployer@project-id.iam.gserviceaccount.com) from the Google Cloud CLI to obtain short-lived OAuth 2.0 access tokens for emergency rollouts without managing static keys.app-devs@example.com) must be able to provision Compute Engine virtual machines that run workloads under a dedicated workload service account (app-runner@project-id.iam.gserviceaccount.com), but they must not be permitted to directly generate credentials or mint tokens for this workload service account from their local workstations.Which IAM role bindings should you configure?
This configuration leverages resource-level IAM role bindings to grant specific, scoped capabilities to each group on individual service accounts, avoiding broader project-level over-permissioning.
roles/iam.serviceAccountTokenCreator) contains the iam.serviceAccounts.getAccessToken permission. Granting this role directly on prod-deployer@project-id.iam.gserviceaccount.com allows devops-leads@example.com to use the --impersonate-service-account flag in gcloud or call the IAM Credentials API to generate short-lived OAuth 2.0 tokens without exposing long-lived service account keys.roles/iam.serviceAccountUser) grants the iam.serviceAccounts.actAs permission. Binding this role to app-devs@example.com on app-runner@project-id.iam.gserviceaccount.com allows developers to attach the service account to compute resources (such as Compute Engine instances). It deliberately does not include token generation permissions (iam.serviceAccounts.getAccessToken), preventing developers from minting tokens to impersonate the service account directly from their workstations.actAs) from the ability to mint credentials interactively (getAccessToken).generateAccessToken and actions utilizing iam.serviceAccounts.actAs generate Cloud Audit Logs identifying both the caller and the target service account.Granting roles at the individual service account resource level rather than the project level minimizes the blast radius. Binding roles/iam.serviceAccountTokenCreator and roles/iam.serviceAccountUser to their respective targets precisely satisfies operational needs without creating privilege escalation paths.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.