SY0-701 Question 47
Single answerBlockchain: Open public ledgerA security architect is evaluating whether to use a public blockchain to store evidence that software updates were approved and released without tampering. Management wants any customer or auditor to be able to independently verify the release history, but the company must avoid exposing confidential internal data. Which approach best meets these requirements while using the security benefits of an open public ledger?
- A
Store the full software packages, employee names, and approval records directly on the public blockchain so the data cannot be changed later
- B
Publish cryptographic hashes of the approved release artifacts and approval records to the public blockchain, while keeping the actual files and sensitive details in an internal repository
- C
Use the public blockchain as a private database by encrypting all records with a shared company key and allowing customers to decrypt them for verification
- D
Rely on the public blockchain to keep release information confidential because only authorized nodes can read blocks on an open public ledger
Show answer and explanation
Correct answer: B
Explanation
The best answer is to store cryptographic hashes on the public blockchain and keep sensitive content off-chain. In Security+ terms, an open public ledger provides integrity, non-repudiation support, transparency, and tamper evidence through distributed consensus and immutable recordkeeping, but it does not provide confidentiality for data written directly to the chain. A common best practice is to anchor hashes, timestamps, or transaction proofs on-chain while retaining the original records in secured internal storage. This allows auditors or customers to independently recompute the hash of a provided artifact and compare it to the public ledger entry to verify that the item has not been altered. This aligns with general security guidance around data minimization, least exposure of sensitive information, and the appropriate use of hashing for integrity verification.
- A. Incorrect.
This is incorrect because a public blockchain is transparent by design. Storing full software packages, names, or detailed approval records on-chain would expose sensitive information permanently to anyone who can read the ledger. While immutability is useful, public blockchains are not appropriate for placing confidential business data directly on-chain.
- B. Correct.
This is correct because it uses the public blockchain for what it does well: providing an open, tamper-evident ledger that anyone can independently verify. By placing only cryptographic hashes on-chain, the company can prove integrity and timestamping of the release artifacts and approval records without revealing the underlying confidential data. The actual packages and records remain off-chain in controlled internal systems.
- C. Incorrect.
This is incorrect because although encryption can protect content, using a shared company key undermines secure key management and does not make the blockchain private. It also creates operational and trust issues for external verification. Customers cannot independently validate records unless key-sharing and access control are carefully managed, which defeats the goal of simple public verification through an open ledger.
- D. Incorrect.
This is incorrect because an open public ledger is readable by the public. Public blockchains provide integrity, transparency, and distributed verification, not confidentiality. The misconception here is confusing authorization on private or permissioned ledgers with open public blockchains, where data visibility is broadly available.