TL;DR: Hardening is a repeatable pipeline, not a one-time checklist. Minimal base image, CIS benchmark applied as idempotent code, attack surface closed, logs and integrity monitoring shipped, then drift detection forever, because a hardened server that silently drifts is an unhardened server with better marketing.
How to approach it
Show process sense rather than reciting items: ordering, automation and verification are what they are scoring. Say early that you bake hardened images once and let fleets inherit them, because hand-hardening individual servers is exactly how estates become inconsistent.
A strong answer
Base image first. Minimal install, no compilers, mail agents or sample apps you do not need: every package is attack surface plus patch load. Prefer immutable images built in a pipeline, Packer producing an AMI or a golden template, so each reviewed image revision carries the baseline. Rebuild for patches and configuration changes, not only major OS upgrades. Hand-managed servers can be scanned and verified, but reproducing their configuration is harder.
Apply a recognised benchmark instead of inventing your own: the CIS benchmark for the distribution, executed as Ansible roles or equivalent idempotent configuration management so it is repeatable and reviewable in git. Scan with OpenSCAP or CIS-CAT to prove it landed. Expect deviations: aggressive audit rules or restrictive umasks break some applications, so maintain a documented deviation list per application family with reasons and compensating controls. Real fleets carry a handful of deliberate deviations, not zero.
The items that matter most, roughly in priority order: SSH daemon locked down, password authentication off, root login off, algorithms restricted, admin through named accounts plus sudo with logging. Firewall default-deny inbound with only the application's ports open, nftables or security groups depending on platform. Time synchronisation enabled, since every log correlation depends on it. Auditd rules and system logs shipping to centralised storage with retention matching your compliance regime. File integrity monitoring via AIDE, baselined after final configuration. Kernel sysctls tuned: reverse-path filtering appropriate for the routing topology, SYN cookies and forwarding off unless required. Strict reverse-path filtering can break asymmetric routing. Keep SELinux/AppArmor enforcing with reviewed policy, and prefer short-lived SSH certificates or brokered access over unmanaged keys. Linux reverse-path filtering documents strict and loose modes.
Then the part candidates skip: keeping it true. Patch cadence with SLAs, critical CVEs measured in days and routine ones in weeks, an agreed reboot strategy of rolling reboots or livepatch for kernels, and drift detection comparing live state against managed state with alarms on out-of-band changes. Hardening at provisioning without drift control means the fleet decays quietly toward the mean.
What interviewers probe next
"How do you keep 2,000 servers consistent?" Golden images plus config management plus drift alarms. Never fix servers individually; fix the pipeline and roll the fix out.
"A CIS rule breaks the application. Now what?" Deviation with named owner, reason, compensating control and review date, tracked beside the role in the repo. Silent local edits are the failure mode this process exists to prevent.
"Containers versus VMs here?" Harden the node once and treat containers as ephemeral application sandboxes. The kernel and kubelet are the durable surface; container images get their own pipeline checks.
Common mistakes
Reciting a flat checklist with no order, no automation story and no verification, which reads as never having operated a fleet.
Hardening during provisioning only. Six months later SSH config has been hand-edited on forty boxes and nobody knows which ones.
Disabling logging or agents over unmeasured performance fears, then failing an incident investigation because the records never existed.