Permits web nodes were patched by SSH hotspot edits, and each server now differs. Leadership wants immutable infrastructure practices instead. What change aligns with immutability?
Select an answer to reveal the explanation.
Short Explanation
Immutability means swapping in a fresh stamped brick instead of carving graffiti onto the old one. Rebuild permits nodes from a new image; do not keep SSH snowflaking production.
Full Explanation
Permits web nodes patched by unique SSH hotspot edits become snowflakes—each server drifts until leadership cannot trust any node to match another. Immutable infrastructure practice replaces nodes with new instances built from an updated image (or immutable container revision) rather than mutating live servers over SSH. Patches land in the image pipeline; rollout is replace-and-retire, which makes rollback a matter of redeploying the prior image.
Continuing unique SSH tweaks and documenting them in a wiki afterward preserves drift and guarantees the wiki lags reality. Disabling configuration management so operators can improvise freely worsens snowflakes. Marking drifted nodes as golden masters without rebuilding images freezes inconsistency as the new baseline instead of eliminating it.
Exam caveat: immutability allows break-glass SSH for forensics, but lasting fixes belong in the image/IaC path. Operational check: bake a patched image, launch new permits nodes behind the load balancer, terminate old instances, and verify configuration drift tools report no unique SSH mutations on the new set. Image pipelines should bake OS patches, app config, and agent versions together so permits nodes are replaceable units. SSH remains for break-glass diagnosis, not for permanent configuration.