- A
Destructive testing — deliberately breaking the system to determine the breaking point.
Why wrong: Destructive testing pushes a system to failure to find limits. Chaos engineering is more controlled: small, deliberate experiments in production to discover unknown weaknesses, not to find the breaking point.
- B
Chaos engineering — deliberately injecting controlled failures to discover system weaknesses and build resilience confidence.
Chaos engineering tests system resilience through controlled failure injection. Each experiment validates (or reveals gaps in) the system's ability to handle unexpected failures without impacting users.
- C
Penetration testing — simulating attacks to find security vulnerabilities.
Why wrong: Penetration testing probes security defenses by simulating attacker techniques. Chaos engineering tests operational resilience through failure injection — a different domain.
- D
Load testing — verifying the system handles expected traffic volumes.
Why wrong: Load testing validates performance under expected (and peak) traffic volumes. Chaos engineering tests resilience to failures and unexpected conditions, not traffic volume.
Quick Answer
The answer is chaos engineering, the practice of deliberately injecting controlled failures like killing random instances, introducing network latency, or cutting database connections to proactively identify weaknesses in a distributed system. This approach is correct because it moves beyond theoretical resilience testing by actively observing how a system behaves under real failure conditions, allowing teams to build confidence in their system’s ability to recover. On the Google Cloud Digital Leader exam, this concept tests your understanding of reliability engineering principles, often appearing alongside tools like Chaos Monkey or Google’s DiRT (Disaster Recovery Testing). A common trap is confusing chaos engineering with standard load testing or disaster recovery planning—remember that chaos engineering is specifically about *proactive, controlled failure injection* to uncover unknown weaknesses, not just verifying known recovery steps. For a memory tip, think of it as “breaking things on purpose to make them stronger,” much like a vaccine introduces a weakened virus to build immunity.
Cloud Digital Leader Scaling with Google Cloud operations Practice Question
This GCDL practice question tests your understanding of scaling with google cloud operations. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
A reliability engineering team wants to proactively identify weaknesses in their distributed system by deliberately injecting failures — killing random instances, introducing network latency, and cutting off database connections — to observe how the system responds. What is this practice called?
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
Chaos engineering — deliberately injecting controlled failures to discover system weaknesses and build resilience confidence.
Option B is correct because chaos engineering is the practice of deliberately injecting controlled failures—such as killing instances, introducing latency, or cutting database connections—into a distributed system to proactively identify weaknesses and build resilience confidence. This approach aligns with Google Cloud's reliability principles, where tools like Chaos Monkey (part of the Simian Army) or Google's internal DiRT (Disaster Recovery Testing) are used to test system behavior under failure conditions.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Destructive testing — deliberately breaking the system to determine the breaking point.
Why it's wrong here
Destructive testing pushes a system to failure to find limits. Chaos engineering is more controlled: small, deliberate experiments in production to discover unknown weaknesses, not to find the breaking point.
- ✓
Chaos engineering — deliberately injecting controlled failures to discover system weaknesses and build resilience confidence.
Why this is correct
Chaos engineering tests system resilience through controlled failure injection. Each experiment validates (or reveals gaps in) the system's ability to handle unexpected failures without impacting users.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
Penetration testing — simulating attacks to find security vulnerabilities.
Why it's wrong here
Penetration testing probes security defenses by simulating attacker techniques. Chaos engineering tests operational resilience through failure injection — a different domain.
- ✗
Load testing — verifying the system handles expected traffic volumes.
Why it's wrong here
Load testing validates performance under expected (and peak) traffic volumes. Chaos engineering tests resilience to failures and unexpected conditions, not traffic volume.
Common exam traps
Common exam trap: answer the scenario, not the keyword
Google Cloud often tests the distinction between 'destructive testing' and 'chaos engineering' by making candidates think any deliberate failure is destructive, but the key difference is that chaos engineering is controlled, hypothesis-driven, and aims to build resilience, not just find the breaking point.
Detailed technical explanation
How to think about this question
Under the hood, chaos engineering often uses a 'blast radius' concept to limit the impact of experiments, ensuring that failures are contained to a subset of services (e.g., using feature flags or traffic shadowing). Real-world scenarios include Netflix's Chaos Monkey randomly terminating EC2 instances in production to ensure auto-scaling groups and load balancers handle the loss gracefully, or Google's DiRT testing that simulates entire datacenter outages to validate multi-region failover mechanisms. A subtle behavior is that chaos experiments must be monitored with metrics like error budgets and SLOs to avoid cascading failures that exceed acceptable thresholds.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A healthcare organisation deploys an application with a public-facing web tier and a private database tier. The database subnet has no public IP and only accepts connections from the web tier's security group. Questions like this test whether you can design cloud network isolation using VNets/VPCs, subnets, and security group rules.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Scaling with Google Cloud operations — study guide chapter
Learn the concepts, then practise the questions
- →
Scaling with Google Cloud operations practice questions
Targeted practice on this topic area only
- →
All GCDL questions
507 questions across all exam domains
- →
Google Cloud Digital Leader study guide
Full concept coverage aligned to exam objectives
- →
GCDL practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related GCDL practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Why cloud technology is transforming business practice questions
Practise GCDL questions linked to Why cloud technology is transforming business.
Fundamental cloud concepts practice questions
Practise GCDL questions linked to Fundamental cloud concepts.
Google Cloud products, services, and solutions practice questions
Practise GCDL questions linked to Google Cloud products, services, and solutions.
Scaling with Google Cloud operations practice questions
Practise GCDL questions linked to Scaling with Google Cloud operations.
Trust and security with Google Cloud practice questions
Practise GCDL questions linked to Trust and security with Google Cloud.
GCDL fundamentals practice questions
Practise GCDL questions linked to GCDL fundamentals.
GCDL scenario practice questions
Practise GCDL questions linked to GCDL scenario.
GCDL troubleshooting practice questions
Practise GCDL questions linked to GCDL troubleshooting.
Practice this exam
Start a free GCDL practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this GCDL question test?
Scaling with Google Cloud operations — This question tests Scaling with Google Cloud operations — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Chaos engineering — deliberately injecting controlled failures to discover system weaknesses and build resilience confidence. — Option B is correct because chaos engineering is the practice of deliberately injecting controlled failures—such as killing instances, introducing latency, or cutting database connections—into a distributed system to proactively identify weaknesses and build resilience confidence. This approach aligns with Google Cloud's reliability principles, where tools like Chaos Monkey (part of the Simian Army) or Google's internal DiRT (Disaster Recovery Testing) are used to test system behavior under failure conditions.
What should I do if I get this GCDL question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 30, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.