Service Mesh in Kubernetes: Istio u0026 Linkerd Basics Quiz Quiz

Explore essential concepts and features of service mesh in Kubernetes with this quiz focusing on Istio and Linkerd basics. Designed for users seeking to understand traffic management, observability, and security within Kubernetes service meshes.

1. Service Mesh Control Plane Functionality

   In a Kubernetes service mesh, what is a primary responsibility of the control plane, such as in Istio or Linkerd?

   1. Running containerized user workloads directly
   2. Storing application data in persistent volumes
   3. Monitoring host CPU and memory usage on worker nodes
   4. Managing and configuring network traffic policies for services

   Explanation: The control plane in a service mesh is chiefly responsible for managing and configuring traffic policies, such as routing, retries, and access control rules for services. The option about storing data refers to storage layers, not the service mesh. Monitoring node resources is typically handled by system monitoring tools, not the service mesh control plane. The control plane does not run application workloads directly; instead, it coordinates sidecars or proxies to enforce policies.

2. Sidecar Proxy Purpose

   Why are sidecar proxies commonly injected alongside application pods when using a service mesh in Kubernetes?

   1. To run backup and disaster recovery jobs for applications
   2. To store environment variables required by each pod
   3. To disable autoscaling based on resource metrics
   4. To dynamically handle service-to-service communication and traffic security

   Explanation: Sidecar proxies intercept and manage network traffic to and from each application pod, enabling features like secure communication and observability. Storing environment variables is handled by the system itself and not proxies. Running backups and disaster recovery jobs is not the function of a sidecar. Disabling autoscaling is neither related to nor managed by injected proxies.

3. Traffic Splitting Use Case

   Which scenario best demonstrates how traffic splitting is useful in a Kubernetes service mesh deployment?

   1. Automatically increasing storage space for a failing database pod
   2. Directly attaching persistent volumes to stateless services
   3. Increasing the replica count of a deployment during peak loads
   4. Gradually routing a small percentage of traffic to a new version of a service during a canary release

   Explanation: Traffic splitting allows gradual control over routing between service versions, which is highly beneficial for controlled releases and testing. Increasing storage space or attaching volumes is handled by storage plugins, not service mesh. Scaling up replicas is done by deployment controllers and does not use traffic splitting.

4. Security Enhancement by Service Mesh

   How does a service mesh improve security for service-to-service communication within a Kubernetes cluster?

   1. By encrypting configuration files on disk
   2. By updating operating system patches for worker nodes
   3. By automatically enforcing mutual Transport Layer Security (mTLS) between services
   4. By creating new admin users with elevated permissions

   Explanation: A service mesh can automatically enforce mTLS, encrypting service-to-service traffic and performing mutual authentication. Creating admin users does not enhance mesh security and can even be risky. Updating OS patches is a system administrator task. Encrypting configuration files is related to internal storage or system security, not communication between services.

5. Observability Features

   Which capability is provided by a service mesh to enhance observability in Kubernetes environments?

   1. Provisioning persistent object storage for all applications
   2. Collecting detailed traffic metrics and traces for service interactions
   3. Deploying GPU-accelerated workloads for advanced computation
   4. Granting direct internet access to all pods

   Explanation: Service meshes offer observability features such as collecting traffic metrics, latency data, and traces between services. Deploying specialized workloads, provisioning storage, or granting internet access are not observability functions. The distractors refer to different infrastructure concerns, not traffic monitoring or tracing.