Backend interview prep

Start

Pods Deployments Services Interview Questions (Top 100 Questions with Answers)

Master Kubernetes Pods, Deployments, and Services Interview Questions with production-ready explanations covering Pod lifecycle, ReplicaSets, rolling updates, rollbacks, Services, service discovery, ConfigMaps, Secrets, StatefulSets, DaemonSets, Jobs, health probes, scaling, troubleshooting, and enterprise deployment patterns.

Module Navigation

Previous: ECS vs EKS vs AKS vs GKE QA | Parent: Containers Learning Path | Next: Ingress QA

Introduction

Pods, Deployments, and Services are the core building blocks of Kubernetes application deployment.

A production Kubernetes application commonly uses:

  • Pods to run containers
  • ReplicaSets to maintain replicas
  • Deployments to manage application releases
  • Services to provide stable networking
  • ConfigMaps for configuration
  • Secrets for sensitive values
  • StatefulSets for stateful workloads
  • DaemonSets for node-level agents
  • Jobs and CronJobs for batch processing

Interviewers expect candidates to understand not only Kubernetes object definitions but also how these resources work together internally.

This guide contains the Top 100 Kubernetes Pods, Deployments, and Services Interview Questions with production-oriented explanations, troubleshooting scenarios, diagrams, YAML examples, common mistakes, and interview follow-ups.

Learning Roadmap

Containers
     │
     ▼
Pods
     │
     ▼
ReplicaSets
     │
     ▼
Deployments
     │
     ▼
Services
     │
     ▼
ConfigMaps and Secrets
     │
     ▼
StatefulSets and DaemonSets
     │
     ▼
Jobs and CronJobs
     │
     ▼
Production Deployment

Pods Fundamentals

1. What is a Kubernetes Pod?

A Pod is the smallest deployable unit in Kubernetes.

A Pod contains one or more containers that share:

  • Network namespace
  • IP address
  • Port space
  • Storage volumes
  • Pod lifecycle
Pod
 ├── Application Container
 └── Sidecar Container

2. Why does Kubernetes deploy Pods instead of individual containers?

Kubernetes uses Pods because some containers must run together and share networking, storage, and lifecycle.

Examples include:

  • Application container with logging sidecar
  • Application container with service-mesh proxy
  • Application container with configuration helper

3. Can a Pod contain multiple containers?

Yes.

However, multiple containers should be placed in one Pod only when they are tightly coupled and must share the same lifecycle.

4. What do containers inside the same Pod share?

Containers inside the same Pod share:

  • Pod IP address
  • Network namespace
  • Port namespace
  • Mounted volumes
  • Lifecycle boundary

They communicate through localhost.

5. Should unrelated applications run in the same Pod?

No.

Unrelated applications should normally run in separate Pods so they can be:

  • Scaled independently
  • Deployed independently
  • Restarted independently
  • Monitored independently

6. What is a Pod manifest?

A Pod manifest is a YAML or JSON document describing the desired Pod configuration.

apiVersion: v1
kind: Pod
metadata:
  name: payment-api
  labels:
    app: payment-api
spec:
  containers:
    - name: payment-api
      image: codewithvenu/payment-api:1.0.0
      ports:
        - containerPort: 8080

7. What are the major sections of a Pod manifest?

The major sections are:

  • apiVersion
  • kind
  • metadata
  • spec
  • status

Users define the desired state under spec.

Kubernetes reports the current state under status.

8. What is the Pod lifecycle?

A Pod can move through these phases:

  • Pending
  • Running
  • Succeeded
  • Failed
  • Unknown
Pending
   │
   ▼
Running
   │
   ├──► Succeeded
   └──► Failed

9. What does the Pending Pod phase mean?

Pending means Kubernetes accepted the Pod, but one or more containers are not yet running.

Possible causes include:

  • Waiting for scheduling
  • Image pull in progress
  • No matching node
  • Persistent volume not available
  • Insufficient CPU or memory

10. What does the Running Pod phase mean?

Running means:

  • The Pod is assigned to a node.
  • All required containers were created.
  • At least one container is running, starting, or restarting.

A Running Pod is not necessarily ready to receive traffic.

Pod Identity and Networking

11. Does every Pod receive an IP address?

Yes.

Every Pod normally receives a unique cluster IP address from the Container Network Interface plugin.

12. Is a Pod IP permanent?

No.

A recreated Pod may receive a different IP address.

Applications should use Kubernetes Services instead of connecting directly to Pod IPs.

13. How do containers inside one Pod communicate?

They communicate through localhost because they share the same network namespace.

Example:

Application Container → localhost:15000 → Sidecar Proxy

14. How do Pods communicate with other Pods?

Pods communicate using Pod IP addresses through the Kubernetes cluster network.

The CNI plugin implements the networking.

Examples include:

  • Calico
  • Cilium
  • Flannel
  • Azure CNI
  • AWS VPC CNI

15. Can two containers in the same Pod listen on the same port?

No.

They share the same network namespace, so both cannot bind to the same IP address and port combination.

16. What happens to the Pod IP when a Pod restarts?

If only a container restarts inside the existing Pod, the Pod IP normally remains the same.

If Kubernetes replaces the entire Pod, the replacement may receive a new IP.

17. Why should applications not store important data inside the container filesystem?

The container filesystem is ephemeral.

Data may be lost when:

  • Container restarts
  • Pod is replaced
  • Pod moves to another node
  • Deployment creates a new replica

Use persistent volumes or external storage for durable data.

18. What is an ephemeral volume?

An ephemeral volume exists for the lifetime of the Pod.

Example:

volumes:
  - name: temporary-data
    emptyDir: {}

All containers in the Pod can share it.

19. What is emptyDir?

emptyDir creates temporary storage when a Pod starts.

The data survives individual container restarts but is deleted when the Pod is removed.

20. What is a PersistentVolumeClaim?

A PersistentVolumeClaim, or PVC, is a request for persistent storage.

volumes:
  - name: application-data
    persistentVolumeClaim:
      claimName: payment-data-pvc

Pod Scheduling

21. How is a Pod assigned to a node?

The Kubernetes Scheduler:

  1. Finds unscheduled Pods.
  2. Filters nodes that cannot run the Pod.
  3. Scores suitable nodes.
  4. Selects the best node.
  5. Records the binding through the API Server.

22. Which factors affect Pod scheduling?

Common factors include:

  • CPU requests
  • Memory requests
  • Node selectors
  • Node affinity
  • Pod affinity
  • Pod anti-affinity
  • Taints and tolerations
  • Topology spread constraints
  • Storage requirements

23. What are resource requests?

Resource requests specify the minimum CPU and memory Kubernetes reserves for a container.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"

The Scheduler uses requests when selecting a node.

24. What are resource limits?

Resource limits define the maximum resources a container may consume.

resources:
  limits:
    cpu: "1"
    memory: "512Mi"

25. What happens when a container exceeds its CPU limit?

The container is throttled.

It is not normally terminated simply for exceeding CPU limits.

26. What happens when a container exceeds its memory limit?

The container may be terminated with an OOMKilled status.

27. What is a node selector?

A node selector places Pods on nodes with matching labels.

nodeSelector:
  workload: payments

28. What is node affinity?

Node affinity provides expressive rules for scheduling Pods onto particular nodes.

It supports:

  • Required rules
  • Preferred rules
  • Multiple matching expressions

29. What are taints and tolerations?

Taints prevent Pods from being scheduled onto nodes unless the Pods have matching tolerations.

Node Taint
    │
    ▼
Only Pods with matching Toleration

30. What is Pod anti-affinity?

Pod anti-affinity keeps selected Pods away from each other.

It is commonly used to distribute replicas across:

  • Nodes
  • Availability Zones
  • Failure domains

Pod Health and Probes

31. What is a liveness probe?

A liveness probe determines whether a container is still functioning.

If the probe repeatedly fails, Kubernetes restarts the container.

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

32. What is a readiness probe?

A readiness probe determines whether a Pod is ready to receive traffic.

When it fails, the Pod is removed from Service endpoints.

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080

33. What is a startup probe?

A startup probe determines whether a slow-starting application has completed initialization.

Until the startup probe succeeds, liveness and readiness probes are not evaluated normally.

34. Liveness probe vs readiness probe?

Liveness Probe Readiness Probe
Checks whether the container is alive Checks whether it can receive traffic
Failure restarts the container Failure removes the Pod from Service endpoints
Detects deadlocks or hangs Detects temporary unavailability

35. When should a startup probe be used?

Use it for applications with long startup times, such as:

  • Large Spring Boot applications
  • JVM services with heavy initialization
  • Applications loading large models
  • Legacy applications

36. What is the danger of a badly configured liveness probe?

An aggressive liveness probe can create restart loops.

Example:

Application starts slowly
        │
Probe fails too early
        │
Container restarts
        │
Application never becomes ready

37. Should readiness checks verify every external dependency?

Not always.

If readiness depends on every optional downstream service, one minor dependency failure can remove all application Pods from traffic.

Readiness should reflect whether the application can safely serve requests.

38. What is a graceful shutdown?

Graceful shutdown allows an application to:

  • Stop accepting new requests
  • Complete in-flight work
  • Close connections
  • Flush logs
  • Release resources

39. What is terminationGracePeriodSeconds?

It defines how long Kubernetes waits before forcefully terminating a Pod.

spec:
  terminationGracePeriodSeconds: 30

40. What is a preStop hook?

A preStop hook executes before Kubernetes terminates a container.

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 10"]

It can help with graceful traffic draining.

ReplicaSets

41. What is a ReplicaSet?

A ReplicaSet ensures that a specified number of identical Pod replicas are running.

42. Why are ReplicaSets used?

ReplicaSets provide:

  • Redundancy
  • Self-healing
  • Horizontal scaling
  • Replacement of failed Pods

43. Should developers create ReplicaSets directly?

Usually no.

Deployments create and manage ReplicaSets automatically.

44. How does a ReplicaSet identify its Pods?

It uses a label selector.

selector:
  matchLabels:
    app: payment-api

45. What happens when a ReplicaSet-managed Pod is deleted manually?

The ReplicaSet detects that the actual replica count is below the desired count and creates a replacement Pod.

46. What happens if a ReplicaSet has three replicas and one node fails?

Kubernetes eventually marks the Pod unavailable and creates a replacement Pod on another healthy node, assuming sufficient resources exist.

47. What is the desired state in a ReplicaSet?

The desired state is the number of replicas defined in the specification.

spec:
  replicas: 3

48. Can a ReplicaSet adopt existing Pods?

Yes, if unmanaged Pods match the ReplicaSet's selector and ownership conditions allow adoption.

This is one reason selectors must be designed carefully.

49. What happens if ReplicaSet labels and selectors do not match?

The resource may be rejected, fail to manage the expected Pods, or create unexpected behavior depending on the manifest.

The Pod template labels must match the selector.

50. ReplicaSet vs ReplicationController?

ReplicaSet is the modern replacement for ReplicationController.

ReplicaSet supports richer set-based label selectors.

Deployments

51. What is a Kubernetes Deployment?

A Deployment declaratively manages stateless application Pods through ReplicaSets.

It supports:

  • Scaling
  • Rolling updates
  • Rollbacks
  • Deployment history
  • Self-healing

52. What resources does a Deployment create?

A Deployment creates and manages:

  • ReplicaSets
  • Pods
Deployment
    │
    ▼
ReplicaSet
    │
    ▼
Pods

53. Show a basic Deployment manifest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
    spec:
      containers:
        - name: payment-api
          image: codewithvenu/payment-api:1.0.0
          ports:
            - containerPort: 8080

54. Why use a Deployment instead of creating Pods directly?

A standalone Pod is not automatically recreated after deletion or failure.

A Deployment provides:

  • Replica management
  • Self-healing
  • Version updates
  • Rollbacks
  • Scaling

55. What is a rolling update?

A rolling update gradually replaces old Pods with new Pods while keeping the application available.

Version 1 Pods
      │
      ▼
Create Version 2 Pod
      │
      ▼
Verify Readiness
      │
      ▼
Remove Version 1 Pod

56. What are Deployment strategies?

The primary built-in strategies are:

  • RollingUpdate
  • Recreate

57. What is the Recreate strategy?

The Recreate strategy terminates all old Pods before creating new Pods.

It causes downtime but may be required when two versions cannot run simultaneously.

58. What are maxSurge and maxUnavailable?

maxSurge controls how many extra Pods may be created during an update.

maxUnavailable controls how many desired Pods may be unavailable.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

59. How do you update a Deployment image?

kubectl set image deployment/payment-api \
  payment-api=codewithvenu/payment-api:2.0.0

Or update the YAML manifest and apply it.

60. How do you check Deployment rollout status?

kubectl rollout status deployment/payment-api

Deployment History and Rollbacks

61. How do you view Deployment history?

kubectl rollout history deployment/payment-api

62. How do you roll back a Deployment?

kubectl rollout undo deployment/payment-api

63. How do you roll back to a specific revision?

kubectl rollout undo deployment/payment-api --to-revision=2

64. What creates a new Deployment revision?

A change to the Pod template creates a new revision.

Examples:

  • Image update
  • Environment variable change
  • Resource configuration change
  • Probe change
  • Pod label change

Changing only the replica count does not normally create a new ReplicaSet revision.

65. What is revisionHistoryLimit?

It controls how many old ReplicaSets Kubernetes retains for rollback.

spec:
  revisionHistoryLimit: 5

66. What does kubectl rollout pause do?

It pauses a Deployment rollout so multiple changes can be made before resuming.

kubectl rollout pause deployment/payment-api

67. What does kubectl rollout resume do?

It continues a previously paused Deployment rollout.

kubectl rollout resume deployment/payment-api

68. What causes a Deployment rollout to become stuck?

Possible causes include:

  • Image pull failure
  • Failed readiness probe
  • Insufficient node resources
  • Invalid configuration
  • Missing Secret or ConfigMap
  • Scheduling restrictions
  • Container crash

69. What is progressDeadlineSeconds?

It specifies how long Kubernetes waits for Deployment progress before reporting a failed rollout condition.

spec:
  progressDeadlineSeconds: 600

70. How do you perform zero-downtime Deployment?

Use:

  • Multiple replicas
  • RollingUpdate strategy
  • Correct readiness probes
  • maxUnavailable: 0
  • Graceful shutdown
  • Connection draining
  • Sufficient cluster capacity

Kubernetes Services

71. What is a Kubernetes Service?

A Service provides a stable network endpoint for a dynamic group of Pods.

72. Why is a Service required?

Pod IP addresses are temporary.

A Service provides:

  • Stable virtual IP
  • Stable DNS name
  • Load balancing
  • Service discovery

73. How does a Service find its Pods?

Using label selectors.

selector:
  app: payment-api

74. Show a basic ClusterIP Service.

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

75. What are the Kubernetes Service types?

  • ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName

76. What is ClusterIP?

ClusterIP exposes a Service only inside the Kubernetes cluster.

It is the default Service type.

77. What is NodePort?

NodePort exposes a Service on a static port on every worker node.

Client
   │
NodeIP:NodePort
   │
Service
   │
Pods

78. What is LoadBalancer Service?

A LoadBalancer Service asks the cloud provider to provision an external load balancer.

It usually routes:

Cloud Load Balancer
        │
        ▼
Kubernetes Service
        │
        ▼
Pods

79. What is ExternalName Service?

ExternalName maps a Kubernetes Service name to an external DNS name.

apiVersion: v1
kind: Service
metadata:
  name: external-payment-provider
spec:
  type: ExternalName
  externalName: api.payment-provider.example

80. ClusterIP vs NodePort vs LoadBalancer?

ClusterIP NodePort LoadBalancer
Internal access Exposes port on every node Creates external cloud load balancer
Default type Basic external access Production cloud exposure
Cluster-only IP Node IP and static port External IP or hostname

Service Networking and Discovery

81. What is port in a Service?

port is the port exposed by the Service.

82. What is targetPort?

targetPort is the port on the target Pod container.

Service Port 80
      │
      ▼
Pod Target Port 8080

83. What is nodePort?

nodePort is the port exposed on each worker node for a NodePort or LoadBalancer Service.

84. What is Kubernetes service discovery?

Kubernetes DNS creates names for Services.

Example:

payment-api.default.svc.cluster.local

A Pod in the same namespace can normally call:

http://payment-api

85. What is CoreDNS?

CoreDNS is the standard Kubernetes DNS service responsible for cluster name resolution.

86. What are EndpointSlices?

EndpointSlices store scalable network endpoint information for Services.

They replace the older single Endpoints object for large environments.

87. What happens when a Pod fails its readiness probe?

The Pod is removed from the Service's ready endpoints.

The Service stops routing normal traffic to it.

88. Does a Service automatically create application-level health checks?

No.

Kubernetes uses Pod readiness and endpoint information.

External cloud load balancers may also perform their own health checks.

89. What is a headless Service?

A headless Service has:

clusterIP: None

It does not provide a virtual cluster IP.

DNS returns individual Pod addresses.

It is commonly used with StatefulSets.

90. Can a Service select Pods in another namespace?

A normal selector-based Service selects Pods only within its own namespace.

Cross-namespace communication uses the target Service's DNS name or specialized patterns.

Production Scenarios and Troubleshooting

91. A Service exists, but traffic does not reach the Pods. What should you check?

Check:

  1. Service selector
  2. Pod labels
  3. Service endpoints
  4. port and targetPort
  5. Pod readiness
  6. Network Policies
  7. Application listening address
  8. CNI health

Useful commands:

kubectl get service payment-api
kubectl get endpointslices
kubectl get pods --show-labels
kubectl describe service payment-api

92. A Pod is Running but not receiving traffic. Why?

Possible causes:

  • Readiness probe failing
  • Service selector mismatch
  • Application bound only to localhost
  • Incorrect target port
  • Network Policy blocking traffic
  • Pod not included in EndpointSlice

93. A Deployment shows ImagePullBackOff. What does it mean?

Kubernetes cannot pull the image successfully.

Possible causes:

  • Wrong image name
  • Missing image tag
  • Registry authentication failure
  • Network issue
  • Image does not exist
  • Rate limit exceeded

94. What is CrashLoopBackOff?

The container starts, crashes, and Kubernetes repeatedly restarts it with increasing delay.

Investigate:

kubectl logs pod-name --previous
kubectl describe pod pod-name

Common causes include:

  • Invalid configuration
  • Missing environment variable
  • Database connection failure
  • Wrong command
  • Application exception

95. Why might a Pod remain Pending?

Common reasons include:

  • Insufficient CPU or memory
  • Unbound PVC
  • Node selector mismatch
  • Untolerated taint
  • Pod affinity restrictions
  • Maximum Pod capacity reached
  • No suitable availability zone

96. How do you scale a Deployment manually?

kubectl scale deployment/payment-api --replicas=5

For automatic scaling, use a HorizontalPodAutoscaler.

97. How do you expose a Deployment as a Service?

kubectl expose deployment payment-api \
  --name=payment-api \
  --port=80 \
  --target-port=8080 \
  --type=ClusterIP

Production environments should usually manage the Service declaratively through YAML.

98. What are common production mistakes?

  • Creating standalone Pods instead of Deployments
  • Using the latest image tag
  • Missing readiness and liveness probes
  • Missing resource requests and limits
  • Service selector mismatch
  • Storing secrets directly in manifests
  • Running only one replica
  • Using NodePort unnecessarily
  • Ignoring graceful shutdown
  • Keeping mutable application state inside Pods

99. What should be monitored?

Monitor:

  • Desired vs available replicas
  • Pod restart count
  • Pod readiness
  • Deployment rollout status
  • Container CPU and memory
  • OOM kills
  • Pending Pods
  • Service endpoint count
  • Request latency
  • Error rate
  • Network failures

Use:

  • Deployments for stateless applications
  • Multiple Pod replicas
  • ClusterIP Services for internal communication
  • Ingress or Gateway API for HTTP exposure
  • Readiness, liveness, and startup probes
  • Resource requests and limits
  • Horizontal Pod Autoscaling
  • PodDisruptionBudgets
  • Topology spread constraints
  • ConfigMaps and external secret management
  • Centralized logs, metrics, and traces
  • GitOps or automated CI/CD
  • Rolling or progressive delivery
  • Network Policies
  • Persistent storage only where required

Complete Deployment and Service Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  labels:
    app: payment-api
spec:
  replicas: 3
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
        version: v1
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: payment-api
          image: codewithvenu/payment-api:1.0.0
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080

          env:
            - name: SPRING_PROFILES_ACTIVE
              value: production

          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"

          startupProbe:
            httpGet:
              path: /actuator/health/liveness
              port: http
            failureThreshold: 30
            periodSeconds: 10

          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: http
            initialDelaySeconds: 10
            periodSeconds: 10
            failureThreshold: 3

          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: http
            periodSeconds: 10
            failureThreshold: 3

          lifecycle:
            preStop:
              exec:
                command: ["sh", "-c", "sleep 10"]

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

Deployment Architecture

                  Deployment
                      │
                      ▼
                  ReplicaSet
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        Pod-1       Pod-2       Pod-3
          │           │           │
          └───────────┼───────────┘
                      ▼
                   Service
                      │
                      ▼
               Stable DNS Name

Rolling Update Flow

Current State

ReplicaSet v1
 ├── Pod v1
 ├── Pod v1
 └── Pod v1

        │
        ▼

Create ReplicaSet v2
        │
        ▼

Start Pod v2
        │
        ▼

Readiness Probe Passes
        │
        ▼

Remove One Pod v1
        │
        ▼

Repeat Until Complete
        │
        ▼

ReplicaSet v2
 ├── Pod v2
 ├── Pod v2
 └── Pod v2

Service Request Flow

Client Pod
    │
    ▼
Service DNS
payment-api
    │
    ▼
ClusterIP
    │
    ▼
EndpointSlice
    │
 ┌──┼───────────┐
 ▼  ▼           ▼
Pod-1          Pod-2

Pod Termination Flow

Pod Deletion Requested
          │
          ▼
Pod Marked Terminating
          │
          ▼
Removed from Service Endpoints
          │
          ▼
preStop Hook Runs
          │
          ▼
SIGTERM Sent
          │
          ▼
Application Completes Requests
          │
          ▼
Container Exits
          │
          ▼
SIGKILL After Grace Period

Pods vs ReplicaSets vs Deployments vs Services

Resource Primary Responsibility
Pod Runs one or more containers
ReplicaSet Maintains a desired number of Pods
Deployment Manages releases and ReplicaSets
Service Provides stable networking to Pods
ConfigMap Stores non-sensitive configuration
Secret Stores sensitive configuration
StatefulSet Manages stateful Pods with stable identity
DaemonSet Runs a Pod on selected nodes
Job Runs work to completion
CronJob Runs Jobs on a schedule

Quick Revision

Topic Key Point
Pod Smallest deployable Kubernetes unit
ReplicaSet Maintains Pod replicas
Deployment Manages stateless application releases
RollingUpdate Gradually replaces Pods
Recreate Removes old Pods before creating new Pods
Service Stable endpoint for dynamic Pods
ClusterIP Internal Service
NodePort Exposes a port on every node
LoadBalancer Provisions an external load balancer
Headless Service Returns individual Pod addresses
Readiness Probe Controls traffic eligibility
Liveness Probe Controls container restart
Startup Probe Protects slow-starting applications
EndpointSlice Stores scalable Service endpoint data
CoreDNS Provides Kubernetes DNS resolution

Interview Tips

During Kubernetes Pods, Deployments, and Services interviews:

  • Clearly explain why Kubernetes deploys Pods rather than standalone containers.
  • Describe the relationship between Deployment → ReplicaSet → Pods.
  • Explain how Services provide stable access to Pods with changing IP addresses.
  • Know the differences between ClusterIP, NodePort, LoadBalancer, and ExternalName.
  • Explain liveness, readiness, and startup probes using production examples.
  • Understand rolling updates, rollbacks, maxSurge, maxUnavailable, and revision history.
  • Be prepared to troubleshoot Pending, CrashLoopBackOff, ImagePullBackOff, and Service selector issues.
  • Mention resource requests, limits, graceful shutdown, autoscaling, high availability, observability, and security in senior-level answers.
  • Use declarative YAML, versioned images, automated CI/CD, and GitOps for production deployments.

Summary

Pods run application containers, ReplicaSets maintain availability, Deployments manage releases, and Services provide stable networking. Together, they form the foundation of Kubernetes application delivery.

Strong interview performance requires understanding:

  • Pod lifecycle and networking
  • Scheduling and resource management
  • Health probes
  • ReplicaSets
  • Deployment strategies
  • Rolling updates and rollbacks
  • Service types
  • Service discovery
  • EndpointSlices
  • Production troubleshooting
  • High availability and graceful shutdown

Mastering these 100 Kubernetes Pods, Deployments, and Services interview questions prepares you for Kubernetes, OpenShift, Amazon EKS, Azure AKS, Google GKE, DevOps Engineer, Platform Engineer, Cloud Engineer, Site Reliability Engineer, Technical Lead, and Solution Architect interviews.