Why service mesh manages inter-service traffic in Microservices - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use a service mesh for inter-service communication?

Which of the following best explains why a service mesh is used to manage inter-service traffic in microservices?

A It stores all service data in a single database to simplify data management.

B It replaces the need for any API gateways by directly exposing all services to the internet.

C It provides a centralized way to handle service discovery, load balancing, and secure communication between services without changing service code.

D It automatically scales the number of services based on CPU usage without configuration.

💡 Hint

Think about how a service mesh helps services talk to each other safely and efficiently.

A service mesh manages communication between microservices by handling service discovery, load balancing, encryption, and retries transparently. This avoids changing each service's code and centralizes traffic control.

💻 Command Output

intermediate

Output of service mesh sidecar proxy status command

What is the expected output when running the command istioctl proxy-status in a Kubernetes cluster with Istio service mesh installed?

Microservices

istioctl proxy-status

A

NAME                                                   CDS        LDS        EDS        RDS        ISTIOD
productpage-5d8f7d6f7f-abcde.default                    SYNCED     SYNCED     SYNCED     SYNCED     istiod-1234567890-xyz
reviews-6f7d8c9d7f-fghij.default                        SYNCED     SYNCED     SYNCED     SYNCED     istiod-1234567890-xyz

B Error: command not found

C No proxies found in the cluster

D Pod productpage-5d8f7d6f7f-abcde is not ready

💡 Hint

This command shows the synchronization status of sidecar proxies managed by Istio.

The istioctl proxy-status command lists all sidecar proxies and their synchronization states with the control plane components like CDS, LDS, EDS, and RDS.

🔀 Workflow

advanced

Steps to enable mutual TLS in a service mesh

Which sequence correctly describes the steps to enable mutual TLS (mTLS) between services in a service mesh?

A 2,1,3,4

B 2,3,1,4

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about configuring policies before deploying and verifying certificates.

First, enable mTLS policy so the mesh knows to secure traffic. Then deploy services with sidecars to enforce it. Next, certificates are issued to proxies for encryption. Finally, test communication to confirm mTLS works.

❓ Troubleshoot

advanced

Troubleshooting failed inter-service calls in a service mesh

You notice that service A cannot reach service B in a service mesh environment. Which of the following is the most likely cause?

A The database used by service A is down.

B The sidecar proxy for service B is not running or crashed.

C Service A has no CPU resources allocated.

D The Kubernetes node running service B is out of disk space.

💡 Hint

Focus on components directly involved in inter-service communication.

If the sidecar proxy for service B is down, service A's requests cannot be routed properly, causing communication failure.

✅ Best Practice

expert

Best practice for managing inter-service traffic with a service mesh

Which practice is considered best for managing inter-service traffic in a service mesh to ensure reliability and security?

A Use sidecar proxies to enforce policies like retries, timeouts, and mutual TLS without modifying service code.

B Disable all sidecar proxies and let services handle communication directly for better performance.

C Store all service credentials in environment variables inside each service container.

D Allow all traffic between services without restrictions to reduce configuration complexity.

💡 Hint

Think about how to keep services secure and reliable without changing their code.

Sidecar proxies provide a transparent layer to enforce communication policies, improving security and reliability without service code changes.