Istio overview in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary role of Istio in Kubernetes?

Istio is often used with Kubernetes clusters. What is its main purpose?

A To manage and secure service-to-service communication within the cluster

B To replace Kubernetes as the container orchestrator

C To provide persistent storage for Kubernetes pods

D To monitor CPU and memory usage of nodes only

💡 Hint

Think about what happens when many microservices need to talk securely and reliably.

Istio acts as a service mesh that manages communication between microservices, adding security, observability, and traffic control.

💻 Command Output

intermediate

What does this Istio command output?

Run the command istioctl version in a terminal connected to a Kubernetes cluster with Istio installed. What output do you expect?

Kubernetes

istioctl version

A Error: command not found

B Pod istio-ingressgateway not found

C No resources found in default namespace

D

Client version: 1.17.1
Control plane version: 1.17.1
Data plane version: 1.17.1 (5 proxies)

💡 Hint

This command shows versions of Istio components installed.

The istioctl version command outputs the client, control plane, and data plane versions of Istio installed in the cluster.

❓ Configuration

advanced

Which Istio configuration snippet correctly enables mutual TLS for all services?

Choose the correct YAML snippet to enable mutual TLS (mTLS) for all services in the default namespace.

A

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: default
  namespace: default
spec:
  action: ALLOW

B

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: default
  namespace: default
spec:
  trafficPolicy:
    tls:
      mode: DISABLE

C

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

D

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: default-gateway
  namespace: default
spec:
  selector:
    istio: ingressgateway

💡 Hint

mTLS is configured using PeerAuthentication resource with mode STRICT.

PeerAuthentication with mtls.mode: STRICT enforces mutual TLS for all workloads in the namespace.

❓ Troubleshoot

advanced

Why might Istio sidecar proxies not inject into new pods?

You deployed Istio with automatic sidecar injection enabled, but new pods in the namespace do not have the Istio proxy container. What could cause this?

A The namespace label <code>istio-injection=enabled</code> is missing

B The pod spec uses hostNetwork: false

C The Kubernetes API server is down

D The pod has resource limits set

💡 Hint

Istio uses namespace labels to decide where to inject sidecars automatically.

Automatic sidecar injection requires the namespace to be labeled with istio-injection=enabled. Without it, pods won't get the sidecar.

🔀 Workflow

expert

Order the steps to deploy a new version of a microservice using Istio traffic shifting

Put these steps in the correct order to safely deploy a new version of a microservice using Istio's traffic shifting feature.

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 1,2,4,3

💡 Hint

Think about deploying first, then routing traffic, then monitoring, then increasing traffic.

First deploy the new version separately, then configure traffic routing to it, monitor its behavior, and finally shift all traffic once stable.