Chaos engineering basics in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the main goal of chaos engineering.

Microservices

chaos_engineering_goal = "[1]"

Drag options to blanks, or click blank then click option'

Ato avoid any system testing

Bto increase system downtime intentionally

Cto improve system resilience by testing failures

Dto reduce system monitoring

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing chaos engineering with causing system downtime.

Thinking chaos engineering avoids testing.

The main goal of chaos engineering is to improve system resilience by intentionally testing failures in a controlled way.

2fill in blank

medium

Complete the code to identify a common tool used in chaos engineering for microservices.

Microservices

common_chaos_tool = "[1]"

Drag options to blanks, or click blank then click option'

AChaos Monkey

BKubernetes

CDocker

DPrometheus

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing Kubernetes or Docker which are container tools, not chaos tools.

Selecting Prometheus which is a monitoring tool.

Chaos Monkey is a popular tool used to randomly terminate instances in microservices to test system resilience.

3fill in blank

hard

Fix the error in the code that simulates a failure injection in a microservice.

Microservices

def inject_failure(service):
    if service.status == 'healthy':
        service.status = '[1]'
    return service.status

Drag options to blanks, or click blank then click option'

Afailed

Brunning

Cstarting

Didle

Attempts:

3 left

💡 Hint

Common Mistakes

Setting status to 'running' or 'starting' which means the service is healthy.

Using 'idle' which does not indicate failure.

To simulate failure, the service status should be set to 'failed'.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that maps microservice names to their failure status if they are unhealthy.

Microservices

failure_map = {service.name: service.status for service in services if service.status [1] '[2]'}

Drag options to blanks, or click blank then click option'

A!=

B==

Cfailed

Dhealthy

Attempts:

3 left

💡 Hint

Common Mistakes

Using '==' with 'healthy' which selects healthy services instead of failures.

Using '!=' with 'failed' which would select healthy services.

The comprehension filters services whose status is not equal to 'healthy', mapping their names to their status.

5fill in blank

hard

Fill all three blanks to create a function that triggers chaos experiments only if the system is stable and the experiment is approved.

Microservices

def trigger_chaos(system_status, experiment_approved):
    if system_status [1] 'stable' and experiment_approved [2] True:
        return '[3]'
    else:
        return 'Do not run experiment'

Drag options to blanks, or click blank then click option'

A==

B!=

CRun experiment

DFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using '!=' which would invert the logic.

Returning 'False' or other strings instead of 'Run experiment'.

The function checks if the system status equals 'stable' and the experiment is approved (True), then returns 'Run experiment'.

Practice

1. What is the main goal of chaos engineering in microservices?

easy

A. To reduce the number of developers needed

B. To increase the number of microservices in a system

C. To find and fix weaknesses before real failures occur

D. To speed up the deployment process

Solution

1. Step 1: Understand chaos engineering purpose

   Chaos engineering is about testing systems by intentionally causing failures to find weaknesses.

2. Step 2: Identify the main goal

   The goal is to find and fix weaknesses before they cause real problems in production.

3. Final Answer:

   To find and fix weaknesses before real failures occur -> Option C

4. Quick Check:

   Chaos engineering goal = Find and fix weaknesses [OK]

Hint: Chaos engineering tests failures to improve system stability [OK]

Common Mistakes:

• Thinking chaos engineering increases microservices count
• Confusing chaos engineering with deployment speedup
• Assuming chaos engineering reduces developer count

2. Which of the following is a correct way to start chaos engineering experiments?

easy

A. Start with complex multi-service failures immediately

B. Begin with simple, controlled failure tests

C. Run chaos tests only after a system crash

D. Avoid monitoring during chaos experiments

Solution

1. Step 1: Review best practice for chaos experiments

   Best practice is to start small with simple, controlled failures to understand system behavior.

2. Step 2: Identify the correct starting approach

   Starting with simple tests helps safely learn and improve system resilience gradually.

3. Final Answer:

   Begin with simple, controlled failure tests -> Option B

4. Quick Check:

   Start chaos with simple tests = Begin with simple, controlled failure tests [OK]

Hint: Start chaos tests simple and controlled, not complex [OK]

Common Mistakes:

• Starting with complex failures too soon
• Running chaos only after failures happen
• Ignoring monitoring during tests

3. Consider a microservice system where a chaos experiment randomly kills one instance every 5 minutes. What is the expected immediate effect on system availability?

medium

A. System availability remains stable if redundancy exists

B. System availability drops to zero immediately

C. System crashes permanently after first kill

D. System automatically scales down instances

Solution

1. Step 1: Analyze the chaos experiment impact

   Killing one instance every 5 minutes tests resilience but does not remove all instances.

2. Step 2: Consider system redundancy

   If the system has redundant instances, killing one does not reduce availability immediately.

3. Final Answer:

   System availability remains stable if redundancy exists -> Option A

4. Quick Check:

   Redundancy keeps availability stable during chaos [OK]

Hint: Redundancy keeps system available despite instance failures [OK]

Common Mistakes:

• Assuming system crashes immediately after one instance killed
• Thinking availability drops to zero instantly
• Believing system scales down automatically

4. A chaos experiment script intended to shut down a microservice instance sometimes fails silently without stopping the instance. What is the most likely cause?

medium

A. The network is too fast for the script

B. The microservice is designed to never stop

C. The chaos experiment is running on a different system

D. The script lacks proper error handling and logging

Solution

1. Step 1: Identify why script fails silently

   Silent failures usually happen when errors are not caught or logged properly.

2. Step 2: Evaluate other options

   Microservices can be stopped; network speed does not cause silent failure; running on different system would cause errors, not silent failure.

3. Final Answer:

   The script lacks proper error handling and logging -> Option D

4. Quick Check:

   Silent failure = Missing error handling [OK]

Hint: Check error handling if chaos script fails silently [OK]

Common Mistakes:

• Assuming microservice cannot be stopped
• Blaming network speed for silent failure
• Ignoring script environment mismatch

5. You want to design a chaos engineering experiment to test how your microservices handle database latency spikes. Which approach best fits this goal?

hard

A. Inject artificial latency into database calls during tests

B. Disable monitoring tools to avoid false alerts

C. Increase the number of database replicas without testing

D. Randomly kill microservice instances during peak hours

Solution

1. Step 1: Understand the goal of testing database latency spikes

   The goal is to see how microservices behave when database responses are slow.

2. Step 2: Choose the best chaos experiment approach

   Injecting artificial latency simulates slow database calls directly, matching the goal.

3. Step 3: Evaluate other options

   Killing instances tests availability, not latency; increasing replicas without testing doesn't simulate latency; disabling monitoring hides important data.

4. Final Answer:

   Inject artificial latency into database calls during tests -> Option A

5. Quick Check:

   Test latency by injecting delays = Inject artificial latency into database calls during tests [OK]

Hint: Inject delays to test latency, not kill instances [OK]

Common Mistakes:

• Confusing instance failure with latency testing
• Adding replicas without testing effects
• Turning off monitoring during chaos