IBM DevOps Engineer interview questions

Five stages, and which one you are stuck in tells you what to fix. A machine that reaches a GRUB prompt has a different problem from one that hangs waiting on a filesystem that no longer exists.

Everyone recites the four letters. The scoring answer walks each packet across the wire and knows the places the exchange silently dies.

A routine cloud operation with three layers that can quietly disagree. The strong answer is an ordered procedure you could run during business hours, without a reboot.

Most hand-written units boot in dev and die in production. The gap is Type selection, restart policy, and the drop-in workflow vendors expect you to respect.

Enterprise loops pair these topics because they test L2 literacy plus vendor coordination together. The scored insight is that LACP spreads flows, not packets, and needs the switch to agree.

Sets instead of thousand-rule chains, one engine for both IP families, atomic ruleset swaps, and a compatibility shim with sharp edges. Migration risk lives in coexistence and tooling assumptions, not syntax.

Volatile by default on many distros, size-capped by silent policy, binary on disk. Know the storage modes, the vacuum knobs, and how journald feeds central logging.

The services-and-enterprise interview staple. There is a defensible answer and it is not 'always re-platform': the decision is a function of change tolerance, deadline reality and what the workload is worth.

Allow-listing egress starts free with security groups and ends with TLS-breaking appliances. Each rung costs latency, money and political capital, and knowing where to stop is the actual test.

Four options with genuinely different costs, and the requirement is usually narrower than it first sounds. Establish whether it is about the network path, the data residency, or the provider's retention terms, because those need different answers.

It copies a small Python program to the target over SSH, runs it, and deletes it. Once that is clear, the agentless claim, the performance characteristics and the idempotency requirement all stop being separate topics.

A staple of services-company interviews, and the boring answer (provisioning versus configuration) is only half of it. The useful half is what happens when you push either tool past its model.

The question that finds out whether someone writes playbooks or writes shell scripts wrapped in YAML. Idempotence is a property of the module you chose, not of Ansible.

The services-market question that decides who can actually run a migration. Import is the easy part; the hard parts are resource-for-resource fidelity and proving the first plan is empty.

Static INI files die somewhere near two hundred hosts. Point inventory plugins at the systems that already know the truth, derive groups from tags with constructed inventory, and plan for stale hosts before they page you.

Vault's weakness is the single shared password, not the AES256 underneath. The senior answer covers rekey ceremonies on offboarding, encrypt_string for readable diffs, labelled vault-ids per environment, and shrinking what needs encrypting at all.

OpenTofu is the Linux Foundation fork of Terraform 1.5 under MPL, drop-in compatible for most code, with distinct features such as native state encryption. Removed blocks and provider mocking also exist in Terraform. Portability survives by pinning version floors and testing both binaries in CI.

Terraform shapes the world; images define what boots inside it. Bake contents into versioned artifacts on a patch cadence, roll fleets by replacement, and keep user_data for identity and wiring only.

A VM virtualises hardware and boots its own kernel. A container is a process on the host kernel with its view of the world restricted. Everything else, including the security answer, follows from that one difference.

It is Kubernetes with an opinion, and the opinion that catches everyone is that containers do not run as root. A manifest that works on vanilla Kubernetes and fails here usually fails for exactly that reason.

Rootless is the rare security control with a visible invoice. Compare its effective resource controls, storage behaviour and remaining host-user access.

Provisioning is a four-actor handshake between the PV controller, a sidecar, a driver and a backend. Knowing who calls whom turns every stuck PVC from mystery into checklist.

Yes, the proxy moves: one L4 agent per node, eBPF in-kernel, waypoints only where L7 policy demands. The scored answer quantifies the sidecar bill, compares where each architecture lands the proxy, and names migration risks.

Jenkins is mostly plugins, they have a dependency graph nobody drew, and the controller is a single point of failure for every team. The answer is a rehearsal against a copy of production, not a maintenance window and hope.

Distinguish executor capacity, placement and provisioning failures, then size an agent pool from measured resource use and cleanup behaviour.

Three places, and which one depends on how the thing was started. Knowing which logs the runtime collects and which the application writes itself, and that journald may not persist across reboots, saves the first twenty minutes.

Emergency mode after a storage change is usually one line in fstab. The order of operations is what decides the outcome here, along with whether the recovery preserves data-mount dependencies rather than booting past them.

This one separates people who read journals from people who restart harder. The exit code and signal systemd already recorded usually name the disease.

NFS waits can stall shutdown and inflate load average while CPUs stay idle. Check the blocked kernel path before deciding whether signals or mount recovery can release it.

The backup is doing its job and the database is paying for it. Attribution first, then enforcement that actually binds on modern kernels, because priority support depends on the active kernel and IO scheduler.

Duplicate-IP claims need evidence, and one command provides it. Then the real skill: telling a genuine two-owner clash apart from ARP flux, because the fixes could not be more different.

Stateful firewalls keep established flows alive after their rule vanishes, so cleanup day passes every check and lag appears days later. Flow logs name the hour; inventories prevent the repeat.

Two commands disagreeing is the diagnosis, not the mystery. A deleted file with an open handle is invisible to du and fully charged by df, and rm made it worse rather than better.

The honest answer splits traffic containment from access control. Flat yes or no loses points here; the condition under which segmentation stops being theatre is what the interviewer wants.

Experienced answers are ordered and verifiable: minimal base, benchmark applied as code, identity and exposure next, then continuous proof it stayed that way. Checklists recited out of order are the tell.

This is a platform-organization question disguised as infrastructure. Score comes from separating enforcement from ownership and explaining what stops the gateway becoming a smart ESB.

The auditor does not require a meeting, they require evidence that changes are authorised, tested and reversible. Generate that evidence from the pipeline and the board stops being the bottleneck.

An untested backup is a belief, not a control. The design that matters is the one that restores automatically on a schedule and verifies the result, because that is the only thing that produces a recovery time you can quote.

Most tagging initiatives are spring cleans that rot within two quarters. The durable answer treats the schema like an API contract enforced where resources are born, and knows which lever actually wins.

A model artifact is code that runs in your cluster with GPU access. Most of the supply-chain controls you already run for containers apply, and the file format adds one of its own.

Most of the obligation lands on the product, but three parts land on infrastructure: an inventory of what is deployed, evidence of what it did, and the ability to turn it off. Those are platform capabilities and they take months to retrofit.

Build a first-ninety-day plan from service risk and observed work, with safe shadowing, tested runbooks and one measurable operating improvement.

Reduce a critical knowledge dependency with funded transfer work, tested operating documentation and demonstrated backup capability, without inventing personal motives.

Assess a signed vendor choice against the actual requirements and contract, then support a bounded implementation or raise material new evidence through its owners.

Multi-AZ is the answer and the reason matters more than the acronym. Each tier fails differently, and the database is the one where high availability means a failover with a real gap, not zero interruption.

The question that separates people who have debugged a hung rollout from people who have read about one. The interesting half is not the signal, it is PID 1.

One is layer 4 and regional, one is layer 7 and regional, one is layer 7 and global. Answer on those two axes and the choice makes itself, including when you need two of them together.

Ordering and retransmission are what TCP adds, and both of them cost time. Naming something that deliberately gives them up, and saying why, is what turns a textbook answer into a real one.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

A staple of every networking round, and the follow-up is always about TLS termination. Knowing which layer sees what decides most of the answer.

The oldest question in systems interviewing and still the best, because it is unbounded: every layer you can describe is another layer you could debug.