Cloud Digital Leader Scaling with Google Cloud operations Practice Question
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?
⚠ Common exam trap
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.
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.
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.
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 is a validation technique that intentionally forces a system past its operational limits to identify the exact point of failure, such as maximum concurrent users or data capacity. Unlike chaos engineering, which injects small, controlled failures in a live environment to observe resilience and recovery, destructive testing is not incremental or hypothesis-driven—it seeks a single breaking threshold. The goal is to characterize absolute limits, not to build ongoing confidence in the system's ability to gracefully degrade under unexpected conditions.
- ✓
Chaos engineering — deliberately injecting controlled failures to discover system weaknesses and build resilience confidence.
Why this is correct
Chaos engineering is the disciplined practice of introducing controlled failures (e.g., terminating a service instance, injecting latency, or simulating a network partition) into a distributed system to observe behavior against a defined steady-state hypothesis. It is a scientific method for verifying that the system can self-heal and maintain user impact within acceptable bounds, and it typically is performed with a limited blast radius and continuous experimentation. The objective is not merely to find a breaking point, but to build resilience confidence by uncovering unknown architectural weaknesses before they manifest as real outages.
- ✗
Penetration testing — simulating attacks to find security vulnerabilities.
Why it's wrong here
Penetration testing is a security assessment that simulates malicious attacks—such as SQL injection, phishing, or privilege escalation—to identify exploitable vulnerabilities in an application's security controls. While both penetration testing and chaos engineering involve intentional disruption, penetration testing targets CIA (confidentiality, integrity, availability) threats and relies on known attack patterns; chaos engineering targets operational resilience to failures like hardware crashes, network faults, or dependency outages. Thus, penetration testing answers 'Can attackers break in?' while chaos engineering answers 'Can the system withstand inevitable operational faults without impacting users?'
- ✗
Load testing — verifying the system handles expected traffic volumes.
Why it's wrong here
Load testing evaluates how a system behaves under expected and peak traffic volumes, measuring metrics like response time, throughput, and resource utilization. It is a performance validation technique that uses synthetic or recorded user traffic to verify capacity planning and scaling decisions, but it assumes the underlying infrastructure is healthy. Chaos engineering, in contrast, introduces abnormal conditions—service failures, packet loss, clock skew—that are unrelated to traffic volume, so it tests the system's ability to handle unexpected operational stress rather than the amount of load it can process.
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Recovery
Recovery is the process of restoring systems, data, and operations after a security incident, failure, or disaster to return to normal functioning.
Key term
Reliability
Reliability is the measure of a system's ability to consistently perform its intended functions without failure over a specified period of time under stated conditions.
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.