Kubernetes for SDET Test Infrastructure Interview Questions 2026 — K8s Architecture Fundamentals for QA Engineers (Pods, Deployments, Services, Ingress, Persistent Volumes), Deploying Selenium Grid on Kubernetes with Production-Grade Helm Charts, Running Playwright at Scale on K8s Clusters (Job Patterns, Sidecar Containers, Parallel Execution Strategies), CI/CD Integration with Argo CD and GitOps for Test Infrastructure, Monitoring Test Pods with Prometheus, Grafana, and Loki, Infrastructure as Code for QA Environments, and the Kubernetes Interview Questions Senior SDET Panels Ask in 2026

You've containerised your test suite. You've got Selenium Grid humming in Docker Compose, Playwright tests running in CI with browser images, and a neat little docker-compose.yml that everyone on the team copies. Life is good. Then your engineering director announces the Q3 goal: "We're scaling to 500 parallel end-to-end tests across three environments, running on every PR." Your Docker Compose setup hits a wall — it was never designed for multi-node orchestration, self-healing, or dynamic scaling. You need Kubernetes. But here is the trap most SDETs fall into: they learn enough K8s to run kubectl apply -f pod.yaml and call it a day. Then the interview panel asks: "Walk me through your Selenium Grid deployment on Kubernetes. How do you handle hub failover? How do you manage browser version upgrades without downtime? What does your Argo CD Application manifest look like? What Prometheus metrics are you scraping from your test pods, and what thresholds trigger alerts?" These are not trivia questions — they reveal whether you understand K8s as an operational platform or just as "Docker with more YAML."

In 2026, Kubernetes has crossed the chasm from "nice-to-have for platform teams" to "baseline expectation for test infrastructure at any company running more than 50 parallel browser tests." This guide covers every K8s topic senior SDET interview panels drill into — from the architecture fundamentals (Pods, Deployments, Services, Ingress) through to production deployment patterns (Helm, Argo CD, Prometheus). Pair this with our deep-dives on Docker Test Automation Interview Questions 2026 for the container fundamentals that precede K8s, our CI/CD Pipeline Testing Interview Questions for the pipelines that deploy to your K8s clusters, and our SDET System Design Interview Questions 2026 for the architectural thinking behind distributed test infrastructure. The SDET Interview Coach iOS app includes Kubernetes-specific infrastructure design challenges — you describe your K8s scaling strategy and get AI-scored feedback against rubrics used at Google, Amazon, and Stripe for senior SDET roles.

Kubernetes Architecture Fundamentals — The QA Engineer's Translation Layer

Kubernetes documentation is written for platform engineers — not testers. But every K8s concept maps cleanly to a test automation concern. Here is the translation layer that turns K8s primitives into QA infrastructure building blocks:

# Production Kubernetes Manifest for SDET Test Infrastructure
# Covers: Pods, Deployments, Services, ConfigMaps, PVCs — Real Interview Patterns

---
# ConfigMap: Environment-specific test configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
  namespace: qa
data:
  app-base-url: "https://staging.bankscanai.com"
  browser-viewport: "1920x1080"
  default-timeout-seconds: "30"
  max-retries: "3"
  parallel-workers: "10"
  selenium-grid-url: "http://selenium-hub-service.qa.svc.cluster.local:4444"

---
# Secret: API keys and credentials (use External Secrets Operator in production!)
apiVersion: v1
kind: Secret
metadata:
  name: test-credentials
  namespace: qa
type: Opaque
data:
  api-key: WW91clNlY3JldEFQSUtleUhlcmU=  # base64-encoded placeholder
  test-user-password: VGVzdFBhc3N3b3JkMTIzIQ==

---
# Deployment: Selenium Grid Hub (stateless router — Deployment is the right choice)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: selenium-hub
  namespace: qa
  labels:
    app: selenium-grid
    component: hub
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0   # Never drop below desired replicas during rollouts
      maxSurge: 1         # Allow one extra pod during rollouts
  selector:
    matchLabels:
      app: selenium-grid
      component: hub
  template:
    metadata:
      labels:
        app: selenium-grid
        component: hub
    spec:
      terminationGracePeriodSeconds: 120  # Allow hub to drain sessions
      containers:
        - name: selenium-hub
          image: selenium/hub:4.27
          ports:
            - containerPort: 4442  # Subscriber events
            - containerPort: 4443  # HTTP (session queue)
            - containerPort: 4444  # HTTPS / GraphQL
          envFrom:
            - configMapRef:
                name: test-config
            - secretRef:
                name: test-credentials
          resources:
            requests:
              memory: "512Mi"
              cpu: "500m"
            limits:
              memory: "1Gi"
              cpu: "1000m"
          livenessProbe:
            httpGet:
              path: /status
              port: 4444
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /status
              port: 4444
            initialDelaySeconds: 15
            periodSeconds: 5
            failureThreshold: 2
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "curl -X POST http://localhost:4444/se/grid/api/drain && sleep 90"]

---
# Service: Stable endpoint for Selenium Grid Hub
apiVersion: v1
kind: Service
metadata:
  name: selenium-hub-service
  namespace: qa
spec:
  type: ClusterIP
  selector:
    app: selenium-grid
    component: hub
  ports:
    - name: http
      port: 4444
      targetPort: 4444
    - name: events
      port: 4442
      targetPort: 4442

---
# Deployment: Chrome Browser Nodes — independently scalable
apiVersion: apps/v1
kind: Deployment
metadata:
  name: selenium-node-chrome
  namespace: qa
spec:
  replicas: 5  # Scale independently of Firefox/Edge node pools
  selector:
    matchLabels:
      app: selenium-grid
      component: node
      browser: chrome
  template:
    metadata:
      labels:
        app: selenium-grid
        component: node
        browser: chrome
    spec:
      containers:
        - name: selenium-node-chrome
          image: selenium/node-chrome:4.27
          env:
            - name: SE_EVENT_BUS_HOST
              value: "selenium-hub-service"
            - name: SE_EVENT_BUS_PUBLISH_PORT
              value: "4442"
            - name: SE_EVENT_BUS_SUBSCRIBE_PORT
              value: "4443"
            - name: SE_NODE_MAX_SESSIONS
              value: "3"
            - name: SE_VNC_NO_PASSWORD
              value: "1"
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "2Gi"
              cpu: "2000m"
          volumeMounts:
            - name: test-reports
              mountPath: /tmp/test-reports
      volumes:
        - name: test-reports
          persistentVolumeClaim:
            claimName: test-reports-pvc

---
# PersistentVolumeClaim: Shared storage for test artifacts
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-reports-pvc
  namespace: qa
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
  storageClassName: standard

---
# Job: Playwright test execution as an ephemeral Job
apiVersion: batch/v1
kind: Job
metadata:
  name: playwright-tests-{{ .Release.Revision }}
  namespace: qa
  labels:
    app: playwright-tests
spec:
  parallelism: 10        # Run 10 test pods in parallel
  completions: 10        # Wait for all 10 to complete
  backoffLimit: 2        # Retry each pod up to 2 times on failure
  ttlSecondsAfterFinished: 3600  # Auto-cleanup after 1 hour
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: playwright
          image: mcr.microsoft.com/playwright:v1.52-jammy
          command: ["npx", "playwright", "test", "--shard={{ .podIndex }}/{{ .numPods }}"]
          envFrom:
            - configMapRef:
                name: test-config
          env:
            - name: POD_INDEX
              valueFrom:
                fieldRef:
                  fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']
          resources:
            requests:
              memory: "1Gi"
              cpu: "1000m"
            limits:
              memory: "2Gi"
              cpu: "2000m"
          livenessProbe:
            exec:
              command:
                - /bin/sh
                - -c
                - "find /tmp -name heartbeat -mmin -2 | grep -q heartbeat"
            initialDelaySeconds: 120
            periodSeconds: 30
            failureThreshold: 3
          volumeMounts:
            - name: test-reports
              mountPath: /app/test-results
      volumes:
        - name: test-reports
          persistentVolumeClaim:
            claimName: test-reports-pvc

Helm Charts — Templating Test Infrastructure for Reusability

Raw Kubernetes YAML gets you running. Helm gets you maintainable across teams, environments, and time. The SDET interview question: "You have three squads, each needing their own Selenium Grid deployment on the shared K8s cluster. How do you avoid copy-pasting 500 lines of YAML per squad?"

# Helm Chart Structure for SDET Test Infrastructure

# Chart.yaml — Package metadata
apiVersion: v2
name: selenium-grid
description: A reusable Helm chart for Selenium Grid test infrastructure
type: application
version: 2.3.0
appVersion: "4.27.0"

# values.yaml — All configurable parameters with sensible defaults
replicaCount:
  hub: 2
  chrome: 5
  firefox: 2
  edge: 1

selenium:
  hub:
    image:
      repository: selenium/hub
      tag: "4.27"
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "1Gi"
        cpu: "1000m"
    service:
      type: ClusterIP
      port: 4444
    terminationGracePeriodSeconds: 120
  nodes:
    chrome:
      maxSessions: 3
      resources:
        requests:
          memory: "1Gi"
          cpu: "500m"
        limits:
          memory: "2Gi"
          cpu: "2000m"
    firefox:
      maxSessions: 3
      resources:
        requests:
          memory: "1Gi"
          cpu: "500m"
        limits:
          memory: "2Gi"
          cpu: "2000m"

testConfig:
  env: "staging"
  baseUrl: "https://staging.myapp.com"
  viewport: "1920x1080"
  timeout: 30
  retries: 2
  parallelWorkers: 8

monitoring:
  prometheus:
    enabled: true
    scrapeInterval: "30s"
  grafana:
    dashboardLabel: "selenium-grid"

# templates/deployment-hub.yaml — Templated Hub Deployment
# Uses Go templating: {{ .Values.selenium.hub.resources.requests.memory }}
# Command: helm install selenium-grid ./selenium-grid -f values-staging.yaml -n qa

CI/CD with Argo CD — GitOps for Test Infrastructure

Running helm install from your CI pipeline works. But GitOps with Argo CD is what senior SDET panels want to hear about — it represents the shift from "CI pushes infrastructure changes" to "infrastructure converges to what's declared in Git."

# Argo CD Application Manifests for SDET Test Infrastructure

---
# Root Application (App of Apps) — manages all squad environments
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test-infrastructure-root
  namespace: argocd
spec:
  project: qa-infrastructure
  source:
    repoURL: https://github.com/myorg/test-infrastructure-gitops
    targetRevision: main
    path: apps/  # Directory containing per-squad Application YAMLs
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true       # Remove resources when Application is deleted
      selfHeal: true    # Revert manual changes to match Git state
      allowEmpty: false

---
# Per-Squad Application: Selenium Grid for Squad Alpha
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: selenium-grid-squad-alpha
  namespace: argocd
spec:
  project: qa-infrastructure
  source:
    repoURL: https://github.com/myorg/test-infrastructure-gitops
    targetRevision: main
    path: helm/selenium-grid
    helm:
      valueFiles:
        - ../../values/squad-alpha/staging.yaml  # Squad-specific overrides
  destination:
    server: https://kubernetes.default.svc
    namespace: squad-alpha-qa
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true     # Auto-create the squad namespace
      - PrunePropagationPolicy=foreground
    retry:
      limit: 3
      backoff:
        duration: "10s"
        factor: 2
        maxDuration: "3m"

---
# ApplicationSet: Ephemeral environments per feature branch (PR generator)
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: selenium-grid-pr-envs
  namespace: argocd
spec:
  generators:
    - pullRequest:
        github:
          owner: myorg
          repo: myapp
          tokenRef:
            secretName: github-token
            key: token
        requeueAfterSeconds: 300
  template:
    metadata:
      name: 'selenium-grid-pr-{{ "{{" }}branch_slug{{ "}}" }}'
    spec:
      project: qa-infrastructure
      source:
        repoURL: https://github.com/myorg/test-infrastructure-gitops
        targetRevision: main
        path: helm/selenium-grid
        helm:
          valueFiles:
            - ../../values/pr-env/default.yaml
      destination:
        server: https://kubernetes.default.svc
        namespace: 'pr-{{ "{{" }}branch_slug{{ "}}" }}-qa'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

Monitoring Test Pods — Prometheus, Grafana, and Loki

Deploying test infrastructure on Kubernetes without monitoring is like running tests without assertions — you have no idea if things are working until something breaks visibly. Senior SDET roles demand observability literacy.

# Prometheus ServiceMonitor for Selenium Grid metrics scraping

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: selenium-grid-monitor
  namespace: qa
  labels:
    release: prometheus-stack
spec:
  selector:
    matchLabels:
      app: selenium-grid
      component: hub
  endpoints:
    - port: http
      path: /metrics
      interval: 30s
      scrapeTimeout: 10s
  namespaceSelector:
    matchNames:
      - qa

---
# PrometheusRule: Alerting rules for Selenium Grid health
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: selenium-grid-alerts
  namespace: qa
spec:
  groups:
    - name: selenium-grid
      rules:
        - alert: SeleniumQueueBacklog
          expr: selenium_queue_size > 20
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Selenium Grid has {{ $value }} queued sessions"
            description: "Queue size exceeds 20 for more than 5 minutes. Consider scaling node replicas."
        - alert: SeleniumNodeCapacityLow
          expr: (selenium_active_sessions / selenium_max_sessions) > 0.85
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Selenium Grid at {{ $value | humanizePercentage }} capacity"
        - alert: SeleniumHighErrorRate
          expr: rate(selenium_session_errors_total[5m]) > 5
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "Elevated Selenium session error rate: {{ $value }}/s"
        - alert: TestPodFailed
          expr: kube_pod_status_phase{namespace="qa", phase="Failed"} > 0
          for: 1m
          labels:
            severity: warning
          annotations:
            summary: "{{ $value }} test pods in Failed state in QA namespace"

---
# Grafana Dashboard JSON snippet — Test Execution Overview panel
# Query: histogram_quantile(0.95, rate(test_duration_seconds_bucket[5m]))
# Panel type: Time series with threshold annotation

Playwright on Kubernetes — Job Patterns, Sharding, and Sidecars

Playwright's architecture makes it a natural fit for Kubernetes — each test runs in its own browser context, parallelisation is built into the test runner, and the mcr.microsoft.com/playwright Docker image ships with all browser binaries. But scaling Playwright on K8s requires understanding the Job pattern, sharding strategy, and the sidecar vs bundled browser decision.

Scaling Test Execution — HPA, Resource Limits, and Node Affinity

The whole point of Kubernetes is scaling — and SDET panels want to hear specific scaling strategies, not generic "we use autoscaling" hand-waves.