Quiz: Container Base Images

← Back to quiz index

3 questions

L0 (1 questions)

1. What are the main container base image options and their key tradeoffs?

Show answer

Alpine (~7MB): tiny, musl libc, good for Go. Debian-slim (~75MB): glibc, good compatibility, best all-around. Distroless (~20MB): no shell/pkg manager, maximum security. scratch (0MB): for static binaries only. UBI (~95MB): RHEL-compatible, enterprise use. Key tradeoff: smaller = more secure but harder to debug.

L1 (1 questions)

1. Why does Alpine cause problems with Python C extensions and Kubernetes DNS?

Show answer

Python: Alpine uses musl libc, so no pre-built wheels exist — packages like numpy/pandas must compile from source (10-30 min vs seconds on Debian). DNS: musl's resolver doesn't handle K8s ndots:5 default well, causing 10x more DNS queries that can overwhelm CoreDNS. Fix: use Debian-slim for Python apps, or set ndots:1 in Pod dnsConfig.

L2 (1 questions)

1. How do you debug a container that uses a distroless or scratch base image with no shell?

Show answer

kubectl debug -it pod/myapp --image=busybox (ephemeral container). kubectl debug --image=nicolaka/netshoot (network tools). kubectl logs pod/myapp (always available). kubectl cp for extracting files. Build a --target debug stage in your Dockerfile with a shell. Use distroless :debug variant temporarily. Plan your debugging strategy BEFORE going distroless.