Services

Services Quiz

Quiz

Question 1 of 36 (0 answered)

Question 1

Why do we need Services in Kubernetes instead of connecting directly to pod IPs?

Pods have static IPs that never change Pods are ephemeral and their IPs change when recreated; Services provide stable endpoints Services are faster than direct pod communication Direct pod IP communication is not supported in Kubernetes

✓

Correct!

Pods are ephemeral and can be created/destroyed dynamically. Each pod gets a unique IP that changes when the pod is replaced. Services provide a stable IP address and DNS name that persists regardless of pod lifecycle changes.

✗

Incorrect

Think about what happens when a pod crashes and is recreated.

Question 2

Explain how Endpoints work in the context of Service traffic routing. Are they queried during active traffic?

Background Synchronization (NOT queried during traffic):

Endpoints work as a background synchronization mechanism:

Setup Phase: Endpoints Controller watches pods matching Service selector → Updates Endpoints object → kube-proxy watches Endpoints → Programs iptables/IPVS rules
Active Traffic: Request hits Service IP → Kernel networking stack → Pre-programmed iptables/IPVS rules → Direct routing to Pod IP

Key Point: Endpoints are NOT queried during active traffic. They update iptables/IPVS rules asynchronously in the background.

Benefits:

Kernel-level routing (no API calls)
No control plane bottleneck
Nanosecond routing decisions
Traffic continues even if API server is slow

Did you get it right?

✓

Correct!

✗

Incorrect

Question 3

What does a Kubernetes Service provide?

Stable IP address that persists across pod restarts DNS name for service discovery Load balancing across pod replicas Automatic pod health monitoring Abstraction of pod lifecycle dynamics

✓

Correct!

Services provide stable IP addresses, DNS names, load balancing across pods, and abstract the dynamic pod lifecycle. While Services route to healthy pods, the actual health monitoring is done by probes in the pod spec, not by the Service itself.

✗

Incorrect

Think about what Services directly manage vs. what they depend on.

Question 4

When traffic reaches a Service IP, the Endpoints object is queried in real-time to determine which pod to route to.

True False

✓

Correct!

False! Endpoints are NOT queried during active traffic. Instead, kube-proxy watches Endpoints objects in the background and pre-programs iptables/IPVS rules. When traffic hits the Service IP, the kernel networking stack uses these pre-programmed rules for direct, fast routing to pods.

✗

Incorrect

Think about performance - would querying an API object for every request be fast?

Question 5

What is the default Service type in Kubernetes?

NodePort LoadBalancer ClusterIP Headless

✓

Correct!

ClusterIP is the default Service type. It provides an internal cluster IP address accessible only within the cluster, making it ideal for internal service-to-service communication.

✗

Incorrect

ClusterIP is the default Service type. It provides an internal cluster IP address accessible only within the cluster, making it ideal for internal service-to-service communication.

Think about the most common use case - internal microservices communication.

Question 6

Given this Service configuration, how can you access it from outside the cluster?

apiVersion: v1
kind: Service
metadata:
  name: backend-api
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

What will this code output?

curl http://<node-ip>:80 curl http://backend-api (from any external client) Not directly accessible; use kubectl port-forward curl http://<cluster-ip>:80 from your laptop

✓

Correct!

ClusterIP Services are only accessible within the cluster. From outside, you must use kubectl port-forward svc/backend-api 8080:80 to create a local tunnel, then access via localhost:8080.

✗

Incorrect

ClusterIP Services are only accessible within the cluster. From outside, you must use kubectl port-forward svc/backend-api 8080:80 to create a local tunnel, then access via localhost:8080.

ClusterIP means cluster-internal only.

Question 7

What is the full DNS format for accessing a Kubernetes Service? (Use angle brackets for variables, e.g., )

✓

Correct!

The full DNS format for Services is <service-name>.<namespace>.svc.cluster.local. The svc component identifies it as a Service resource. Example: api.default.svc.cluster.local.

✗

Incorrect

The full DNS format for Services is <service-name>.<namespace>.svc.cluster.local. The svc component identifies it as a Service resource. Example: api.default.svc.cluster.local.

It includes the service name, namespace, resource type abbreviation, and cluster domain.

Question 8

Arrange the ClusterIP traffic flow in the correct order:

Sequence from client request to pod response

⋮⋮ Client inside cluster makes request

⋮⋮ Client sends packet to ClusterIP

⋮⋮ CoreDNS resolves Service name to ClusterIP

⋮⋮ iptables/IPVS rules route traffic (DNAT: ClusterIP → Pod IP)

⋮⋮ Packet arrives at Pod

⋮⋮ Pod processes request and responds

✓

Correct!

Traffic flow: Client request → DNS resolution → Packet to ClusterIP → Kernel routing via iptables/IPVS → Pod. Note that kube-proxy pre-programs the routing rules but doesn’t handle actual traffic.

✗

Incorrect

Question 9

What is the default port range for NodePort services?

1024-65535 30000-32767 8000-9000 80-443

✓

Correct!

NodePort services use ports in the range 30000-32767 by default. You can specify a port in this range or let Kubernetes auto-assign one. This range is configurable but 30000-32767 is the standard default.

✗

Incorrect

It’s a high port range above the well-known ports.

Question 10

Complete the NodePort Service to expose port 80 on node port 30080:

Fill in the missing Service type

apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  type: _____
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080

Your answer:

✓

Correct!

The NodePort type exposes the Service on each node’s IP at a static port (30080 in this case), allowing external access via any node’s IP address.

✗

Incorrect

The NodePort type exposes the Service on each node’s IP at a static port (30080 in this case), allowing external access via any node’s IP address.

Question 11

Why is NodePort NOT recommended for production external access?

NodePort requires manual tracking of port allocations (30000-32767) Nodes can be replaced, making it difficult for clients to track which Node IP to use NodePort services don’t support load balancing LoadBalancer (L4) or Ingress (L7) are better alternatives for production NodePort services are slower than other types

✓

Correct!

NodePort has port management challenges, node ephemerality issues, and better alternatives exist (LoadBalancer, Ingress). NodePort DOES support load balancing across pods and isn’t inherently slower - the issues are operational.

✗

Incorrect

Think about operational challenges and better architectural patterns.

Question 12

Explain the traffic flow for a LoadBalancer Service from external client to pod.

LoadBalancer Traffic Flow:

Client (external)
  ↓
Cloud Load Balancer (AWS ELB, GCP LB, Azure LB)
  ↓
Node IP:NodePort (LB distributes across nodes)
  ↓
iptables/IPVS rules (programmed by kube-proxy)
  ↓
DNAT: NodePort → Pod IP (e.g., 10.244.1.5:8080)
  ↓
Pod

Key Points:

LoadBalancer type automatically creates a NodePort
Cloud provider’s LB uses NodePorts as backend targets
kube-proxy programs iptables/IPVS rules
ClusterIP is also created but data plane traffic flows directly from NodePort to Pod via DNAT
Only works with cloud providers (AWS, GCP, Azure)

Did you get it right?

✓

Correct!

✗

Incorrect

Question 13

A LoadBalancer Service can only be created in cloud environments (AWS, GCP, Azure) and will not work in on-premises clusters.

True False

✓

Correct!

True! LoadBalancer Services require cloud provider integration to provision external load balancers (AWS ELB, GCP LB, Azure LB). In on-premises clusters, the Service will remain in ‘Pending’ state unless you have a solution like MetalLB to provide LoadBalancer functionality.

✗

Incorrect

Think about who provides the external load balancer.

Question 14

What makes a Headless Service different from a regular ClusterIP Service?

Headless Services have no pods Headless Services set clusterIP: None and return Pod IPs directly instead of a single ClusterIP Headless Services only work with Deployments Headless Services provide better load balancing

✓

Correct!

Headless Services have clusterIP: None, which means no ClusterIP is allocated. DNS queries return individual Pod IPs instead of a single Service IP, allowing direct pod-to-pod connectivity without kube-proxy load balancing.

✗

Incorrect

Think about what ‘headless’ means - no head/single IP.

Question 15

A Headless Service named ‘mysql’ is created with 3 StatefulSet pods (mysql-0, mysql-1, mysql-2). What DNS records are created?

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None
  selector:
    app: mysql
  ports:
  - port: 3306

What will this code output?

Only mysql.default.svc.cluster.local → ClusterIP mysql.default.svc.cluster.local → All pod IPs, plus individual records like mysql-0.mysql.default.svc.cluster.local No DNS records are created for Headless Services mysql-0, mysql-1, mysql-2 DNS records only (no Service DNS)

✓

Correct!

Headless Services create DNS records that return all pod IPs for the service name, plus individual DNS records for each pod: mysql-0.mysql.default.svc.cluster.local, mysql-1.mysql.default.svc.cluster.local, etc. This enables both direct pod access and load balancing.

✗

Incorrect

Headless Services provide BOTH collective and individual pod DNS records.

Question 16

An ExternalName Service type returns a _____ DNS record instead of creating a ClusterIP or proxying traffic.

✓

Correct!

ExternalName Services return a CNAME (Canonical Name) record that points to an external DNS name. This provides DNS aliasing without any proxying - traffic goes directly to the external service.

✗

Incorrect

ExternalName Services return a CNAME (Canonical Name) record that points to an external DNS name. This provides DNS aliasing without any proxying - traffic goes directly to the external service.

It’s a DNS record type that aliases one domain to another.

Question 17

Which Kubernetes components are involved in routing traffic for an ExternalName Service?

CoreDNS, kube-proxy, iptables/IPVS Only CoreDNS (returns CNAME, no proxying) kube-proxy and Endpoints Service Controller and kube-proxy

✓

Correct!

ExternalName Services only involve CoreDNS for DNS resolution. There’s no ClusterIP, no kube-proxy involvement, no iptables/IPVS rules, and no Endpoints. It’s purely a DNS alias that returns a CNAME record pointing to an external service.

✗

Incorrect

ExternalName is DNS-only, no Kubernetes networking components.

Question 18

Compare the five Service types: ClusterIP, NodePort, LoadBalancer, Headless, and ExternalName. When would you use each?

ClusterIP (default):

Internal cluster communication only
Use for: Microservices, internal APIs, backends
Access: Within cluster via DNS or ClusterIP

NodePort:

Exposes Service on each node’s IP at a static port (30000-32767)
Use for: Development/testing, direct node access
Access: External via <NodeIP>:<NodePort>
Production: ❌ Use LoadBalancer or Ingress instead

LoadBalancer:

Creates external cloud load balancer
Use for: Production external access (cloud only)
Access: External via cloud LB IP

Headless (clusterIP: None):

Returns pod IPs directly, no load balancing
Use for: StatefulSets, direct pod access, custom load balancing
Access: DNS returns individual pod IPs

ExternalName:

DNS alias (CNAME) to external service
Use for: Accessing external databases/APIs, migration scenarios
Access: Returns CNAME, no proxying

Did you get it right?

✓

Correct!

✗

Incorrect

Question 19

When you create a Service with a selector, Kubernetes automatically creates a corresponding Endpoints object.

True False

✓

Correct!

True! When a Service has a selector, the Endpoints Controller automatically creates and maintains an Endpoints object with the same name, populated with IPs and ports of pods matching the selector. This happens automatically in the background.

✗

Incorrect

Services with selectors are ‘selector-based’ and get automatic endpoint management.

Question 20

What are the benefits of EndpointSlices over the older Endpoints objects?

EndpointSlices split large endpoint lists into smaller chunks EndpointSlices provide more efficient watch updates EndpointSlices improve scalability for services with thousands of pods EndpointSlices are faster at routing traffic EndpointSlices reduce control plane load

✓

Correct!

EndpointSlices improve scalability by splitting large endpoint lists into chunks (typically 100 endpoints each), enabling more efficient updates and reducing control plane load. They don’t directly affect traffic routing speed - that’s handled by pre-programmed iptables/IPVS rules.

✗

Incorrect

Focus on scalability and control plane efficiency, not data plane performance.

Question 21

What happens when you create a Service without a selector?

apiVersion: v1
kind: Service
metadata:
  name: external-database
spec:
  ports:
  - port: 3306
    targetPort: 3306

What will this code output?

The Service fails to create Kubernetes automatically finds all pods in the namespace No Endpoints object is created automatically; you must manually create it The Service uses all pods in the cluster

✓

Correct!

Services without selectors don’t get automatic Endpoints management. You must manually create an Endpoints object with the same name to specify which IPs to route to. This is useful for routing to external services or manually managed endpoints.

✗

Incorrect

No selector = no automatic pod discovery.

Question 22

What does sessionAffinity: ClientIP do in a Service?

Routes all traffic to the pod with the matching IP Ensures requests from the same client IP go to the same pod Balances traffic based on client IP hash Blocks traffic from unknown client IPs

✓

Correct!

sessionAffinity: ClientIP ensures that requests from the same client IP address are consistently routed to the same pod. This creates session stickiness based on the client’s source IP, useful for stateful connections or in-memory caching.

✗

Incorrect

Think about maintaining session state across requests.

Question 23

Complete the Service configuration to enable session affinity with a 3-hour timeout:

Fill in the sessionAffinity value and timeout

apiVersion: v1
kind: Service
metadata:
  name: stateful-app
spec:
  sessionAffinity: _____
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: _____
  selector:
    app: stateful-app
  ports:
  - port: 80

Your answer:

✓

Correct!

Set sessionAffinity: ClientIP and timeoutSeconds: 10800 (3 hours = 10800 seconds). This ensures requests from the same client IP go to the same pod for 3 hours.

✗

Incorrect

Set sessionAffinity: ClientIP and timeoutSeconds: 10800 (3 hours = 10800 seconds). This ensures requests from the same client IP go to the same pod for 3 hours.

Question 24

With sessionAffinity: None (default), how does traffic distribution work?

All traffic goes to the first pod Random selection (iptables mode) or round-robin (IPVS mode) Weighted distribution based on pod resources Least connections algorithm

✓

Correct!

With sessionAffinity: None, traffic distribution depends on kube-proxy mode: iptables (default) uses random selection, while IPVS mode uses round-robin by default. No session stickiness is maintained.

✗

Incorrect

The behavior differs based on kube-proxy’s networking mode.

Question 25

Explain externalTrafficPolicy: Local vs Cluster. What are the tradeoffs?

externalTrafficPolicy: Cluster (default):

External traffic can land on any node (even if no matching pods)
Kubernetes then routes to any matching pod in the cluster
Traffic is distributed across all matching Pods cluster-wide
❌ Source IP is lost (SNAT applied)
❌ Extra network hop possible (traffic may cross nodes)
✅ Better load distribution

externalTrafficPolicy: Local:

External traffic is sent only to nodes with matching Pods
Traffic stays on the receiving node (no cross-node routing)
✅ Source IP preserved (no SNAT)
✅ No extra network hops
❌ Uneven distribution if pods spread unevenly across nodes

Use Cases:

Local: When you need source IP (logging, security) or want to avoid cross-node traffic
Cluster: When even distribution is more important than preserving source IP

Note: With LoadBalancer + Local, health checks ensure only nodes with pods receive traffic.

Did you get it right?

✓

Correct!

✗

Incorrect

Question 26

When using externalTrafficPolicy: Local with a LoadBalancer Service, the cloud load balancer’s health checks automatically exclude nodes that don’t have any matching pods.

True False

✓

Correct!

True! With externalTrafficPolicy: Local, Kubernetes configures health checks so that nodes without local pods are marked as unhealthy, causing the cloud load balancer to exclude them from the backend pool. This ensures traffic only goes to nodes with running pods.

✗

Incorrect

Health checks are key to making Local policy work effectively.

Question 27

Which fields are used in the Service port configuration section?

port - The Service’s exposed port targetPort - The port on the Pod that traffic is forwarded to nodePort - The node’s static port (for NodePort/LoadBalancer) containerPort - The container’s listening port protocol - TCP, UDP, or SCTP

✓

Correct!

Service port configuration uses: port (Service’s exposed port), targetPort (port on the Pod that traffic is forwarded to), nodePort (node’s static port for NodePort/LoadBalancer types), and protocol (TCP/UDP/SCTP). Traffic flow: Client → Service’s port → Service forwards to Pod’s targetPort → Container Key distinction: containerPort is defined in the pod spec (where container listens), while targetPort in the Service spec points to that container port.

✗

Incorrect

containerPort is a pod-level configuration, not Service-level.

Question 28

Given this Service configuration, what happens when a client inside the cluster accesses it using just the Service name ‘api’?

apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: production
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: api-server

What will this code output?

It works if the client is in the 'production' namespace; fails otherwise It fails because the full FQDN must be used It works from any namespace in the cluster It only works from the 'default' namespace

✓

Correct!

Short DNS names (just the service name) only work within the same namespace. To access across namespaces, use api.production or the full FQDN api.production.svc.cluster.local. This is Kubernetes’ DNS search domain behavior.

✗

Incorrect

DNS shortcuts are namespace-scoped.

Question 29

Order these Service types from most restrictive (internal only) to most open (external access):

Drag to arrange from most restricted to most accessible

⋮⋮ ExternalName

⋮⋮ ClusterIP

⋮⋮ NodePort

⋮⋮ LoadBalancer

✓

Correct!

ClusterIP is most restrictive (cluster-internal only), then NodePort (exposes on all nodes for external access), then LoadBalancer (external cloud load balancer for production). ExternalName is special (DNS alias to external service, no proxying).

✗

Incorrect

Question 30

What kubectl command allows you to access a ClusterIP Service from your local machine?

kubectl expose svc/my-service kubectl proxy svc/my-service kubectl port-forward svc/my-service 8080:80 kubectl tunnel svc/my-service

✓

Correct!

kubectl port-forward svc/my-service 8080:80 creates a tunnel from your local machine’s port 8080 to the Service’s port 80. You can then access it via localhost:8080. This is useful for debugging ClusterIP Services without exposing them externally.

✗

Incorrect

Think about creating a local tunnel to the cluster.

Question 31

The Kubernetes component responsible for resolving Service DNS names to IP addresses is _____.

✓

Correct!

CoreDNS is the DNS server running in Kubernetes clusters that resolves Service names to their ClusterIP addresses. It intercepts DNS queries from pods and returns the appropriate Service IPs or records.

✗

Incorrect

It’s the DNS component that replaced kube-dns.

Question 32

kube-proxy directly handles all network traffic flowing through Services by acting as a proxy layer between clients and pods.

True False

✓

Correct!

False! kube-proxy does NOT handle data plane traffic. It watches Service and EndpointSlice objects and programs iptables/IPVS rules on each node. The actual traffic routing happens at the kernel level using these rules, making it very fast without kube-proxy involvement in the data path.

✗

Incorrect

The name ‘proxy’ is misleading - think about what kube-proxy actually does.

Question 33

When a pod is deleted, how quickly does the Service stop routing traffic to it?

Immediately when the delete command is issued Within 1-2 seconds after Endpoints Controller updates and kube-proxy programs new rules After the pod’s terminationGracePeriodSeconds expires After the Service’s sessionAffinity timeout

✓

Correct!

When a pod is deleted, the Endpoints Controller detects the termination, updates the Endpoints object, kube-proxy receives the update and removes iptables/IPVS rules for that pod. This typically happens within 1-2 seconds, after which traffic stops going to the deleted pod.

✗

Incorrect

Think about the asynchronous background update process.

Question 34

Explain the complete lifecycle of how a new pod becomes part of Service traffic routing.

Pod to Service Traffic Lifecycle:

Pod Created: Pod scheduled with labels matching Service selector
Networking Setup: kubelet/CNI assigns Pod IP
Containers Start: Containers start, Pod is NotReady
Pod Becomes Ready: Readiness probe succeeds (Ready=True)
Endpoints Controller Detection: Controller detects Ready pod matching selector
Endpoints Update: EndpointSlices updated with Pod IP:port
kube-proxy Watch: kube-proxy receives Endpoint updates
Rules Programming: kube-proxy programs iptables/IPVS rules
Traffic Inclusion: Traffic now routes to the new pod (typically within 1-2 seconds)

Reverse for deletion: Pod Deleted → Endpoints Controller removes IP → Endpoints updated → kube-proxy removes rules → Traffic stops

Key Points:

Pods must be Ready before being added to Endpoints
Asynchronous background synchronization
Active traffic uses pre-programmed kernel rules, not real-time API queries

Did you get it right?

✓

Correct!

✗

Incorrect

Question 35

Which statements about Service selectors are TRUE?

Selectors use labels to identify which pods the Service routes to Selectors must match the labels in the pod’s metadata.labels field Services can have multiple selectors with OR logic Changing a Service selector immediately updates routing Services without selectors require manual Endpoints management

✓

Correct!

Service selectors use label matching (must match pod labels), updates take effect quickly, and services without selectors need manual Endpoints. However, Service selectors use AND logic for multiple labels, not OR.

✗

Incorrect

Multiple labels in a selector all must match (AND logic).

Question 36

What happens when you try to create a LoadBalancer Service in an on-premises cluster without cloud provider integration?

kubectl apply -f loadbalancer-service.yaml
kubectl get svc my-service

What will this code output?

The Service is rejected and fails to create The Service is created but EXTERNAL-IP shows <pending> indefinitely Kubernetes automatically falls back to NodePort type The Service creates a ClusterIP only

✓

Correct!

Without cloud provider integration, LoadBalancer Services are created successfully but the EXTERNAL-IP field shows <pending> indefinitely since there’s no controller to provision an external load balancer. The Service still works as a NodePort internally.

✗

Incorrect

Kubernetes creates the resource, but can’t fulfill the LoadBalancer provisioning.

Quiz Results

Score

0/0

Accuracy

Right

Wrong

Skipped

Last updated on March 15, 2026

Workload Controllers Ingress