Google Cloud Security Engineer Professional

1. 1.An enterprise runs Active Directory on premises and wants Google Cloud user accounts and groups to reflect AD automatically, while authentication still happens against the corporate identity provider. Which combination should be deployed?

   • AGoogle Cloud Directory Sync for provisioning plus SAML SSO for authenticationCorrect answer
   • BManual account creation with Cloud Identity passwords
   • CWorkload Identity Federation for each employee
   • DGoogle Cloud Directory Sync with locally managed Cloud Identity passwords

   Why

   Google Cloud Directory Sync provisions users and groups from Active Directory into Cloud Identity on a schedule, and SAML-based SSO delegates the actual authentication to the corporate identity provider so passwords never live in Cloud Identity. Creating accounts by hand does not stay in sync, Workload Identity Federation is for workloads rather than employees, and setting Cloud Identity passwords manually contradicts delegating authentication.

2. 2.An organization must reduce the risk associated with its Cloud Identity super administrator accounts. Which practice is recommended?

   • AKeep a few dedicated super admin accounts, protected by hardware security keys and not used dailyCorrect answer
   • BGrant super administrator to every project owner for convenience
   • CUse a super administrator account for routine day-to-day administration
   • DShare one super administrator account among the admin team

   Why

   Keeping a small number of dedicated super admin accounts that are not used for daily work, protected with hardware security keys and monitored, limits both the blast radius and the exposure of the most privileged identity. Granting the role to every project owner spreads maximum privilege widely, using a super admin account for routine administration exposes it constantly, and sharing one account among administrators destroys attribution.

3. 3.A workload running on Amazon EKS must call Google Cloud APIs without any long-lived Google credential stored in the cluster. What should be configured?

   • AWorkload Identity Federation with the external providerCorrect answer
   • BA downloaded service account key stored as a Kubernetes secret
   • CA dedicated Cloud Identity user account with a stored password
   • DAn API key embedded in the workload's configuration

   Why

   Workload Identity Federation lets an external workload exchange its own provider-issued token for short-lived Google Cloud credentials, so no service account key is stored anywhere. Downloading a service account key into the cluster creates exactly the long-lived credential being avoided, a user account is not appropriate for a workload, and an API key does not authorize IAM-protected Google Cloud APIs in this way.

4. 4.A security review finds dozens of service account keys older than two years across many projects. Which control most directly prevents new keys from being created?

   • AAn organization policy constraint disabling service account key creationCorrect answer
   • BRotating all existing service account keys
   • CA Cloud Monitoring alert on key creation events
   • DA documented internal standard discouraging key use

   Why

   The organization policy constraint that disables service account key creation blocks the creation of new keys at the hierarchy level, forcing teams toward impersonation and federation. Rotating the existing keys does not stop new ones from appearing, an alert on key creation detects rather than prevents, and documenting a standard relies on voluntary compliance.

5. 5.A developer needs to run a command as a service account for a one-off troubleshooting task, without obtaining any key material. Which mechanism supports this?

   • AService account impersonation via the Service Account Token Creator roleCorrect answer
   • BDownloading a JSON key for the service account
   • CAdding the developer as a project owner
   • DCopying an access token from another running system

   Why

   Granting the Service Account Token Creator role lets the developer impersonate the service account and receive a short-lived access token, with the impersonation recorded in audit logs. Downloading a key produces exactly the long-lived credential being avoided, adding the developer as a project owner grants far more than needed, and copying an existing token from another system is neither supported nor auditable.

Practice all 65 questions

Frequently asked questions