Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create one large project for all teams and split the bill manually at month-end.

  Why it's wrong here

  A single project hosting all teams merges every team's resources into one billing line item, so splitting the bill manually at month-end relies on error-prone spreadsheet or export manipulation rather than real-time attribution. GCP projects provide isolation boundaries for quotas, IAM, and budgets; without separate projects, teams lose independent budget alerts and quota limits, leading to one team's bursty usage causing broader failures. Label-based cost allocation inside a single project is possible only if labeling is strictly enforced, but manual reconciliation still fails to provide live accountability and makes sub-team granularity fragile.

• ✓

  Use separate projects per team within a folder structure, with resource labels for sub-team cost attribution.

  Why this is correct

  Separate projects per team, placed under a folder structure, enforce a clean resource hierarchy: each project is the primary billing boundary, so Cloud Billing reports and budget alert thresholds map directly to a team. Resource labels add a second dimension, enabling sub-team or product-level cost breakdowns through BigQuery billing export, which is the precise mechanism for granular chargeback. This approach preserves GCP-native elastic capacity and self-service while giving finance a structured, queryable view of spend.

• ✗

  Purchase dedicated hardware for each team so costs are inherently separate.

  Why it's wrong here

  Purchasing dedicated hardware per team directly contradicts the cloud operating model: it requires upfront capacity planning, ongoing hardware lifecycle management, and provides no elasticity to scale with demand. GCP cost management is organized around logical boundaries like projects and billing accounts, not physical infrastructure; dedicated hardware also eliminates the ability to use resource labels, budgets, or per-second metering. Even if isolated physically, it doesn't integrate with Cloud Billing's reporting, making cross-cloud or shared-account cost oversight impossible.

• ✗

  Use Cloud Identity to create separate accounts for each team and bill separately.

  Why it's wrong here

  Cloud Identity is an identity-as-a-service (IDaaS) product for managing user accounts, authentication, and device trust; it does not create or control billing accounts, and it cannot isolate GCP resource costs. Billing separation is achieved by attaching projects to different billing accounts or by using labels within one account; creating separate identity accounts for teams would only fragment access governance, not resource spend. It also ignores the fact that projects, not identities, are the unit of cost aggregation, and misusing identity for billing would create operational friction for SSO and group policies.

Go deeper

Related to this question