GCP-ACE - Setting up a cloud solution environment (20% of the exam) - Section 1.1
Set up cloud projects and accounts, including creating a resource hierarchy, applying organization policies to it, granting IAM roles within a project, managing users and groups in Cloud Identity, enabling APIs, assessing quotas, and configuring Cloud Asset Inventory and Workforce Identity Federation.
Create a resource hierarchy of organization, folders, and projects, and choose the level at which an organization policy or IAM binding should be attached so that it inherits correctly to the resources below it. Manage users and groups in Cloud Identity, enable the APIs a project needs, assess quotas and request increases, and configure Cloud Asset Inventory and Workforce Identity Federation for external workforce access.
lock_openFree sampleSetting up a cloud solution environmentmedium
A consultancy's staff are managed in an external identity provider (Okta). They need short-term interactive access to the Google Cloud console and gcloud, and your company does not want to create or synchronise Cloud Identity accounts for them. Which approach fits this requirement?
ACreate a Cloud Identity user account for every consultant, grant the needed roles, and delete each account when the engagement finishes.
BConfigure Workforce Identity Federation with an Okta pool so the consultants sign in with their existing Okta identities and receive short-lived Google Cloud access.check_circle Correct
CConfigure Workload Identity Federation to map the consultants' Okta identities onto a service account they use for the console.
DCreate one shared service account, generate a key for it, and distribute that key to all of the consultants for the duration.
Workforce Identity Federation gives external human workforces console and gcloud access via their own IdP without provisioning Cloud Identity accounts. Workforce Identity Federation federates an external identity provider such as Okta for human users, issuing short-lived credentials on sign-in, so no Cloud Identity user accounts need to be created or kept in sync for the external staff.
Why A is wrong: Tempting because it clearly works, but it is exactly the account provisioning and lifecycle overhead the requirement rules out, and it duplicates identities already managed in Okta.
Why B is correct: Correct because Workforce Identity Federation is built for external human workforces: users authenticate through the external IdP and receive short-lived credentials, with no Cloud Identity accounts to create or sync.
Why C is wrong: Tempting because it also federates external identities without new accounts, but Workload Identity Federation is designed for workloads and applications, not interactive human sign-in to the console.
Why D is wrong: Tempting because it avoids per-person accounts, but sharing one service account key destroys per-user attribution and is a well-known security anti-pattern that GCP guidance warns against.
Exam traps in Setting up a cloud solution environment
Answers that look right on this material and are not. Each one is a distractor from a different question in the GCP-ACE bank for this domain.
Grant the Editor role to each engineer's individual user account, updating every project's IAM policy by hand as people join or leave the team.
errorWhy it is wrong: Tempting because per-user bindings are explicit and easy to reason about, but they scale poorly: each joiner or leaver forces a manual IAM policy edit, which is the maintenance burden the group approach is meant to remove.
Workforce Identity Federation grants applications running outside Google Cloud access to resources, while Workload Identity Federation signs in human users from an external provider.
errorWhy it is wrong: Tempting because both names sound interchangeable, but the roles are reversed: workforce covers human users and workload covers applications, so this option swaps the two.
Grant the contractor the Storage Object Admin role at the project level so the binding is easy to locate.
errorWhy it is wrong: A project-level binding applies to every bucket in the project, giving the contractor object access well beyond the single bucket and breaching the least-privilege requirement.