Docker for SDET Test Automation Interviews 2026 — Dockerfile Best Practices and Multi-Stage Builds for Test Images, Docker Compose for Local Test Stacks (Selenium Grid, Databases, API Services), Containerising Playwright and Selenium Tests for CI/CD Consistency, TestContainers for Integration Testing with Real Dependencies, Docker Volumes and Networks for Multi-Container Test Environments, Docker in CI/CD Pipelines (GitHub Actions, Jenkins, GitLab CI), Docker vs Kubernetes for Test Infrastructure Scaling Decisions, and How to Answer Docker Questions That Test Infrastructure Thinking at Senior SDET Panels

You've written tests. Good tests — Playwright tests, Selenium tests, API tests with Supertest. They pass on your machine. Then CI runs them, and they fail. "Element not found." "Connection refused." "Timeout waiting for selector." You check the CI logs: the database wasn't seeded. The Selenium Grid was on a different version. A background service timed out starting up. And your interview panel — hearing you describe this — leans forward and asks: "How do you ensure deterministic test execution across environments? Walk me through your containerisation strategy. What's the difference between ENTRYPOINT and CMD — and which would you use for a test runner image? When would you use TestContainers instead of a shared Docker Compose stack? Design a multi-container test environment that spins up PostgreSQL, Redis, Selenium Grid, and your test suite — and explain how you ensure service readiness before the first test executes. When does Docker Compose suffice for test infrastructure, and when do you graduate to Kubernetes?" And suddenly you realise: you've been running tests, but you haven't been engineering the infrastructure they run on. You've been treating Docker as a deployment tool — not as a test reliability engineering tool. And in 2026, that gap costs candidates the offer.

Docker has moved from a nice-to-have to a foundational SDET skill. In 2026, interview panels expect you to containerise tests, compose multi-service test environments, use TestContainers for integration tests with real dependencies, and design container-based CI/CD pipelines that produce deterministic, reproducible results. Not because Docker is trendy — because tests that depend on the host environment are unreliable tests. A test that passes on your macOS machine but fails in CI's Ubuntu runner is a test whose failure costs engineer-hours diagnosing environmental drift. Docker eliminates that class of failure by making the test environment identical everywhere. And that's exactly the argument interview panels want to hear: not "I use Docker because everyone uses Docker," but "I use Docker because it makes my test suite deterministic across environments — and here's how."

This guide covers every Docker topic that SDET interview panels probe in 2026 — from the Dockerfile fundamentals that gate junior-to-mid transitions, to the TestContainers patterns that signal senior-level integration testing maturity, to the Docker-vs-Kubernetes infrastructure decisions that separate test engineers from test architects. Complement it with our CI/CD deep-dive at CI/CD Pipeline Testing Interview Questions, our system design coverage at SDET System Design Interview Questions, and our test data patterns at SDET Test Data Management Interview Questions. The SDET Interview Coach iOS app includes dedicated infrastructure and containerisation mock interviews — with AI-scored rounds covering Docker, TestContainers, Docker Compose, and CI/CD integration at five seniority levels.

Docker Fundamentals Interviewers Test — Dockerfile, Images, and the Container Lifecycle

Every Docker interview starts with fundamentals. But in 2026, panels aren't asking "what's a Docker image?" — they're asking questions that test whether you've built and debugged Docker images in production test pipelines. A candidate who can explain the difference between ENTRYPOINT and CMD with use cases from a real test suite demonstrates something the junior candidate can't: they've hit the sharp edges and learned from them.

# Dockerfile — Multi-stage build for a Playwright TypeScript test suite
# Stage 1: Builder — compile TypeScript, install browsers
FROM mcr.microsoft.com/playwright:v1.44.0-focal AS builder

WORKDIR /app

# Copy package files first — leverage Docker layer caching
COPY package*.json ./
RUN npm ci

# Copy source and compile TypeScript
COPY tsconfig.json ./
COPY src/ ./src/
RUN npx tsc

# Install Playwright browsers (Chromium, Firefox, WebKit)
RUN npx playwright install --with-deps

# Stage 2: Runtime — lean test execution image
FROM mcr.microsoft.com/playwright:v1.44.0-focal

WORKDIR /app

# Copy only production dependencies from builder
COPY --from=builder /app/node_modules ./node_modules

# Copy compiled JavaScript output from builder
COPY --from=builder /app/dist ./dist

# Copy Playwright browser binaries from builder (avoids re-download)
COPY --from=builder /root/.cache/ms-playwright /root/.cache/ms-playwright

# Copy test configuration and fixtures
COPY playwright.config.ts ./
COPY fixtures/ ./fixtures/

# ENTRYPOINT: the test runner (not overridable without --entrypoint)
ENTRYPOINT ["npx", "playwright", "test"]

# CMD: default arguments (overridable at docker run time)
CMD ["--config=playwright.ci.config.ts"]

The interview answer that demonstrates depth: "I structure test Docker images as multi-stage builds. Stage 1 — the builder — installs all dependencies including devDependencies, compiles TypeScript to JavaScript, and downloads browser binaries. Stage 2 — the runtime — copies only production node_modules, compiled output, and browser binaries from Stage 1. This produces an image that's 60-70% smaller than a single-stage build, pulls faster in CI (reducing cold-start pipeline time), and doesn't expose build tools inside the runtime container. I use ENTRYPOINT for the test runner binary and CMD for default flags — so CI can override flags without a new image build. I mount test reports as a Docker volume so they survive container termination, and I use a .dockerignore file to exclude node_modules, .git, and local test artifacts from the build context — which speeds up the COPY step and prevents cache invalidation from local cruft."

Containerising Playwright and Selenium Tests — The Practical Patterns

Every SDET has run Playwright or Selenium tests locally. Containerising those tests — and making them run identically in CI — is the skill panels probe for evidence of operational maturity. The questions aren't "can you run a Playwright test in Docker?" — they're "explain your container strategy for browser-based tests, how you handle browser binaries, how you mount test reports, and how you debug a containerised test that's failing in CI but passing locally."

# docker-compose.yml — Selenium Grid for parallel cross-browser testing
type DockerCompose = (services: {
  selenium-hub: {
    image: string;
    container_name: string;
    ports: string[];
    environment: Record<string, string>;
  };
  chrome: {
    image: string;
    depends_on: string[];
    environment: Record<string, string>;
    volumes: string[];
  };
  firefox: {
    image: string;
    depends_on: string[];
    environment: Record<string, string>;
    volumes: string[];
  };
  test-runner: {
    build: { context: string; dockerfile: string };
    depends_on: string[];
    environment: Record<string, string>;
    volumes: string[];
    command: string;
  };
}) => void;

# Actual docker-compose.yml:
version: '3.8'

services:
  selenium-hub:
    image: selenium/hub:4.18
    container_name: selenium-hub
    ports:
      - "4442:4442"  # Subscriber
      - "4443:4443"  # Publisher
      - "4444:4444"  # UI + W3C WebDriver endpoint
    environment:
      SE_SESSION_REQUEST_TIMEOUT: 300
      SE_SESSION_RETRY_INTERVAL: 5

  chrome:
    image: selenium/node-chrome:4.18
    depends_on:
      - selenium-hub
    environment:
      SE_EVENT_BUS_HOST: selenium-hub
      SE_EVENT_BUS_PUBLISH_PORT: 4442
      SE_EVENT_BUS_SUBSCRIBE_PORT: 4443
      SE_NODE_MAX_SESSIONS: 4
      SE_NODE_SESSION_TIMEOUT: 300
    volumes:
      - ./videos/chrome:/videos  # Session video recording

  firefox:
    image: selenium/node-firefox:4.18
    depends_on:
      - selenium-hub
    environment:
      SE_EVENT_BUS_HOST: selenium-hub
      SE_EVENT_BUS_PUBLISH_PORT: 4442
      SE_EVENT_BUS_SUBSCRIBE_PORT: 4443
      SE_NODE_MAX_SESSIONS: 4
    volumes:
      - ./videos/firefox:/videos

  test-runner:
    build:
      context: .
      dockerfile: Dockerfile.selenium
    depends_on:
      selenium-hub:
        condition: service_healthy
    environment:
      SELENIUM_HUB_URL: http://selenium-hub:4444
      TEST_ENV: ci
    volumes:
      - ./test-results:/app/test-results
      - ./screenshots:/app/screenshots
    command: ["npm", "run", "test:e2e:ci"]

# Scale up: docker compose up --scale chrome=3 --scale firefox=2
# Result: 12 Chrome sessions + 8 Firefox sessions = 20 parallel tests

TestContainers — Integration Testing with Real Dependencies

TestContainers is the topic that most separates mid-level from senior SDETs in Docker interviews. When a panel asks "how do you test database integrations?" and the candidate says "I mock the database layer" — alarm bells ring. Mocking a database means you're not testing the actual SQL, the actual connection pool behaviour, or the actual transaction isolation. TestContainers solves this by spinning up real infrastructure — PostgreSQL, Redis, Kafka, Elasticsearch, Selenium browser containers — directly from your test code, using Docker under the hood. The containers are ephemeral: they start before the test, run during the test, and are destroyed after. Every test gets a clean, isolated instance.

// TestContainers with TypeScript + Jest — Integration test with real PostgreSQL
import {
  PostgreSqlContainer,
  type StartedPostgreSqlContainer,
} from '@testcontainers/postgresql';
import { RedisContainer } from '@testcontainers/redis';
import { GenericContainer } from 'testcontainers';
import { Client } from 'pg';
import { createApp } from '../src/app';

describe('Order Service Integration Tests', () => {
  let postgresContainer: StartedPostgreSqlContainer;
  let redisContainer: any;
  let dbClient: Client;
  let app: any;

  beforeAll(async () => {
    // Start PostgreSQL container with test-specific configuration
    postgresContainer = await new PostgreSqlContainer('postgres:16-alpine')
      .withDatabase('orders_test')
      .withUsername('test_user')
      .withPassword('test_password')
      .withExposedPorts(5432)
      .start();

    // Start Redis container for caching layer
    redisContainer = await new RedisContainer('redis:7-alpine')
      .withExposedPorts(6379)
      .start();

    // Connect and run migrations — using real database, real SQL
    dbClient = new Client({
      host: postgresContainer.getHost(),
      port: postgresContainer.getPort(),
      database: postgresContainer.getDatabase(),
      user: postgresContainer.getUsername(),
      password: postgresContainer.getPassword(),
    });
    await dbClient.connect();
    await dbClient.query(`
      CREATE TABLE orders (
        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
        user_id VARCHAR(50) NOT NULL,
        total DECIMAL(10,2) NOT NULL,
        status VARCHAR(20) DEFAULT 'pending',
        created_at TIMESTAMP DEFAULT NOW()
      )
    `);

    // Start the app with real infrastructure
    app = createApp({
      postgresUrl: postgresContainer.getConnectionUri(),
      redisUrl: redisContainer.getConnectionUrl(),
    });
  }, 60000); // 60s timeout for container startup

  afterAll(async () => {
    await dbClient.end();
    await postgresContainer.stop();
    await redisContainer.stop();
  });

  beforeEach(async () => {
    // Clean data between tests — each test gets a clean slate
    await dbClient.query('DELETE FROM orders');
  });

  it('creates an order and returns it with calculated total', async () => {
    const response = await app.createOrder({
      userId: 'user-001',
      items: [
        { productId: 'prod-1', quantity: 2, price: 29.99 },
        { productId: 'prod-2', quantity: 1, price: 49.99 },
      ],
    });

    expect(response.status).toBe(201);
    expect(response.body.total).toBe(109.97); // Real calculation tested

    // Verify the data actually persisted correctly
    const { rows } = await dbClient.query(
      'SELECT * FROM orders WHERE id = $1',
      [response.body.id]
    );
    expect(rows[0].status).toBe('pending');
    expect(parseFloat(rows[0].total)).toBe(109.97);
  });

  it('handles concurrent order creation with optimistic locking', async () => {
    // Test actual transaction isolation — impossible with mocks
    const order1 = app.createOrder({ userId: 'user-001', items: [{ productId: 'last-item', quantity: 1, price: 10.00 }] });
    const order2 = app.createOrder({ userId: 'user-001', items: [{ productId: 'last-item', quantity: 1, price: 10.00 }] });

    const results = await Promise.allSettled([order1, order2]);
    const succeeded = results.filter(r => r.status === 'fulfilled').length;

    // Only one should succeed if inventory logic is correct
    expect(succeeded).toBe(1);
  });
});

Docker Volumes and Networks — The Multi-Container Plumbing Interviewers Probe

Docker volumes and networks are the "plumbing" concepts that most candidates skip over — and that senior panels probe specifically. When you understand volumes, you understand how test artifacts survive container termination. When you understand networks, you understand how containers discover each other and why "localhost" means different things inside and outside a container. These aren't trivia — they're the operational knowledge that determines whether your containerised test suite works on the first try or consumes three days of debugging.

# Docker Compose — Multi-container networking with health checks and dependencies
type DockerComposeEnv = {
  services: {
    postgres: { host: string; port: number; db: string };
    redis: { host: string; port: number };
    localstack: { host: string; port: number };
    test_runner: { build: string; depends_on: Record<string, 'service_healthy'>; environment: Record<string, string>; volumes: string[] };
  };
  networks: { test_network: { driver: 'bridge' } };
  volumes: { pg_data: {}, test_results: {} };
}; void;

# Actual docker-compose.integration.yml:
version: '3.8'

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: testdb
      POSTGRES_USER: tester
      POSTGRES_PASSWORD: testpass
    ports:
      - "5432"  # Random host port — avoids conflicts
    volumes:
      - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U tester -d testdb"]
      interval: 2s
      timeout: 5s
      retries: 10
    networks:
      - test_network

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 2s
      timeout: 3s
      retries: 10
    networks:
      - test_network

  localstack:
    image: localstack/localstack:3.0
    environment:
      SERVICES: s3,dynamodb,sqs
      DEFAULT_REGION: eu-west-2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:4566/_localstack/health"]
      interval: 5s
      timeout: 10s
      retries: 5
    networks:
      - test_network

  test-runner:
    build:
      context: .
      dockerfile: Dockerfile.test
    depends_on:
      postgres:
        condition: service_healthy  # Wait for actual readiness, not just container start
      redis:
        condition: service_healthy
      localstack:
        condition: service_healthy
    environment:
      PG_HOST: postgres          # Service name = DNS hostname
      PG_PORT: "5432"
      PG_DB: testdb
      PG_USER: tester
      PG_PASSWORD: testpass
      REDIS_HOST: redis
      REDIS_PORT: "6379"
      AWS_ENDPOINT: http://localstack:4566
      AWS_REGION: eu-west-2
      NODE_ENV: test
    volumes:
      - ./test-results:/app/test-results  # Artifact persistence
      - ./coverage:/app/coverage
    networks:
      - test_network
    command: ["npm", "run", "test:integration"]

networks:
  test_network:
    driver: bridge

volumes:
  pg_data:
  test_results:

Docker in CI/CD Pipelines — The Deterministic Test Execution Pattern

The reason Docker dominates CI/CD test pipelines is simple: determinism. A test suite that runs in a Docker container on your laptop runs in exactly the same environment in GitHub Actions, Jenkins, or GitLab CI. Same OS, same dependencies, same browser versions, same system libraries. Docker eliminates the "it works on my machine" class of test failures by making the CI environment identical to the development environment. But getting Docker right in CI requires understanding layer caching, service containers, artifact extraction, and the pipeline patterns that make containerised tests fast enough to gate deployments. For the full CI/CD testing picture, see our dedicated guide at CI/CD Pipeline Testing Interview Questions.

# .github/workflows/e2e-tests.yml — Dockerised Playwright tests with service containers
name: E2E Tests (Docker)
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    
    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: tester
          POSTGRES_PASSWORD: testpass
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U tester -d testdb"
          --health-interval 2s
          --health-timeout 5s
          --health-retries 10
      
      redis:
        image: redis:7-alpine
        ports:
          - 6379:6379
        options: >-
          --health-cmd "redis-cli ping"
          --health-interval 2s
          --health-timeout 3s
          --health-retries 10

    container:
      image: ghcr.io/myorg/playwright-tests:latest
      credentials:
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
      options: >-
        --network host
        -v ${{ github.workspace }}/test-results:/app/test-results
        -v ${{ github.workspace }}/playwright-report:/app/playwright-report

    steps:
      - uses: actions/checkout@v4

      - name: Run Playwright E2E tests
        run: npx playwright test --config=playwright.ci.config.ts
        env:
          DATABASE_URL: postgresql://tester:testpass@localhost:5432/testdb
          REDIS_URL: redis://localhost:6379

      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-results
          path: |
            test-results/
            playwright-report/
          retention-days: 7

      - name: Upload screenshots on failure
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-screenshots
          path: test-results/**/*.png
          retention-days: 7

Docker vs Kubernetes for Test Infrastructure — The Scaling Decision

This is the strategic infrastructure question that appears at the senior and lead SDET level: "When do you move from Docker Compose to Kubernetes for test infrastructure?" Panels aren't looking for Kubernetes evangelism — they're looking for engineering judgment. The candidate who says "Kubernetes for everything" has demonstrated trend-following. The candidate who says "Docker Compose suffices for most test needs; here's when Kubernetes adds value" has demonstrated infrastructure maturity.

# Kubernetes Job — Run a Playwright test suite to completion on a k8s cluster
apiVersion: batch/v1
kind: Job
metadata:
  name: playwright-e2e-${GIT_SHA}
  namespace: test-automation
  labels:
    app: playwright-tests
    pr: "${PR_NUMBER}"
spec:
  backoffLimit: 1        # Retry once on failure
  ttlSecondsAfterFinished: 3600  # Auto-cleanup after 1 hour
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: playwright
          image: ghcr.io/myorg/playwright-tests:${GIT_SHA}
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: test-db-credentials
                  key: url
            - name: TEST_ENV
              value: "k8s-ci"
          resources:
            requests:
              memory: "2Gi"
              cpu: "2"
            limits:
              memory: "4Gi"
              cpu: "4"
          volumeMounts:
            - name: test-results
              mountPath: /app/test-results
      volumes:
        - name: test-results
          persistentVolumeClaim:
            claimName: playwright-results-pvc

Common Docker Interview Questions for SDETs — And How to Answer Them

After 20 years of SDET interview panels, Mitchell has catalogued the Docker and containerisation questions that appear most frequently. Here's the question bank with the answer patterns that separate candidates who've tinkered with Docker from those who've engineered containerised test infrastructure at scale.

How SDET Interview Coach Prepares You for Docker and Infrastructure Interview Rounds

Docker knowledge is no longer optional for SDETs — it's table stakes at mid-level and the differentiator at senior. The SDET Interview Coach iOS app prepares you for Docker and infrastructure rounds with AI-powered mock interviews that simulate the exact flow of a containerisation-focused SDET interview — from the opening "explain the difference between ENTRYPOINT and CMD" to the architect-level "design a containerised test infrastructure for 50 parallel test suites across 3 cloud regions."

The app's infrastructure topic area covers Docker, Docker Compose, TestContainers, Kubernetes for testing, CI/CD container patterns, and cloud infrastructure for test environments — with questions calibrated to five seniority levels. At junior level, the questions focus on Dockerfile basics, running containers, and simple docker-compose.yml files. At mid level, they cover multi-stage builds, TestContainers, service containers in CI, and volume/network patterns. At senior and lead levels, they probe infrastructure architecture — Docker-vs-Kubernetes decisions, multi-region test infrastructure design, cost-optimisation of containerised CI pipelines, and the design of self-service test environment platforms that serve 100+ engineering teams.

The AI mock interviewer scores your answers on technical accuracy, completeness, communication clarity, and real-world applicability — the same criteria real interview panels use. After each mock round, you receive a detailed scorecard with specific feedback on what to improve, plus links to the relevant sections in our infrastructure guides (including this Docker guide, the CI/CD Pipeline Testing guide, and the System Design guide). The spaced repetition system ensures you retain Dockerfile instruction semantics, Docker Compose healthcheck patterns, and the TestContainers API patterns that interviewers expect you to recall under pressure. Use Job Match to generate 50 bespoke questions from any job description that mentions Docker, Kubernetes, containerisation, or CI/CD — and walk into your interview knowing you've practised the exact questions your panel will ask.

For the broader infrastructure picture, complement this guide with CI/CD Pipeline Testing Interview Questions for the full pipeline integration perspective and SDET System Design Interview Questions for the architectural patterns that Docker enables in distributed test infrastructure.