Exercise 3: Why Personal Distro Preference Shouldn't Drive a Production Support Decision — Possible Solution ==================================================================== WHAT THE ADMINISTRATOR'S REASONING WOULD BE ------------------------------ Choosing Arch for the new production server based on personal desktop familiarity would mean prioritizing "which distribution do I already know how to use best" over "which distribution actually satisfies this server's own real requirements." WHY THIS CHAPTER NAMES THIS EXACT REASONING AS A MISTAKE ------------------------------ Per this chapter's own warn-box, "choosing a distribution based purely on personal familiarity, without weighing the task's own actual requirements, is a real and common mistake - someone genuinely comfortable running Arch on their own desktop can still be choosing badly by reflexively deploying it to a production server that actually needs RHEL's own support SLA." This is precisely the scenario in the exercise - personal comfort with Arch doesn't change what the actual job (a server needing a vendor support contract) genuinely requires. WHAT THE JOB ITSELF ACTUALLY REQUIRES, PER THIS CHAPTER'S OWN TABLE ------------------------------ Per this chapter's own table, "enterprise server needing vendor SLA/compliance certification" maps to RHEL specifically, because "commercial support, certification, and a decade-long support window are the actual requirement." Arch has no vendor to call for a support contract, no certification program, and (per Chapter 9) no commercial backing at all - it structurally cannot satisfy a requirement for a vendor SLA, regardless of how well the administrator personally knows how to run it. WHY THIS IS A CATEGORY MISMATCH, NOT JUST A SUBOPTIMAL CHOICE ------------------------------ This isn't a case of Arch being merely a weaker choice than RHEL for this task - it's a case of Arch being structurally incapable of providing something the task explicitly requires (a vendor support contract), the same way a hardware constraint made only Raspberry Pi OS viable in this chapter's own Pi scenario. No amount of personal skill with Arch changes the fact that it has no vendor backing to offer. WHY THIS WORKS AS AN ANSWER ------------------------------ It names the specific reasoning error using this chapter's own warn-box verbatim, restates what the task genuinely requires per this chapter's own table, and explains why the mismatch is structural (Arch cannot provide a vendor SLA at all) rather than merely a matter of the administrator's own preference being suboptimal.