Docker vs Terraform Interview Questions: Containers vs Infrastructure as Code

Docker's Dockerfile best practices recommend COPY for plain file copies because its behaviour is transparent: it only copies local files/directories from the build context. ADD does extra implicit work — it can download remote URLs and will auto-extract local tar archives — which makes builds less predictable and can mask surprises. Both preserve permissions and both handle single files. Reaching for ADD 'just in case' is the misconception; use ADD only when you specifically want local-archive auto-extraction.

State is Terraform's record of which real object (an AWS instance id, a bucket ARN) corresponds to each resource address in your config. Without it Terraform couldn't tell what already exists, so it couldn't compute a diff or know what to update or destroy. Credentials are supplied by the provider config/environment, the desired state is your .tf files, and plugins are cached under .terraform/. Losing or corrupting state is what makes Terraform try to recreate or orphan live infrastructure.

EXPOSE is documentation/metadata: it records which port the app listens on but never publishes anything. To let host traffic reach the container you publish the port with -p 8080:8080 (or auto-publish all exposed ports with -P). You don't even need EXPOSE to publish — -p works regardless. The trap is assuming EXPOSE opens the port; teams hit this when a 'working' image is unreachable in production because nobody published the port.

create_before_destroy, prevent_destroy, and ignore_changes (plus replace_triggered_by) are the lifecycle meta-arguments: they tune replacement order, block destroys, and tell Terraform to ignore drift on chosen attributes. depends_on is a meta-argument too, but it sits at the resource level, not inside lifecycle — putting it there is a common authoring error. Knowing what lifecycle controls is what lets you do a zero-downtime replacement or stop an external autoscaler's changes from showing up as perpetual drift.

With exec form, your process is launched directly and becomes PID 1, so it receives signals (notably the SIGTERM docker stop sends) and can drain connections and exit cleanly. Shell form runs /bin/sh -c "node server.js", making the shell PID 1; the shell frequently doesn't forward SIGTERM to its child, so docker stop hangs for 10s and then SIGKILLs — abrupt termination, dropped requests. Shell form does pass args and isn't slower; it just breaks signal handling. This is the classic 'my container takes 10 seconds to stop' bug.

False. sensitive = true only redacts the value from CLI plan/apply output (it shows as <sensitive>); the value is still written to state in plaintext, and terraform output -json/-raw will print it. Anyone who can read the state file can read the secret. To keep a value out of state entirely you use an ephemeral output (Terraform 1.10+). Believing sensitive encrypts state is a dangerous assumption — protect state with backend encryption and access controls instead.

docker run <image> creates a brand-new container from an image and starts its main process. docker exec <container> <cmd> runs an additional command inside a container that is already running — the target must exist and be running, so you can't exec into a stopped or nonexistent container. You use exec for debugging (docker exec -it web sh) without disturbing the main process. Confusing the two leads people to spin up a fresh container when they meant to inspect a live one.

merge combines maps left to right, and when the same key appears more than once the value from the later argument wins. So env from overrides (prod) overrides env from defaults (dev), while team is carried through unchanged. Duplicate keys across arguments are not an error — last-wins is the whole point. This precedence is the standard pattern for a base tag/config map overridden per environment; getting the argument order backwards silently applies the wrong values.

An image is a stack of read-only layers. Starting a container adds a thin writable layer on top (copy-on-write): all changes the container makes live only there. Removing the container deletes that writable layer, so the file is gone, and the image's layers were never modified — a new container starts clean. Writes are never committed back to the image automatically, and each container gets its own writable layer (they aren't shared). This is exactly why durable data must go in a volume or bind mount, not the container filesystem.

Line 7 makes the resource depend on its own computed id, which doesn't exist until the resource is created — a dependency cycle Terraform's graph rejects. To allow a security group to reference itself you set self = true on the rule instead of listing its own id. name is settable, inline ingress blocks are valid (a separate aws_security_group_rule is just an alternative), and protocol = "tcp" is correct. Self-reference cycles are a classic Terraform graph error that the message can make cryptic.

ARG and ENV values are baked into image metadata and are recoverable with docker history --no-trunc (and ENV also persists into every running container's environment). Writing the secret then rm-ing it in a later layer doesn't help: each layer is immutable and retained, so the earlier layer still contains the file even though the final filesystem hides it — anyone can extract it from the layer. The only safe option is a BuildKit secret mount (RUN --mount=type=secret), which exposes the secret to a single RUN and never writes it to any layer. Believing a later rm 'deletes' a secret is the most dangerous misconception here.

The two big wins are a single shared source of truth (no divergent laptop copies) and state locking to prevent concurrent applies from corrupting state. Strong answers also mention durability/versioning and that state holds secrets in plaintext, so a remote backend with encryption and access control is a security improvement too. This is the question that separates someone who has run Terraform solo from someone who has run it on a team.