Service mesh concept in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary role of a service mesh in microservices?

Imagine you have many small services talking to each other in an app. What main job does a service mesh do?

A It stores all the data used by the microservices in a central database.

B It compiles the code of all microservices into a single executable.

C It replaces the need for containers by running services directly on hardware.

D It manages communication between services, handling security, routing, and monitoring.

💡 Hint

Think about how services talk and stay safe and visible.

A service mesh helps microservices communicate securely and reliably by managing traffic, security policies, and observability without changing the services themselves.

💻 Command Output

intermediate

What output does this Istio command produce?

Run the command istioctl proxy-status in a Kubernetes cluster with Istio installed. What does it show?

Microservices

istioctl proxy-status

A A list of all Envoy proxies connected to the Istio control plane with their sync status.

B The current CPU and memory usage of the Istio control plane pods.

C A list of all Kubernetes nodes and their IP addresses.

D The version of Istio installed on the cluster.

💡 Hint

Think about what 'proxy-status' might mean in Istio.

The command shows the status of Envoy proxies (sidecars) connected to the Istio control plane, including if their configurations are synced.

🔀 Workflow

advanced

Order the steps to enable mutual TLS (mTLS) in a service mesh

Put these steps in the correct order to enable mutual TLS between services in a service mesh.

A 1,3,2,4

B 1,2,3,4

C 3,1,2,4

D 2,1,3,4

💡 Hint

Think about preparing the namespace, deploying services, then enforcing policies.

First, enable sidecar injection so proxies are added. Then deploy services with sidecars. Next, apply the mTLS policy. Finally, verify the setup.

❓ Troubleshoot

advanced

Why might a service mesh cause increased latency between microservices?

You notice that calls between microservices are slower after adding a service mesh. What is a likely cause?

A The service mesh merges all services into one, causing bottlenecks.

B The sidecar proxies add extra network hops and encryption overhead.

C The service mesh disables caching in the microservices.

D The microservices are running on slower hardware than before.

💡 Hint

Think about what sidecars do to network traffic.

Sidecar proxies intercept and encrypt traffic, adding processing time and extra network hops, which can increase latency.

✅ Best Practice

expert

Which practice best improves observability in a service mesh?

To understand how your microservices behave in a service mesh, which practice is best?

A Only monitor the main application containers, ignoring sidecars.

B Disable all logging to reduce noise and improve performance.

C Enable distributed tracing and collect metrics from sidecar proxies.

D Use manual log parsing instead of automated tools.

💡 Hint

Think about how to get detailed info from all parts of the mesh.

Distributed tracing and metrics from sidecars give detailed insights into service interactions and performance.

Practice

1. What is the main purpose of a service mesh in microservices architecture?

easy

A. To write application business logic

B. To store data for microservices

C. To replace microservices with monolithic applications

D. To manage communication between microservices securely and reliably

Solution

1. Step 1: Understand the role of service mesh

   A service mesh handles how microservices talk to each other, focusing on communication.

2. Step 2: Identify what service mesh does not do

   It does not store data, replace microservices, or write business logic.

3. Final Answer:

   To manage communication between microservices securely and reliably -> Option D

4. Quick Check:

   Service mesh = communication management [OK]

Hint: Service mesh controls microservice communication, not data or logic [OK]

Common Mistakes:

• Confusing service mesh with data storage
• Thinking service mesh replaces microservices
• Assuming service mesh writes app code

2. Which of the following is a common tool used to implement a service mesh?

easy

A. Docker

B. Istio

C. Kubernetes

D. Git

Solution

1. Step 1: Recall popular service mesh tools

   Istio, Linkerd, and Consul are well-known service mesh tools.

2. Step 2: Differentiate from other tools

   Docker is for containers, Kubernetes for orchestration, Git for version control, not service mesh.

3. Final Answer:

   Istio -> Option B

4. Quick Check:

   Istio = service mesh tool [OK]

Hint: Istio is a popular service mesh tool, not Docker or Git [OK]

Common Mistakes:

• Choosing Docker or Kubernetes as service mesh
• Confusing version control tools with service mesh
• Mixing container tools with service mesh tools

3. Given a microservices setup with Istio service mesh, what happens when a service-to-service call fails due to network issues?

medium

A. Istio retries the call automatically based on configured policies

B. The call fails immediately without retries

C. Istio shuts down the service permanently

D. The service mesh ignores the failure and logs no information

Solution

1. Step 1: Understand Istio's retry feature

   Istio can automatically retry failed calls to improve reliability.

2. Step 2: Eliminate incorrect behaviors

   Istio does not shut down services or ignore failures silently; it logs and manages retries.

3. Final Answer:

   Istio retries the call automatically based on configured policies -> Option A

4. Quick Check:

   Istio retries failed calls = true [OK]

Hint: Istio retries failed calls automatically if configured [OK]

Common Mistakes:

• Assuming no retries happen on failure
• Thinking Istio shuts down services on failure
• Believing failures are ignored silently

4. You deployed a service mesh but notice that traffic between microservices is not encrypted. What is the most likely cause?

medium

A. The network cables are unplugged

B. The microservices are not running

C. Mutual TLS (mTLS) is not enabled in the service mesh configuration

D. The service mesh is not installed

Solution

1. Step 1: Check encryption settings in service mesh

   Service mesh uses mutual TLS (mTLS) to encrypt traffic between services.

2. Step 2: Identify why encryption might fail

   If mTLS is not enabled, traffic remains unencrypted despite service mesh presence.

3. Final Answer:

   Mutual TLS (mTLS) is not enabled in the service mesh configuration -> Option C

4. Quick Check:

   mTLS disabled = no encryption [OK]

Hint: Enable mTLS to encrypt service mesh traffic [OK]

Common Mistakes:

• Assuming services not running causes no encryption
• Thinking service mesh absence causes partial encryption
• Ignoring mTLS setting importance

5. You want to add observability to your microservices without changing their code. How does a service mesh help achieve this?

hard

A. By injecting sidecar proxies that monitor and report traffic metrics transparently

B. By rewriting the microservices code to add logging

C. By replacing microservices with a single monolithic app

D. By disabling network communication between services

Solution

1. Step 1: Understand sidecar proxy role in service mesh

   Service mesh injects sidecar proxies alongside microservices to handle communication and monitoring without code changes.

2. Step 2: Eliminate incorrect options

   Service mesh does not rewrite code, replace microservices, or disable communication.

3. Final Answer:

   By injecting sidecar proxies that monitor and report traffic metrics transparently -> Option A

4. Quick Check:

   Sidecar proxies add observability without code change [OK]

Hint: Sidecar proxies add monitoring without changing app code [OK]

Common Mistakes:

• Thinking code must be rewritten for observability
• Confusing service mesh with app replacement
• Assuming communication is disabled for observability