The short answer
Start from the Cloudera support matrix, read against the cluster as it is today rather than the target release. If the operating system reaches end of life while still inside a supported CDP version, the OS upgrade has to be sequenced first — ideally onto a version both releases support — with a rollback point before each step.
This is the scenario we put to data engineering candidates for Cloudera work. It looks like a version-upgrade question. It is really a sequencing question, and sequencing is where regulated upgrades go wrong.
A bank is on CDP Private Cloud Base 7.1.7 and wants to move to 7.1.9. Their OS reaches end of life inside the currently supported CDP version. What do you check, and in what order?
The trap in the question
The release jump is not the hard part. The hard part is the clause most candidates read past: the operating system reaches end of life inside the currently supported CDP version. The OS clock runs out before the platform clock does, so the upgrade cannot be planned as a single CDP event with the OS as an afterthought.
The support matrix is the authority here. It states which operating system versions each CDP release supports, and the safe path keeps the cluster on a supported OS-and-platform pairing at every step. That usually means moving the OS first, ideally onto a version both 7.1.7 and 7.1.9 support, and only then moving the platform.
What a senior answer contains
- Goes to the support matrix first, and reads it against the actual cluster rather than the target release. The question is what is supported from where you are now, not what 7.1.9 supports in the abstract.
- Spots that the OS end of life is the trap, and sequences the OS upgrade accordingly instead of discovering mid-programme that the cluster is running on an unsupported OS.
- Names what breaks in practice: Ranger policies, the Hive metastore, Spark 3 pairings and Kerberos principals. None of these surface in a release-notes skim, and each of them has stopped real upgrades.
- Asks who signs off the lineage evidence, because in a bank that sign-off gates the change — and it is a person with a calendar, not a checkbox.
Where a mid answer stops
- Starts from the CDP release notes and treats the OS as an afterthought. Release notes describe what changed. They do not tell you what your particular cluster can safely move to.
- Plans the upgrade as one window rather than a sequence with rollback points. In a regulated environment, a single big-bang window with no intermediate fallback is a risk the change board will rightly refuse.
- Has not had to produce lineage evidence for an examiner, and does not ask who will.
The wider point
Most of what goes wrong in a platform upgrade is visible before the first command runs, to someone who has done it before. That is the case for having this screen run by an engineer who does CDP upgrades inside banks, rather than by someone checking a CV for the word Cloudera.
This is the published screen for data engineers. The role page carries the scenario, the full rubric and the technologies we screen on.