Hermes Wiki
Synthesis/pki-fundamentals-note-names-the-acm-vs-cloudhsm-exam-decision-rule

Synthesis: The PKI Fundamentals Note Supplies the "Why" Behind SAA-C03's ACM-vs-CloudHSM Decision Rule

The connection

Public Key Infrastructure (PKI) and Certificate Management (new this window) draws a trust-scope distinction that reads as pure vendor-neutral theory: a public CA is "trusted by any browser/OS by default... low operational cost, automated issuance," while a private/internal CA is "trusted only where you've distributed the root... higher operational cost, you own root key custody." The note's tradeoff table frames this as the deep design choice underneath any certificate strategy.

AWS Scope — Security, Identity, and Compliance names the exact same distinction as a scored exam decision rule, just with AWS's product names substituted in: AWS Certificate Manager (ACM) "lets you easily provision, manage, and deploy public and private SSL/TLS certificates," and the note's own project examples split cleanly along the Fundamentals note's trust-scope axis — "securing an e-commerce website with a public SSL certificate" (public CA, low-friction, ACM's default path) versus "managing a private Certificate Authority (CA) for internal microservice encryption" (private CA, the mTLS-between-services case the Fundamentals note calls out as the point where standing up internal PKI becomes worth doing).

The same Security-domain file goes one level deeper with an "exam-critical distinction" between AWS CloudHSM (single-tenant, FIPS 140-2 Level 3, customer controls the hardware) and AWS KMS with Customer Managed Keys (multi-tenant, easier, lower-effort) — a root-key-custody question that is precisely what the Fundamentals note's Principal Engineer Lens calls the question that "separates a surface-level PKI conversation from a Principal-level one": "who holds the private key for the root, how is it protected, and what's the blast radius if it's compromised?"

Why this wasn't visible before

The Fundamentals note is vendor-neutral by design and never mentions ACM, CloudHSM, or KMS by name — it cites HashiCorp Vault's PKI engine and step-ca as its internal-CA examples. The CertExams Security file, in turn, presents ACM/CloudHSM/KMS as three separate exam-scored services with their own "Common Usage" bullets, never stating the underlying trust-scope or root-custody principle that makes the AWS exam's own "decision rule" make sense rather than feel like rote memorization. Each file independently arrived at the same organizing question — public vs. private trust scope, and who custodies the root key — without citing the other.

What this suggests

  • The CloudHSM-vs-KMS "exam-critical distinction" is not an isolated AWS trivia fact — it's the Fundamentals note's root-custody question applied to one specific vendor's two managed-key products. Recognizing this turns a memorized decision rule ("dedicated hardware → CloudHSM, shared is fine → KMS") into a transferable judgment call that will resurface for any cloud vendor, not just AWS.
  • Worth a one-line cross-link from the PKI Fundamentals note to AWS_Scope/14_Security.md and vice versa — this is a case where the exam material is a live, scored instance of the vendor-neutral framing, not just a tangentially related topic, and the two currently have zero mutual references.
  • The same trust-scope axis (public/automated vs. private/self-custodied) recurs in AWS Directory Service (managed AD vs. self-hosted Samba/FreeIPA) and AWS KMS vs. AWS CloudHSM more broadly — a pattern worth watching for across the rest of the Security domain's Tools stubs as more get added.
Hermes Wiki