Courseiva
Scaling with Google Cloud operationseasyMultiple ChoiceObjective-mapped

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Google Cloud runs its own infrastructure operations using the Site Reliability Engineering (SRE) model, which Google invented. What is the core principle that distinguishes SRE from traditional IT operations?

⚠ Common exam trap

The GCDL exam often tests the misconception that SRE is just a rebranding of traditional IT operations or that it prohibits deployments entirely; the trap here is assuming SRE is purely about stability at the expense of innovation, when in fact it uses error budgets to balance both.

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

SRE applies software engineering principles to operations — automating toil, using quantitative SLOs, and treating reliability as an engineered system property.

The core principle of SRE is applying software engineering practices to operations work. This means automating manual toil, defining quantitative Service Level Objectives (SLOs) to measure reliability, and treating reliability as an engineered property of the system — not as an afterthought. This contrasts with traditional IT operations, which often rely on manual processes and reactive troubleshooting.

Answer analysis

Option-by-option breakdown

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

  • SRE teams never allow production deployments to ensure maximum stability.

    Why it's wrong here

    SRE does not block production changes; it would stagnate products if no deployments were allowed. Instead, SRE uses an error budget derived from the SLO to decide when changes are safe, so teams can ship quickly when reliability is within budget and slow down only when the budget is exhausted. This balances velocity with stability rather than eliminating all risk, and it is a core principle distinguishing SRE from change-averse operations models.

  • SRE applies software engineering principles to operations — automating toil, using quantitative SLOs, and treating reliability as an engineered system property.

    Why this is correct

    Site Reliability Engineering deliberately applies software engineering practices to operations itself: repetitive toil is automated with code, reliability is measured through quantitative service level objectives (SLOs) and error budgets, and systems are engineered with failure modes in mind rather than managed reactively. SREs write code for automation, use peer review and version control for operational artifacts, and treat reliability as a design property you can measure and tune. This is fundamentally different from traditional IT operations.

  • SRE relies entirely on external monitoring vendors to detect and respond to all incidents.

    Why it's wrong here

    While SRE teams use monitoring products like Cloud Monitoring, they do not outsource detection and response. Instead, SREs own their instrumentation, custom metrics, alerting rules, and incident command procedures, building or configuring systems that surface the exact failure modes their services may face. Relying entirely on external vendors would forfeit the internal engineering ownership and continuous improvement that are central to SRE. That is why this option mischaracterizes the model.

  • SRE means development and operations teams are separate departments that communicate only via ticketing systems.

    Why it's wrong here

    This describes traditional siloed IT operations, where developers hand work to a separate operations team through tickets, creating delays and shifting accountability. SRE intentionally breaks that wall by embedding reliability engineers with product teams, so they share on-call duties, code ownership, and continuous collaboration. Thus, SRE is the opposite of a ticket-based handoff; it is shared ownership of the same service.

About these practice questions

Courseiva writes every GCDL question from scratch — 829 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.