Chaos engineering basics in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary goal of chaos engineering?

Chaos engineering is a practice used in microservices to improve system reliability. What is its main goal?

A To intentionally introduce failures to identify weaknesses before they cause real problems

B To speed up the deployment process by automating tests

C To replace manual monitoring with automated alerts

D To reduce the number of microservices in a system

💡 Hint

Think about why we would want to cause failures on purpose in a system.

Chaos engineering intentionally causes failures to find weaknesses early, so teams can fix them before users are affected.

❓ Architecture

intermediate

Which component is essential in a chaos engineering system for safely running experiments?

In a microservices architecture, chaos experiments must be controlled to avoid major outages. Which component helps manage this safely?

A Load balancer that distributes traffic evenly

B Chaos experiment orchestrator that schedules and controls failure injections

C Database replication system for backups

D API gateway for routing requests

💡 Hint

Consider which part controls when and how failures happen during chaos testing.

The chaos experiment orchestrator schedules and controls failure injections, ensuring experiments run safely and can be stopped if needed.

❓ scaling

advanced

How should chaos experiments scale in a large microservices system?

When applying chaos engineering to a large system with many microservices, what is the best approach to scaling experiments?

A Start with small, isolated experiments on critical services and gradually increase scope

B Run chaos experiments on all services simultaneously to find all issues quickly

C Scale experiments by increasing the number of injected failures per service immediately

D Only test non-critical services to avoid impacting users

💡 Hint

Think about minimizing risk while learning about system weaknesses.

Starting small and isolated reduces risk and helps understand system behavior before expanding experiments.

❓ tradeoff

advanced

What is a key tradeoff when running chaos experiments in production?

Running chaos experiments in a live production environment can improve reliability but also has risks. What is a key tradeoff?

A Choosing between faster deployments and slower rollback times

B Selecting between cloud and on-premise infrastructure

C Balancing between discovering hidden failures and risking temporary user impact

D Deciding whether to use manual or automated monitoring tools

💡 Hint

Consider what happens when you cause failures in a system users rely on.

Chaos experiments can reveal hidden issues but may cause temporary disruptions, so teams must balance learning with user experience.

❓ estimation

expert

Estimate the minimum number of chaos experiments needed to cover 10 microservices with 3 failure types each, assuming independent tests.

You have 10 microservices and want to test 3 failure types (e.g., latency, error, crash) on each independently. What is the minimum number of chaos experiments to cover all cases?

A 10 experiments

B 13 experiments

C 3 experiments

D 30 experiments

💡 Hint

Multiply the number of services by the number of failure types for independent tests.

Each microservice needs 3 separate failure tests, so 10 services × 3 failure types = 30 experiments.