Google Professional Cloud Developer Question 298
Select 3Google Cloud PlatformYou are a developer for an e-commerce application deployed on Google Kubernetes Engine (GKE). The application uses a microservices architecture, and you want to implement chaos engineering to improve its reliability. Which of the following actions would be appropriate for implementing failure testing in this scenario?
- A
Simulate pod failures to ensure automatic rescheduling works as expected.
- B
Introduce random delays in service-to-service communication to test timeout handling.
- C
Manually delete Kubernetes nodes to verify the application’s fault tolerance.
- D
Simulate a network partition between services to test failover and retries.
- E
Disable liveness and readiness probes for all pods to observe application behavior.
Show answer and explanation
Correct answers: A, B, D
Explanation
Chaos engineering involves deliberately introducing failures or disruptions into the system to test its resilience and recovery mechanisms. Actions such as simulating pod failures, adding delays in communication, and testing network partitions are valid practices to identify weaknesses and improve the system’s reliability. However, actions like deleting nodes or disabling health checks can cause unnecessary disruptions and are not aligned with chaos engineering best practices.
- A. Correct.
Simulating pod failures is a common chaos engineering practice to verify that the Kubernetes scheduler automatically reschedules pods and maintains availability.
- B. Correct.
Introducing random delays in service communication helps test the system’s resilience to latency and the effectiveness of timeout configurations.
- C. Incorrect.
Manually deleting Kubernetes nodes is not an ideal chaos engineering practice as it does not simulate real-world scenarios effectively and can disrupt the environment unnecessarily.
- D. Correct.
Simulating a network partition is a valid chaos engineering technique to assess how the system handles failover scenarios and retries.
- E. Incorrect.
Disabling liveness and readiness probes for all pods is not recommended as it disrupts the health-checking mechanism essential for maintaining service reliability.