Cloud Digital Leader Scaling with Google Cloud operations Practice Question
A platform engineering team is designing a self-service cloud environment for development teams. They want developers to be able to provision approved cloud resources quickly without waiting for central IT approval for every request, while still ensuring compliance with security and cost policies. Which architectural approach best balances developer agility with governance?
⚠ Common exam trap
Google Cloud often tests the misconception that giving developers full access (Option B) or restricting them to a sandbox (Option D) are acceptable trade-offs, when in fact the correct answer requires a policy-as-code approach that enforces guardrails automatically without manual intervention.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Provide a self-service catalog of pre-approved, policy-compliant infrastructure templates with automated provisioning, budget alerts, and org policy guardrails — enabling developer agility while enforcing compliance automatically
It uses a self-service catalog with pre-approved, policy-compliant templates (e.g., Deployment Manager or Terraform configurations) combined with Organization Policy Service guardrails and automated budget alerts. This approach allows developers to provision resources on demand while enforcing security and cost policies automatically, balancing agility with governance without manual bottlenecks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require all resource provisioning requests to be submitted as tickets to the central IT team for manual review and approval before any resources are created
Why it's wrong here
A manual ticket-based approval process for every resource request introduces a serial bottleneck that directly contravenes cloud agility. It forces developers to wait hours or days for even routine, low-risk changes, and it does not scale as the number of developers and deployments grows. Moreover, manual review is inherently inconsistent—the same request may be approved or rejected differently depending on the reviewer—and it prevents the use of infrastructure-as-code, policy-as-code, or CI/CD automation that can enforce compliance continuously and consistently.
- ✗
Give all developers Owner access to all Google Cloud projects so they can provision any resources without delays
Why it's wrong here
Granting Owner access to all Google Cloud projects to all developers removes all governance guardrails and violates the principle of least privilege. With Owner, a developer can modify IAM policies to grant access to others, delete projects or resources, disable audit logging, and change org policies or budget alerts, effectively bypassing every cost and security control. This is the opposite of agility within guardrails; it creates an environment where one accidental misconfiguration can lead to data exposure, runaway costs, or a complete loss of operational visibility, making the platform inherently unsafe.
- ✓
Provide a self-service catalog of pre-approved, policy-compliant infrastructure templates with automated provisioning, budget alerts, and org policy guardrails — enabling developer agility while enforcing compliance automatically
Why this is correct
This is the platform engineering approach: build the rails, not the roads. Pre-approved templates (Terraform modules, Config Connector blueprints) let developers self-serve within defined boundaries. Org policies prevent non-compliant configurations. Budget alerts enforce cost controls. Developers move fast; governance is automated, not manual.
- ✗
Allow developers to provision resources freely in a shared sandbox project only, keeping production entirely controlled by central IT
Why it's wrong here
Restricting developer self-service to a shared sandbox project while keeping production under central IT control fails to deliver agility for the environments that matter. Sandbox projects typically have limited quotas, no real service accounts, and a different network topology, so code that works there may fail when it reaches production, causing integration and configuration drift. At the same time, central IT approval for production resources re-introduces the exact bottleneck that cloud is meant to eliminate, stalling critical deployments and delaying releases. Developers need self-service in production-like, policy-compliant environments—using pre-approved templates and automated guardrails—not just a low-risk playground.
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Compliance
Compliance is the process of ensuring that an organization follows laws, regulations, standards, and internal policies that apply to its operations and data handling.
Key term
Terraform
Terraform is an infrastructure-as-code tool that lets you define and manage your IT infrastructure using configuration files instead of manual processes.
About these practice questions
This GCDL question is part of Courseiva's 829-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.