Backend interview prep

Start

Container Security Interview Questions (Top 30 Questions with Answers)

Master Container Security Interview Questions with production-ready explanations covering image security, supply-chain protection, runtime security, least privilege, Kubernetes RBAC, Pod Security Standards, secrets management, network policies, admission control, monitoring, and incident response.

Module Navigation

Previous: Helm QA | Parent: Containers Learning Path | Next: Production Kubernetes QA

Introduction

Container security protects containerized applications throughout the complete software lifecycle:

Source Code
     │
     ▼
Build Pipeline
     │
     ▼
Container Image
     │
     ▼
Container Registry
     │
     ▼
Deployment Platform
     │
     ▼
Running Container
     │
     ▼
Monitoring and Incident Response

Securing only the running container is not enough. A production security strategy must protect:

  • Source code
  • Dependencies
  • Container images
  • CI/CD pipelines
  • Registries
  • Kubernetes clusters
  • Runtime processes
  • Network communication
  • Secrets
  • Supply-chain integrity

This guide contains 30 production-oriented Container Security interview questions and answers covering Docker, Kubernetes, OpenShift, Amazon EKS, Azure AKS, Google GKE, and enterprise cloud-native platforms.

Container Security Learning Roadmap

Secure Source Code
        │
        ▼
Secure Dockerfile
        │
        ▼
Scan Dependencies
        │
        ▼
Build Immutable Image
        │
        ▼
Sign and Store Image
        │
        ▼
Validate During Admission
        │
        ▼
Run with Least Privilege
        │
        ▼
Restrict Network Access
        │
        ▼
Monitor Runtime Behavior
        │
        ▼
Respond to Incidents

Container Security Fundamentals

1. What is container security?

Container security is the practice of protecting containerized applications, images, registries, orchestration platforms, networks, and runtime environments from vulnerabilities and unauthorized access.

Container security covers several layers:

  • Application dependencies
  • Container image
  • Container runtime
  • Host operating system
  • Kubernetes cluster
  • Network communication
  • Secrets
  • CI/CD supply chain

A vulnerability at any one of these layers can compromise the application.

2. Why is container security different from virtual machine security?

Containers share the host operating-system kernel, while virtual machines normally run separate guest operating systems.

Virtual Machines

App A          App B
  │              │
Guest OS A    Guest OS B
      \          /
        Hypervisor
            │
         Host OS


Containers

App A          App B
  │              │
Container A   Container B
       \         /
     Shared Host Kernel

Because containers share the kernel:

  • A kernel vulnerability can affect multiple containers.
  • Privileged containers may access host resources.
  • Namespace isolation must be configured correctly.
  • Runtime controls are especially important.

Virtual machines generally provide stronger isolation, while containers provide lighter and faster application packaging.

3. What are the major container security attack surfaces?

The main attack surfaces are:

  1. Source-code repositories
  2. Open-source dependencies
  3. Dockerfiles
  4. CI/CD pipelines
  5. Container images
  6. Container registries
  7. Kubernetes API Server
  8. Worker nodes
  9. Container runtime
  10. Pod-to-Pod networking
  11. Secrets and credentials
  12. Third-party Helm charts
  13. Admission controllers
  14. Runtime processes

A complete security program must protect the entire lifecycle rather than scanning only the final image.

Image Security

4. How do you secure a container image?

Use the following practices:

  • Start with trusted base images.
  • Use minimal images.
  • Pin image versions or digests.
  • Remove unnecessary packages.
  • Use multi-stage builds.
  • Run vulnerability scans.
  • Never include secrets.
  • Sign the image.
  • Generate an SBOM.
  • Store it in a private registry.
  • Enforce immutable tags.
  • Rebuild images regularly.

Example:

FROM eclipse-temurin:21-jre-alpine

RUN addgroup -S appgroup && adduser -S appuser -G appgroup

WORKDIR /app

COPY --chown=appuser:appgroup application.jar application.jar

USER appuser

ENTRYPOINT ["java", "-jar", "application.jar"]

5. Why should minimal base images be used?

Minimal images contain fewer:

  • Operating-system packages
  • Shell utilities
  • Package managers
  • Libraries
  • Executable tools

This reduces:

  • Image size
  • Vulnerability count
  • Download time
  • Patch workload
  • Attack surface

Common options include:

  • Distroless images
  • Alpine-based images
  • Slim runtime images
  • Organization-approved hardened images

However, image compatibility and debugging requirements must also be considered.

6. What is the difference between an Alpine image and a distroless image?

Alpine Image Distroless Image
Minimal Linux distribution Contains only application runtime requirements
Usually includes package manager Usually excludes package manager
Often includes a shell Usually has no shell
Easier to debug More difficult to debug
Small attack surface Even smaller attack surface
Uses musl libc Depends on the selected runtime image

Distroless images are often preferred for hardened production workloads, while Alpine images may be easier during development and troubleshooting.

7. What is container image scanning?

Container image scanning identifies known vulnerabilities in:

  • Operating-system packages
  • Language dependencies
  • Runtime libraries
  • Application components
  • Container configuration

Typical pipeline:

Build Image
     │
     ▼
Scan Image
     │
 ┌───┴────────────┐
 ▼                ▼
Safe         Critical CVEs
 │                │
 ▼                ▼
Sign and Push   Block Build

Scanning should happen:

  • During pull-request validation
  • After image build
  • Before registry promotion
  • During admission
  • Continuously after deployment

8. What is an SBOM?

SBOM means Software Bill of Materials.

It lists the software components included in an artifact, such as:

  • Base image
  • Operating-system packages
  • Java libraries
  • Node.js packages
  • Python packages
  • Native libraries
  • Component versions
  • Licensing information

An SBOM helps organizations:

  • Identify affected applications during a vulnerability disclosure
  • Track open-source components
  • Perform license reviews
  • Improve supply-chain visibility
  • Meet compliance requirements

9. What is image signing?

Image signing cryptographically verifies:

  • Who produced the image
  • Whether the image was modified
  • Whether it came from a trusted pipeline

A secure flow is:

CI/CD Build
     │
     ▼
Security Scan
     │
     ▼
Generate SBOM
     │
     ▼
Sign Image
     │
     ▼
Push to Registry
     │
     ▼
Admission Verification

Kubernetes admission policies can reject unsigned or untrusted images.

10. Why should the latest image tag be avoided?

The latest tag is mutable and does not identify a specific build.

Problems include:

  • Different clusters may pull different image contents.
  • Rollbacks become unreliable.
  • Auditing becomes difficult.
  • Deployments are not reproducible.
  • Unauthorized image replacement is harder to detect.

Prefer:

image: registry.example.com/payment-api:3.5.1

For stronger immutability, use a digest:

image: registry.example.com/payment-api@sha256:example-digest

Container Runtime Security

11. Why should containers not run as root?

A root process inside a container may have increased ability to exploit:

  • Misconfigured volume mounts
  • Runtime vulnerabilities
  • Host devices
  • Kernel vulnerabilities
  • Excessive Linux capabilities

Run containers using a non-root user.

Dockerfile example:

RUN addgroup -S appgroup \
    && adduser -S appuser -G appgroup

USER appuser

Kubernetes example:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001

12. What is a Kubernetes SecurityContext?

A securityContext defines security settings for a Pod or container.

Example:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

It can control:

  • User and group ID
  • Privileged execution
  • Linux capabilities
  • Privilege escalation
  • Root filesystem permissions
  • SELinux settings
  • Seccomp profile

13. What is a privileged container?

A privileged container receives extensive access to host resources and bypasses many normal isolation controls.

A privileged container may be able to:

  • Access host devices
  • Modify kernel settings
  • Manage network interfaces
  • Mount filesystems
  • Escape normal container restrictions

Example of a dangerous setting:

securityContext:
  privileged: true

Privileged containers should be blocked unless a documented infrastructure requirement exists.

14. What are Linux capabilities?

Linux capabilities divide root privileges into smaller permission units.

Examples include:

  • NET_ADMIN
  • SYS_ADMIN
  • CHOWN
  • SETUID
  • NET_BIND_SERVICE

Instead of granting broad root access, grant only the capability the application requires.

Recommended approach:

securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE

Most application containers should drop all capabilities.

15. What is allowPrivilegeEscalation?

allowPrivilegeEscalation controls whether a process can gain more privileges than its parent process.

Recommended configuration:

securityContext:
  allowPrivilegeEscalation: false

It helps prevent privilege escalation through mechanisms such as setuid binaries.

16. Why use a read-only root filesystem?

A read-only root filesystem prevents applications or attackers from changing the container image filesystem.

securityContext:
  readOnlyRootFilesystem: true

Benefits include:

  • Preventing malicious binary modification
  • Reducing persistence opportunities
  • Enforcing immutable-container behavior
  • Detecting applications that incorrectly write locally

Writable paths should be mounted explicitly:

volumeMounts:
  - name: temporary-data
    mountPath: /tmp

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

17. What are seccomp, AppArmor, and SELinux?

These technologies restrict container behavior.

Technology Purpose
seccomp Restricts Linux system calls
AppArmor Restricts application access using security profiles
SELinux Applies mandatory access-control labels and policies

Example seccomp configuration:

securityContext:
  seccompProfile:
    type: RuntimeDefault

A production container should normally use the runtime's default seccomp profile or an approved custom profile.

Kubernetes Security

18. What are Kubernetes Pod Security Standards?

Pod Security Standards define three security levels:

  • Privileged
  • Baseline
  • Restricted

Privileged

Allows unrestricted workloads and should be limited to trusted infrastructure components.

Baseline

Blocks well-known privilege-escalation risks while remaining compatible with many applications.

Restricted

Applies strong hardening requirements such as:

  • Non-root execution
  • Restricted capabilities
  • Seccomp usage
  • No privilege escalation
  • Restricted volume types

Production application namespaces should generally target the Restricted standard where possible.

19. What is Pod Security Admission?

Pod Security Admission is a built-in Kubernetes admission mechanism that enforces Pod Security Standards at the namespace level.

Example namespace labels:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Modes include:

  • Enforce
  • Audit
  • Warn

20. How does Kubernetes RBAC improve container security?

Role-Based Access Control determines who can perform which actions on Kubernetes resources.

RBAC components include:

  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payments
  name: payment-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list", "watch"]

Best practices:

  • Follow least privilege.
  • Prefer namespace-scoped Roles.
  • Avoid wildcard permissions.
  • Avoid unnecessary cluster-admin.
  • Review bindings regularly.
  • Use separate service accounts for each workload.

21. Why should every application use a dedicated ServiceAccount?

A dedicated ServiceAccount allows each workload to receive only its required Kubernetes permissions.

Avoid using the default ServiceAccount for every application.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-api
  namespace: payments

Pod configuration:

spec:
  serviceAccountName: payment-api
  automountServiceAccountToken: false

Set automountServiceAccountToken: false when the application does not need Kubernetes API access.

22. What are Kubernetes NetworkPolicies?

NetworkPolicies control communication between Pods and network endpoints.

Without policies, many clusters allow broad Pod-to-Pod communication.

Example default-deny policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

A production strategy commonly follows:

Default Deny
     │
     ▼
Explicitly Allow Required Traffic

The CNI plugin must support NetworkPolicy enforcement.

23. How should secrets be managed in containers?

Never place secrets in:

  • Dockerfiles
  • Container images
  • Git repositories
  • Plain-text Helm values
  • Application source code
  • Build logs
  • Environment files committed to Git

Use:

  • HashiCorp Vault
  • AWS Secrets Manager
  • Azure Key Vault
  • Google Secret Manager
  • Kubernetes Secrets with encryption at rest
  • External Secrets Operator
  • Secrets Store CSI Driver
  • Sealed Secrets or SOPS

A preferred flow is:

Application Pod
      │
      ▼
Workload Identity
      │
      ▼
External Secret Manager
      │
      ▼
Short-Lived Secret

24. Are Kubernetes Secrets encrypted by default?

Kubernetes Secrets are encoded, not automatically protected merely because they are Base64 formatted.

Security requires:

  • Encryption at rest for etcd
  • Strict RBAC
  • Restricted namespace access
  • Audit logging
  • External secret management where appropriate
  • Secret rotation
  • Avoiding exposure through environment dumps and logs

Base64 encoding is not encryption.

Supply-Chain and Admission Security

25. What is container supply-chain security?

Container supply-chain security protects every step used to produce and distribute an image.

Developer
    │
    ▼
Source Repository
    │
    ▼
Build System
    │
    ▼
Dependencies
    │
    ▼
Container Image
    │
    ▼
Registry
    │
    ▼
Kubernetes Deployment

Controls include:

  • Protected source branches
  • Reviewed pull requests
  • Trusted build workers
  • Dependency scanning
  • Reproducible builds
  • SBOM generation
  • Image signing
  • Provenance verification
  • Private registries
  • Admission policies

26. What is an admission controller?

An admission controller evaluates Kubernetes API requests after authentication and authorization but before objects are stored.

Admission controls can:

  • Reject privileged Pods
  • Require resource limits
  • Enforce approved registries
  • Verify image signatures
  • Add security defaults
  • Require labels
  • Prevent hostPath usage
  • Require non-root execution

Policy tools may include:

  • ValidatingAdmissionPolicy
  • Open Policy Agent Gatekeeper
  • Kyverno
  • Cloud-provider policy services

27. What security policies should be enforced during admission?

Common policies include:

  • Images must come from approved registries.
  • Images must use immutable versions or digests.
  • Containers must not run as root.
  • Privileged containers are prohibited.
  • Privilege escalation is disabled.
  • All capabilities are dropped unless approved.
  • Host networking and host PID are prohibited.
  • Sensitive hostPath volumes are prohibited.
  • Resource requests and limits are required.
  • Runtime-default seccomp is required.
  • Critical vulnerabilities block deployment.
  • Signed images are required.

Monitoring and Incident Response

28. What is container runtime security?

Runtime security monitors running containers for suspicious behavior that may not be visible during image scanning.

Examples include:

  • Unexpected shell execution
  • Modification of system binaries
  • Access to sensitive host paths
  • Unexpected outbound connections
  • Cryptocurrency mining
  • Privilege escalation
  • New process execution
  • Suspicious system calls
  • Access to Kubernetes credentials

Runtime protection combines:

  • Process monitoring
  • Network monitoring
  • System-call analysis
  • File-integrity monitoring
  • Behavioral detection
  • Alerting and automated response

29. What should be monitored in a secure container platform?

Monitor:

Image and registry

  • Vulnerability findings
  • Unsigned images
  • Unexpected image changes
  • Registry login failures
  • Image-pull sources

Kubernetes

  • API Server audit logs
  • RBAC changes
  • ClusterRoleBindings
  • Secret access
  • Privileged Pod creation
  • Admission-policy violations
  • ServiceAccount token usage

Runtime

  • Container restarts
  • Unexpected processes
  • Shell execution
  • Network connections
  • File changes
  • CPU and memory anomalies
  • Cryptomining behavior
  • Container escape indicators

Infrastructure

  • Node health
  • Runtime versions
  • Kernel vulnerabilities
  • Patch status
  • Control-plane events

Use layered controls throughout the complete lifecycle.

                    Developer
                        │
                        ▼
             Protected Source Repository
                        │
                        ▼
                  CI/CD Pipeline
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
 Dependency Scan   Secret Scan   Code Analysis
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                Hardened Image Build
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
    Image Scan       Generate SBOM   Sign Image
          │             │             │
          └─────────────┼─────────────┘
                        ▼
               Private Image Registry
                        │
                        ▼
                Admission Policies
                        │
                        ▼
               Kubernetes Deployment
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
    Restricted Pod    RBAC      Network Policies
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                 Runtime Security
                        │
                        ▼
             Central Monitoring and SIEM
                        │
                        ▼
                Incident Response

A production platform should include:

  • Trusted hardened base images
  • Automated dependency and image scanning
  • SBOM generation
  • Image signing and verification
  • Private registries
  • Immutable image references
  • Pod Security Admission
  • Non-root containers
  • Read-only filesystems
  • Runtime-default seccomp
  • Least-privilege RBAC
  • Dedicated ServiceAccounts
  • NetworkPolicies
  • External secret management
  • Kubernetes audit logging
  • Runtime threat detection
  • Automated patching and image rebuilds
  • Centralized security monitoring
  • Documented incident-response procedures

Secure Dockerfile Example

# Build stage
FROM maven:3.9-eclipse-temurin-21 AS builder

WORKDIR /workspace

COPY pom.xml .
COPY src ./src

RUN mvn clean package -DskipTests


# Runtime stage
FROM eclipse-temurin:21-jre-alpine

RUN addgroup -S appgroup \
    && adduser -S appuser -G appgroup

WORKDIR /app

COPY --from=builder \
     --chown=appuser:appgroup \
     /workspace/target/payment-api.jar \
     payment-api.jar

USER appuser

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "payment-api.jar"]

Security improvements:

  • Multi-stage build
  • Smaller runtime image
  • Build tools excluded from runtime
  • Non-root user
  • Explicit working directory
  • Versioned base image recommended
  • No secrets stored in the image

Secure Kubernetes Deployment Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  namespace: payments
spec:
  replicas: 3

  selector:
    matchLabels:
      app: payment-api

  template:
    metadata:
      labels:
        app: payment-api

    spec:
      serviceAccountName: payment-api
      automountServiceAccountToken: false

      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
        seccompProfile:
          type: RuntimeDefault

      containers:
        - name: payment-api
          image: registry.example.com/payment-api:3.5.1
          imagePullPolicy: IfNotPresent

          ports:
            - name: http
              containerPort: 8080

          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            privileged: false
            capabilities:
              drop:
                - ALL

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

          volumeMounts:
            - name: temporary-data
              mountPath: /tmp

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

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

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

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

Default-Deny NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Allow API Traffic from Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-payment-api
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payment-api

  policyTypes:
    - Ingress

  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx

      ports:
        - protocol: TCP
          port: 8080

Container Security Layers

Application Security
        │
        ▼
Dependency Security
        │
        ▼
Image Security
        │
        ▼
Registry Security
        │
        ▼
Admission Security
        │
        ▼
Pod Security
        │
        ▼
Network Security
        │
        ▼
Runtime Security
        │
        ▼
Node and Cluster Security

Vulnerability Remediation Flow

New Vulnerability Published
          │
          ▼
Search SBOM Inventory
          │
          ▼
Identify Affected Images
          │
          ▼
Update Base Image or Dependency
          │
          ▼
Rebuild Image
          │
          ▼
Scan and Sign
          │
          ▼
Deploy Updated Version
          │
          ▼
Verify Runtime

Container Security Checklist

✓ Trusted Base Images
✓ Minimal Runtime Images
✓ Multi-Stage Builds
✓ Non-Root User
✓ No Privileged Containers
✓ Privilege Escalation Disabled
✓ Linux Capabilities Dropped
✓ Read-Only Root Filesystem
✓ RuntimeDefault Seccomp
✓ Image Vulnerability Scanning
✓ Dependency Scanning
✓ SBOM Generation
✓ Signed Images
✓ Immutable Tags or Digests
✓ Private Container Registry
✓ Registry Access Control
✓ Pod Security Admission
✓ Least-Privilege RBAC
✓ Dedicated ServiceAccounts
✓ ServiceAccount Token Disabled When Unused
✓ Default-Deny NetworkPolicies
✓ External Secret Management
✓ etcd Encryption
✓ Kubernetes Audit Logging
✓ Admission Policy Enforcement
✓ Runtime Threat Detection
✓ Node Patching
✓ Centralized Security Monitoring
✓ Incident Response Procedures

Quick Revision

Topic Key Point
Container Security Protects the entire container lifecycle
Minimal Image Reduces attack surface
Image Scan Finds known vulnerabilities
SBOM Lists software components
Image Signing Verifies integrity and origin
Non-Root User Reduces privilege risk
SecurityContext Defines Pod and container security
Linux Capabilities Fine-grained root privileges
seccomp Restricts system calls
Read-Only Filesystem Prevents runtime filesystem changes
Pod Security Standards Privileged, Baseline, and Restricted
RBAC Controls Kubernetes permissions
NetworkPolicy Restricts Pod communication
Admission Control Validates resources before creation
Runtime Security Detects suspicious behavior
External Secret Manager Protects and rotates secrets

Interview Tips

During Container Security interviews:

  • Explain security across the complete lifecycle, not only the running container.
  • Clearly describe the difference between image scanning and runtime security.
  • Mention minimal images, multi-stage builds, non-root users, and immutable image references.
  • Explain how namespaces, cgroups, Linux capabilities, seccomp, AppArmor, and SELinux contribute to isolation.
  • Understand SecurityContext, Pod Security Standards, Pod Security Admission, RBAC, and NetworkPolicies.
  • Explain why Base64-encoded Kubernetes Secrets are not automatically secure.
  • Discuss image signing, SBOMs, trusted registries, and admission verification.
  • Use a default-deny network model and explicitly allow required communication.
  • Mention external secret managers, workload identity, and short-lived credentials.
  • Include monitoring, audit logs, runtime detection, vulnerability remediation, and incident response in senior-level answers.
  • Support answers with examples from Docker, Kubernetes, OpenShift, Amazon EKS, Azure AKS, or Google GKE.

Summary

Container security requires layered protection from source code through runtime operations.

Strong interview performance requires understanding:

  • Image hardening
  • Vulnerability scanning
  • SBOMs
  • Image signing
  • Supply-chain security
  • Non-root execution
  • Linux capabilities
  • SecurityContext
  • Pod Security Standards
  • RBAC
  • NetworkPolicies
  • Secrets management
  • Admission control
  • Runtime detection
  • Monitoring and incident response

Mastering these 30 Container Security interview questions prepares you for Docker, Kubernetes, OpenShift, Amazon EKS, Azure AKS, Google GKE, DevSecOps Engineer, Platform Engineer, Cloud Engineer, Site Reliability Engineer, Security Engineer, Technical Lead, and Solution Architect interviews.