A validated application is certified only against Red Hat Enterprise Linux 9.4, and the vendor will not support any other minor release. How does RHEL's release lifecycle let you hold a fleet on one minor release, and what do you give up by doing it?

## The shape of the lifecycle A RHEL major release is a decade-long commitment. Broadly, the first years are Full Support, where new hardware enablement and selected feature work still land; the remainder is Maintenance Support, where the content narrows toward security and critical bug fixes; at the very end, an Extended Life Cycle Support add-on can buy more time for stragglers. The precise boundaries move between majors, so quote the shape rather than dates you half-remember. Inside that decade, minor releases arrive on roughly a six-month cadence: 9.0, 9.1, 9.2 and so on. A minor release is not a new operating system — the ABI is stable across the major, so binaries keep working — but it does refresh package versions, sometimes changes defaults, and occasionally deprecates something. That is precisely why an ISV certifies against one. ## Following latest versus pinning By default a registered host resolves content for the newest minor of its major version, so a routine update run in the week after 9.5 ships will move the host to 9.5. For a certified workload, that is an uncontrolled change. Pinning is a per-host setting on the subscription client: ``` sudo subscription-manager release --set=9.4 sudo subscription-manager release --show ``` This fixes the release version used to build repository URLs, so the host draws from the 9.4 content path and will not roll forward on the next update run. `subscription-manager release --unset` returns it to following latest. ## The trap: a pinned ordinary minor is a dead end The part candidates miss is what happens to a minor release's content after the next one appears. For an ordinary minor, the answer is: nothing more arrives. Fixes are published into the current minor. A host pinned to a superseded ordinary minor keeps working, keeps reporting itself as fully updated, and quietly accumulates unpatched vulnerabilities — the worst failure mode, because monitoring says everything is fine. Extended Update Support exists for exactly this case. EUS is a separate entitlement covering selected minor releases — in the RHEL 8 and 9 policy, the even-numbered ones — and it continues to publish security and critical fixes into that minor for roughly two years past its release. That converts a pin from "frozen and rotting" into "supported and stationary". Because 9.4 is an even-numbered minor, it is a plausible EUS target; a vendor demanding certification against an odd-numbered minor is asking for something the lifecycle does not support well, and that is worth pushing back on. There are further specialised streams for particular workloads — extended support tailored to certain platform partnerships — but the interview point is the pattern: some minors are designated as long-lived, most are not. ## Operating a pinned fleet - **Set the pin as part of provisioning**, not as a remediation after a host drifts. It is host state, so it belongs in the build automation and in configuration drift checks. - **Verify the entitlement, not just the pin.** A pin without the matching EUS entitlement is the failure mode described above. Alert on hosts whose release lock names a minor that is no longer receiving errata. - **Budget the exit.** EUS is time-boxed, so the pin has an expiry date the day you set it. Put the move to the next EUS minor on the roadmap immediately, with the vendor's recertification timeline attached to it. - **Keep an unpinned canary.** One host following latest gives you early warning of what the next minor changes for your workload, so the eventual jump is not a surprise. - **Know the reverse constraint:** you cannot go backwards. Pinning to an older minor than the one already installed does not downgrade the machine; it merely limits what it will see next. Recovering a host that jumped a minor by accident means rebuilding it. ## Why interviewers ask this It separates people who have run a regulated fleet from people who have run laptops. The naive answer — "just don't run updates" — produces the same frozen state with none of the visibility, and fails an audit immediately. The mature answer treats the certified minor as a supported resting place with a known end date, and plans the fleet's movement between such resting places as an ongoing programme rather than an emergency.