Home / Containers / containerd Deep Dive / Interview Questions

containerd Interview Questions

Basic to Advanced Scenario-Based 25+ Questions

Ace your container runtime interview with this comprehensive Q&A guide covering containerd architecture, CRI, troubleshooting, performance, and real-world scenarios with detailed explanations for each answer.

25+ Questions Basic to Expert Detailed Explanations
8
Basic Questions
8
Intermediate Questions
6
Advanced Questions
5
Scenario-Based Questions
Basic Level Questions

These questions test fundamental understanding of containerd and container runtimes. They're typically asked in junior or mid-level interviews.

Q1: What is containerd and why is it important in the container ecosystem? Basic

Answer: containerd is an industry-standard container runtime that manages the complete container lifecycle. It was originally built by Docker and donated to the CNCF, where it became a graduated project. It's responsible for pulling images, creating and starting containers, managing storage, and handling container lifecycle operations.

Why it matters: containerd is the default runtime for Kubernetes, Docker, and most major container platforms. Understanding it is essential for any container engineer. Its modular architecture and CRI compliance make it the backbone of modern container infrastructure.
Q2: What is the CRI (Container Runtime Interface) and how does containerd implement it? Basic

Answer: CRI is a Kubernetes API that defines how kubelet interacts with container runtimes. containerd implements CRI through the io.containerd.grpc.v1.cri plugin, which translates Kubernetes pod and container requests into containerd operations.

Key insight: The CRI plugin is the bridge between Kubernetes and containerd. It handles pod sandbox creation, container lifecycle, image management, and health checks. Without the CRI plugin, containerd can still run containers but wouldn't integrate with Kubernetes.
Q3: What are the main components of containerd's architecture? Basic

Answer: containerd has a modular architecture with these main components:

  • GRPC Server: Handles API requests from clients
  • Content Store: Manages OCI image blobs
  • Snapshotter: Manages filesystem snapshots (overlayfs, etc.)
  • Metadata Store: Tracks image and container metadata
  • Runtime: Executes containers (runc by default)
  • CRI Plugin: Kubernetes integration
Why this matters: Understanding the architecture helps with troubleshooting and configuration. Each component has specific responsibilities, and issues can often be isolated to a particular component based on the error message.
Q4: What's the difference between containerd, Docker, and runc? Basic

Answer: They operate at different layers of the container stack:

  • runc: The low-level OCI runtime that actually creates and runs containers using Linux kernel features (namespaces, cgroups).
  • containerd: A high-level runtime that manages the complete container lifecycle, including image pulling, storage, and runtime execution. It uses runc under the hood.
  • Docker: A complete container platform that includes containerd as its runtime, plus additional tools for building images, networking, and orchestration.
Analogy: Think of runc as the engine, containerd as the car chassis, and Docker as the entire vehicle with steering wheel, seats, and entertainment system. Kubernetes uses containerd without the Docker extras.
Q5: What is the pause image in containerd and why is it needed? Basic

Answer: The pause image is a minimal container that holds the network namespace for each Kubernetes pod. It's the first container started in a pod and maintains the pod's network stack while other containers are started or restarted.

Key concept: The pause container ensures the pod's network namespace persists even if application containers crash or restart. This maintains network identity (IP address) stability. The default pause image is registry.k8s.io/pause:3.9.
Q6: How do you check if containerd is running and view its logs? Basic

Answer: Use these commands:

# Check status sudo systemctl status containerd # View live logs sudo journalctl -u containerd -f # View recent logs sudo journalctl -u containerd -n 50 # Check if socket exists sudo ls -la /run/containerd/containerd.sock
Pro tip: For Kubernetes nodes, also check journalctl -u kubelet to see kubelet errors related to containerd. The combination of both logs is often needed to diagnose issues.
Q7: What are containerd namespaces and why are they used? Basic

Answer: containerd namespaces provide multi-tenancy isolation for containers, images, and snapshots. They're logical separations that allow different users or applications to use the same containerd instance without interfering with each other.

Common namespaces: default (for general use), k8s.io (for Kubernetes CRI plugin), moby (for Docker). The CRI plugin uses k8s.io namespace, which is why ctr -n k8s.io images list shows Kubernetes images.
Q8: What is the purpose of the config.toml file in containerd? Basic

Answer: config.toml is the main configuration file for containerd, located at /etc/containerd/config.toml. It controls all aspects of containerd's behavior including:

  • Logging levels and format
  • Storage paths (root and state directories)
  • CRI plugin settings (pause image, runtime selection)
  • Registry mirrors and authentication
  • Snapshotter selection (overlayfs, zfs, etc.)
  • GC schedule and behavior
Important: Always validate configuration changes with containerd config validate before restarting the service. Invalid config can prevent containerd from starting.
Intermediate Level Questions

These questions test deeper understanding of containerd operations, troubleshooting, and integration with Kubernetes. Typically asked in senior engineer interviews.

Q9: How do you troubleshoot "failed to pull image" errors in containerd? Intermediate

Answer: Follow this systematic approach:

  1. Check logs: journalctl -u containerd | grep -i "pull\|error"
  2. Verify network connectivity: curl -v https://registry-1.docker.io/v2/
  3. Check DNS resolution: nslookup registry-1.docker.io
  4. Validate credentials: Check registry auth in config.toml
  5. Test with ctr: ctr image pull --debug <image>
  6. Check disk space: df -h /var/lib/containerd
  7. Verify image exists: crane manifest <image:tag>
Common causes: Network timeouts (increase image_pull_progress_timeout), invalid credentials (check registry.auth), rate limiting (use registry mirrors), or DNS issues (check /etc/resolv.conf).
Q10: What are the different snapshot drivers supported by containerd and when would you use each? Intermediate

Answer: containerd supports multiple snapshot drivers:

  • overlayfs: Best performance, uses Linux kernel overlay filesystem. Recommended for most environments.
  • native: Copies entire layers. Poor performance, only for testing.
  • devicemapper: Legacy, uses thin provisioning. Not recommended for new deployments.
  • zfs: For ZFS filesystems. Good for ZFS users with built-in compression.
  • btrfs: For Btrfs filesystems. Good for Btrfs users with CoW features.
  • overlay: Legacy overlay, use overlayfs instead.
Recommendation: Use overlayfs unless you have specific filesystem requirements. It's the default and most performant option. Change with snapshotter = "overlayfs" in config.toml.
Q11: Explain the difference between ctr, nerdctl, and crictl. When would you use each? Intermediate

Answer: Each tool serves different purposes:

  • ctr: Native containerd CLI. Low-level debugging, direct access to containerd API. Use for troubleshooting without Kubernetes context.
  • nerdctl: Docker-compatible CLI for containerd. Use for development when you want Docker-like experience with containerd. Supports compose.
  • crictl: CRI-compatible CLI for Kubernetes. Use for debugging pods and containers on Kubernetes nodes. Works with kubelet's CRI.
Best practice: For Kubernetes debugging, always use crictl as it understands pod sandboxes and CRI concepts. For low-level containerd debugging, use ctr. For development, use nerdctl.
Q12: What is the containerd shim process and why is it important? Intermediate

Answer: The containerd shim is a lightweight process that acts as a parent for each container. It serves several critical purposes:

  • Process reaping: It reaps zombie processes from containers.
  • Independence: Allows containerd daemon to restart without affecting running containers.
  • Resource management: Maintains container state and handles I/O.
  • Communication: Provides a stable API channel between containerd and the container process.
Why it matters: Each container runs with its own shim process. This design ensures that containerd can crash or be restarted without terminating running containers—a key stability feature for production environments.
Q13: How do you configure containerd for a private registry with authentication? Intermediate

Answer: Configure registry in config.toml:

[plugins."io.containerd.grpc.v1.cri".registry] # Registry configuration [plugins."io.containerd.grpc.v1.cri".registry.mirrors."myregistry.io"] endpoint = ["https://myregistry.io"] # Auth configuration [plugins."io.containerd.grpc.v1.cri".registry.configs."myregistry.io".auth] username = "myuser" password = "mypassword" # Or use auth token [plugins."io.containerd.grpc.v1.cri".registry.configs."myregistry.io".auth] auth = "base64-encoded-credentials" # TLS configuration [plugins."io.containerd.grpc.v1.cri".registry.configs."myregistry.io".tls] insecure_skip_verify = false ca_file = "/etc/containerd/certs.d/ca.crt"
Security note: For production, use auth with base64-encoded credentials or, better yet, use Kubernetes image pull secrets mounted as files. Never hardcode credentials in config.toml for production.
Q14: What is the difference between SystemdCgroup=true and false in containerd configuration? Intermediate

Answer: SystemdCgroup controls how containerd manages cgroups:

  • true: Uses systemd to manage cgroups. Required for cgroup v2. Provides better resource management and compatibility with systemd-based systems.
  • false: Uses cgroupfs directly. Works with cgroup v1 but causes issues on cgroup v2.
Critical point: On modern Linux distributions (cgroup v2), SystemdCgroup = true is required. Without it, resource limits (CPU, memory) won't work correctly, and containers may fail to start. Always check your cgroup version with mount | grep cgroup2.
Q15: How do you debug a container that fails to start with "OCI runtime error"? Intermediate

Answer: Systematic debugging approach:

  1. Check containerd logs: journalctl -u containerd -f | grep -i oci
  2. Verify runc installation: runc --version
  3. Check cgroup configuration: SystemdCgroup = true for cgroup v2
  4. Check SELinux/AppArmor: sestatus or sudo aa-status
  5. Check system resources: Memory, disk space, inodes
  6. Test with a simple image: crictl run hello-world
  7. Enable debug logging: Set log_level = "debug"
Common OCI errors: "failed to create shim" (runc missing), "operation not permitted" (SELinux), "cannot allocate memory" (system memory pressure). Each points to different root causes.
Q16: What is containerd's garbage collection and how does it work? Intermediate

Answer: containerd's garbage collection (GC) automatically removes unused resources:

  • What it cleans: Unused snapshots, content blobs, and metadata references.
  • How it works: Uses reference counting—resources are kept if referenced by images or containers. Unreferenced resources are marked for deletion.
  • When it runs: Can be configured via plugins."io.containerd.gc.v1.scheduler" in config.toml.
  • Manual trigger: ctr image prune, ctr snapshot prune, ctr content prune.
Important: GC doesn't automatically run as frequently as you might expect. In production, it's best to combine automatic GC with scheduled manual pruning. The default GC schedule may not be aggressive enough for high-churn environments.
Advanced Level Questions

These questions test deep expertise in containerd architecture, performance tuning, and complex troubleshooting. Typically asked in senior/principal or architect interviews.

Q17: Explain the relationship between containerd, CRI, and Kubernetes kubelet. How do they interact? Advanced

Answer: The interaction flow is:

  1. kubelet receives pod specification from Kubernetes API server.
  2. kubelet sends CRI requests (CreatePodSandbox, CreateContainer, StartContainer) to containerd.
  3. CRI plugin in containerd translates CRI requests into containerd API calls.
  4. containerd manages the container lifecycle: pulls images, creates snapshots, starts runc processes.
  5. runc creates the actual container using Linux kernel features.
  6. containerd reports status back to kubelet via the CRI plugin.
Key insight: The CRI plugin acts as a translation layer. Without it, containerd is just a standalone runtime. This separation allows Kubernetes to work with any runtime that implements CRI (containerd, CRI-O, etc.) while maintaining a consistent API.
Q18: How would you design a production containerd deployment with high availability and performance? Advanced

Answer: Key considerations for production containerd:

  • Storage: Use SSD storage for /var/lib/containerd. Allocate at least 50-100GB per node.
  • Snapshotter: Use overlayfs for best performance.
  • SystemdCgroup: Set to true for cgroup v2 compatibility.
  • Logging: Set log_level to "info" (not "debug") in production. Configure log rotation.
  • Registry: Configure registry mirrors for faster image pulls and rate limit avoidance.
  • GC: Configure aggressive GC schedules or run regular cron jobs for cleanup.
  • Monitoring: Enable metrics endpoint and monitor with Prometheus. Set up alerts for disk usage, operation failures.
  • Security: Enable seccomp, AppArmor/SELinux, and rootless mode where appropriate.
Expert tip: Run containerd on dedicated nodes for performance-critical workloads. Use node affinity to isolate workloads that require guaranteed performance. Monitor the metrics endpoint for early warning signs of issues.
Q19: How do you debug "context deadline exceeded" errors in containerd? Advanced

Answer: This error indicates an operation timed out. Systematic approach:

  1. Identify the operation: Check logs to see what was timing out (image pull, container start, etc.).
  2. Image pull timeouts: Increase image_pull_progress_timeout in config.toml. Default is 5 minutes.
  3. Network issues: Check registry connectivity, DNS, and proxy settings.
  4. Resource constraints: Check if system is under memory or CPU pressure.
  5. Slow storage: Check I/O latency on /var/lib/containerd.
  6. Large images: Large images may need more time to pull. Use smaller base images.
  7. GC issues: Slow GC can cause timeouts. Check GC configuration and performance.
Advanced debugging: Use strace to trace containerd operations, and use the metrics endpoint to monitor operation durations. Look for patterns—if timeouts occur at specific times, it might indicate resource contention.
Q20: What are the performance implications of different snapshot drivers and how do you benchmark them? Advanced

Answer: Performance characteristics:

  • overlayfs: Best performance (low CPU, low I/O). Uses kernel-level overlay.
  • zfs/btrfs: Good performance, but with more CPU overhead for checksums and compression.
  • native: Poor performance (copies entire layers). Avoid in production.

Benchmarking method:

# Measure image pull time time ctr image pull docker.io/nginx:latest # Measure container start time time ctr run --rm docker.io/nginx:latest nginx-test # Measure operation performance using metrics curl http://localhost:1338/metrics | grep container_runtime_operations # Use ioping for storage performance ioping /var/lib/containerd
Expert insight: For most workloads, overlayfs is the clear winner. Only consider zfs or btrfs if you're already using those filesystems and need their features (deduplication, compression). Always benchmark with your actual workload patterns.
Q21: Explain the concept of image layers and how containerd stores them efficiently. Advanced

Answer: containerd uses a content-addressable storage system:

  • Layers: Each Dockerfile instruction creates a layer. Layers are stored as blobs in the content store.
  • Content addressing: Each blob is identified by its SHA-256 digest, enabling deduplication.
  • Sharing: Identical layers across different images are stored once, saving disk space.
  • Snapshots: Layers are mounted via the snapshot driver (overlayfs) to create the container root filesystem.
  • Lazy pulling: containerd supports lazy pulling where layers are downloaded on-demand, reducing startup time.
How it works: When you pull an image, containerd downloads each layer blob, calculates its digest, and stores it in the content store. The metadata tracks which blobs belong to which images. Snapshots then create overlay mounts combining these layers for each container.
Q22: How do you implement image signing and verification in containerd using Cosign? Advanced

Answer: Image signing workflow with Cosign:

  1. Install Cosign: Download from GitHub releases.
  2. Generate keys: cosign generate-key-pair
  3. Sign image: cosign sign --key cosign.key ghcr.io/user/image:latest
  4. Verification: cosign verify --key cosign.pub ghcr.io/user/image:latest

containerd integration:

  • Use admission controllers (ImagePolicyWebhook) to enforce verification.
  • Implement policy-as-code with Gatekeeper/OPA.
  • For manual verification, check signatures before pulling.
Advanced tip: Use keyless signing with Sigstore for production—it eliminates the need to manage private keys. Use cosign sign with OIDC identity for GitHub Actions or GitLab CI. This provides better security and auditability.
Scenario-Based Questions

These questions test practical problem-solving skills in real-world scenarios. They're commonly asked in senior-level interviews to assess hands-on experience.

Q23: Your Kubernetes nodes are reporting disk pressure. How do you identify and resolve containerd-related disk space issues? Expert

Answer: Systematic resolution approach:

  1. Diagnose:
    • df -h /var/lib/containerd - Check overall usage
    • du -sh /var/lib/containerd/* | sort -h - Find large directories
    • crictl images -v - List images with sizes
  2. Immediate actions:
    • ctr image prune --keep=5 -f - Remove unused images
    • ctr snapshot prune -f - Clean snapshots
    • ctr content prune -f - Remove orphaned blobs
  3. Prevent recurrence:
    • Configure Kubernetes image GC: --image-gc-high-threshold=85
    • Set up cron jobs for daily cleanup
    • Monitor disk usage with Prometheus alerts
Key insight: The immediate priority is to free space quickly to restore node stability. Run content prune last as it's most aggressive. For critical systems, you may need to temporarily increase the disk size or evict non-critical pods.
Q24: A container consistently fails to start with "failed to run container: operation not permitted". How do you diagnose and fix this? Expert

Answer: This is typically a security policy issue. Diagnostic approach:

  1. Check SELinux:
    • sestatus - Check if enforcing
    • setenforce 0 - Temporarily disable for testing
    • If fixed, create SELinux policy for your container
  2. Check AppArmor:
    • sudo aa-status - List loaded profiles
    • sudo aa-disable <profile> - Disable for testing
  3. Check file permissions:
    • ls -la /var/lib/containerd
    • sudo chown -R root:root /var/lib/containerd
  4. Check capabilities:
    • Review required capabilities for your container
    • Add specific capabilities if needed in config.toml
Security best practice: Instead of disabling SELinux/AppArmor permanently, create proper profiles. Use ausearch to find denied operations and audit2allow to generate SELinux policies. This maintains security while allowing your containers to run.
Q25: You need to migrate a cluster from Docker runtime to containerd. What are the key considerations and steps? Expert

Answer: Migration plan:

  1. Preparation:
    • Test containerd in staging environment first
    • Validate all applications work with containerd
    • Update Kubernetes configuration to use containerd
    • Prepare rollback plan
  2. Migration steps per node:
    • Drain node: kubectl drain <node> --ignore-daemonsets
    • Install containerd: apt-get install containerd
    • Configure containerd: Generate config.toml
    • Update kubelet: Set --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock
    • Restart kubelet and containerd
    • Uncordon: kubectl uncordon <node>
  3. Post-migration:
    • Verify pods are running
    • Monitor logs for errors
    • Remove Docker if no longer needed
Critical: The change in runtime does not require rebuilding images—both Docker and containerd use OCI images. The biggest risk is configuration differences. Test with a single node before rolling out cluster-wide. Always have a rollback plan.
Q26: How would you design a canary deployment strategy for testing containerd upgrades in a production cluster? Expert

Answer: Canary deployment strategy:

  1. Phase 1: Non-production testing
    • Test in dev and staging environments
    • Run performance benchmarks
    • Test all application workloads
  2. Phase 2: Single node canary
    • Select one node in production
    • Drain and upgrade containerd
    • Monitor for 24-48 hours
    • Watch metrics: operation latency, error rates
  3. Phase 3: Gradual rollout
    • Upgrade nodes in batches (e.g., 10% per day)
    • Monitor closely after each batch
    • Be ready to rollback if issues appear
  4. Phase 4: Full rollout
    • Complete all node upgrades
    • Monitor for 1 week before declaring success
Key metrics to monitor: Container startup time, image pull duration, error rates (failed container operations), system resource usage (CPU, memory, disk I/O). Set up automated rollback triggers if error rates exceed threshold.
Q27: Your application is experiencing high latency in container startup time. How do you diagnose and optimize with containerd? Expert

Answer: Diagnostic and optimization approach:

  1. Diagnose:
    • Measure startup time: time ctr run --rm nginx
    • Check image pull metrics: container_image_pull_duration_seconds
    • Check snapshot creation time: ctr snapshot list
  2. Optimize image pulls:
    • Use smaller base images (Alpine instead of Ubuntu)
    • Configure registry mirrors
    • Pre-pull frequently used images on nodes
    • Optimize layer order (put infrequently changing layers first)
  3. Optimize container creation:
    • Use overlayfs snapshotter (fastest)
    • Ensure SystemdCgroup=true for cgroup v2
    • Consider using containerd's lazy pulling feature
  4. System-level optimizations:
    • Use SSD storage for /var/lib/containerd
    • Increase system memory if needed
    • Optimize kubelet sync frequency
Benchmark approach: Create a baseline startup time measurement, then measure after each optimization. Focus on the biggest bottlenecks first—often image size and network latency are the main culprits. Use the metrics endpoint to track improvements.
Quick Command Reference
# Check containerd status systemctl status containerd # View logs journalctl -u containerd -f # List images ctr image ls crictl images # List containers ctr container ls crictl ps -a # Pull image ctr image pull docker.io/nginx:latest # Run container ctr run --rm docker.io/nginx:latest nginx # Prune images ctr image prune --keep=5 # Prune snapshots ctr snapshot prune # Prune content ctr content prune # Check disk usage df -h /var/lib/containerd # Validate config containerd config validate # Dump config containerd config dump
Interview Tips & FAQs
What level of containerd knowledge is expected for a DevOps role?
For DevOps/SRE roles, you should understand containerd architecture, be able to troubleshoot common issues (image pull failures, OCI errors), know how to configure containerd for Kubernetes, and be comfortable with ctr, crictl, and config.toml. Basic to intermediate questions are most common.
How should I prepare for containerd interview questions?
Hands-on practice is essential. Set up a Kubernetes cluster with containerd, practice troubleshooting, and experiment with configuration. Understand the difference between containerd, Docker, and runc. Be familiar with common errors and their solutions. Practice explaining concepts clearly.
What are the most commonly asked containerd questions?
Top questions include: What is containerd and how does it differ from Docker? How does containerd integrate with Kubernetes? How do you troubleshoot image pull failures? What are containerd namespaces? How do you configure containerd for a private registry? What is the CRI plugin?
Should I focus on containerd or Docker for interviews?
For Kubernetes-focused roles, containerd is more important (it's the default runtime). For general container roles, both are relevant. Understand that Docker uses containerd internally, so knowledge of containerd is transferable. Focus on containerd for modern container interviews.
How do I explain containerd architecture in interviews?
Start with the high-level: containerd is a daemon with a modular architecture. Mention the core components: GRPC API, content store, snapshotter, metadata store, runtime (runc), and CRI plugin. Explain how they work together to manage container lifecycle. Use a diagram if possible.
What scenario-based questions are commonly asked?
Common scenarios: Node disk pressure (how to clean up), container startup failures (how to debug), migrating from Docker to containerd, performance optimization (reducing startup time), and security issues (SELinux/AppArmor troubleshooting). Be ready to walk through your diagnostic process step by step.
Do I need to memorize containerd commands for interviews?
You should be familiar with common commands (ctr, crictl, journalctl) and their use cases. You don't need to memorize every flag, but you should know which tool to use for which task and be able to explain why you'd use it. Understanding concepts is more important than memorizing syntax.
Previous: Disk Space Cleanup Next: Production Deployment

Preparation is key. Practice these questions, set up a test environment, and you'll be well-prepared for your containerd interview. Good luck!