yoklainterview sim
ProgressHistory

DevOps / Cloud K8s Services Networking Interview Questions

75 verified DevOps / Cloud K8s Services Networking interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

K8s Services NetworkingDifficulty 1
How does a Kubernetes Service decide which Pods belong to it?
  • aIt matches Pods that were created by the same Deployment name
  • bIt matches Pods running on the same Node as the Service
  • cIt matches Pods whose labels satisfy its label selector✓
  • dIt matches Pods listed by name in the Service's manifest
Explanation:A Service's spec.selector is a label selector: any Pod carrying labels that match it is included as a backend, regardless of which controller created it or which Node it runs on.
K8s Services NetworkingDifficulty 1
A Deployment's rolling update replaces all Pods with new ones (new names, new IPs). What happens to clients connecting to the Service in front of them?
  • aClients get connection errors until they manually refresh the Service's ClusterIP
  • bClients keep using the same stable Service ClusterIP/DNS name✓
  • cThe Service is automatically recreated with a new ClusterIP after every rollout
  • dClients must switch to the new Pods' individual IP addresses
Explanation:The Service's ClusterIP and DNS name stay fixed for the Service's lifetime. As old Pods are replaced, the Service's endpoint list is updated to point at the new Pods, so clients never need to know individual Pod IPs.
K8s Services NetworkingDifficulty 2
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

After applying this alongside a Deployment whose Pods carry the label app: web, kubectl get endpoints web-svc is run. What does it show?
  • aThe Pod IP:port pairs of every ready Pod matching app: web✓
  • bThe single ClusterIP assigned to web-svc
  • cThe Deployment name and its current replica count
  • dAn empty list until a NodePort or LoadBalancer is also created
Explanation:The Endpoints object (and its EndpointSlice equivalent) is populated by the endpoint controller with the IP:port of each Pod that matches the Service's selector and is currently ready — this was confirmed live: kubectl get endpoints web-svc returned 10.244.0.6:80,10.244.0.7:80,10.244.0.8:80 for three ready Pods.
K8s Services NetworkingDifficulty 2
A Deployment has 3 replicas behind a Service. One Pod's readiness probe starts failing, but the container keeps running (it is not restarted). What do kubectl get pods and the Service's endpoint list show?
  • aThe Pod disappears from kubectl get pods, and the Service routes to only 2 Pods
  • bThe Pod restarts automatically, and the Service keeps routing to all 3 Pods
  • cThe Pod shows as Running with a new IP, and the Service adds a 4th endpoint
  • dThe Pod still shows Running (0/1 ready), but is dropped from the endpoint list✓
Explanation:This was reproduced live: a Pod whose readiness probe failed stayed Running in kubectl get pods (ready count dropped to 0/1), while kubectl get endpoints web-svc shrank from 3 addresses to 2 — the container isn't restarted by a failing readiness probe, but the Service stops sending it traffic.
K8s Services NetworkingDifficulty 2
A Service's selector is app: web, but someone patches it to app: nonexistent while the backing Pods still carry app: web. What happens to the Service?
  • aThe Service is automatically deleted since it has no valid backends
  • bThe Service keeps its ClusterIP, but its endpoint list becomes empty✓
  • cThe Service falls back to matching all Pods in the namespace
  • dThe Service keeps its old endpoints until the Pods are restarted
Explanation:This was reproduced live: patching web-svc's selector to a label no Pod has produced kubectl get endpoints web-svc showing no addresses and kubectl describe svc showing an empty Endpoints: line — the Service object itself and its ClusterIP are untouched, only the endpoint list is recalculated.
K8s Services NetworkingDifficulty 1
By default (without specifying type), what kind of Service does Kubernetes create?
  • aClusterIP — reachable only from inside the cluster✓
  • bNodePort — reachable on every Node's IP at a fixed port
  • cLoadBalancer — provisions an external cloud load balancer
  • dExternalName — a DNS alias to an external hostname
Explanation:ClusterIP is the default Service type: it gets a stable virtual IP routable only within the cluster's network, which is exactly what most in-cluster service-to-service traffic needs.

By specialization

AWS 450Azure 450GCP 450Kubernetes 450Linux 450Terraform 450

By seniority

DevOps / Cloud JuniorDevOps / Cloud MidDevOps / Cloud Senior

Other fields

BackendFrontendFullstackAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview