If you are studying for the Professional Cloud Architect exam, you will see questions about how to make logs verifiably tamper-evident. The answer almost always involves a digital signature or a cryptographic hash, and the architectural decision is where you store that hash relative to the log itself.
This article walks through how Public Key Infrastructure and digital signatures work, how that mechanism is applied to log integrity, and the storage decision that the PCA exam likes to test.
Public Key Infrastructure is the system that manages public and private key pairs. Every key pair has two halves. The private key stays with its owner. The public key gets distributed.
Digital signatures are built on asymmetric cryptography, which is just a fancy way of saying that the two keys do different jobs. The private key is used to create a signature. The public key is used to verify that signature. You cannot derive the private key from the public key, which is what makes the whole system work.
The signing process for a log entry has three steps.
First, you compute a cryptographic hash of the log data. SHA-256 is the standard choice. A hash is a fixed-length fingerprint of the input. Change a single character in the input and the hash comes out completely different.
Second, you encrypt that hash with the sender's private key. The encrypted hash is the digital signature.
Third, you store the signature alongside the original log entry.
Verification reverses the process. You recompute the hash of the log data as it sits today. You decrypt the attached signature using the corresponding public key, which gives you the hash that was signed at write time. Then you compare. If the two hashes match, the log has not been altered. If they differ, something changed after the log was signed.
This is what people mean when they say a log is tamper-evident. You cannot prevent someone from modifying a log entry, but you can guarantee that any modification will be detected.
This is the part the Professional Cloud Architect exam will test. There are two options for where the hash lives, and each suits a different threat model.
Storing the hash alongside the log is the simpler option. The log entry and its signature sit together in the same record or the same file. Verification is fast and self-contained. This works when the storage system itself is trusted, for example an append-only ledger or a write-once tamper-proof storage system. If the storage layer cannot be modified by an attacker, then keeping the hash next to the log is fine.
Storing the hash separately is the option you reach for when the threat model assumes the log storage system itself can be compromised. The classic example is an attacker who gains database access. If the hash sits in the same database as the log, that attacker can modify the log entry and recompute a fresh hash to match. The tampering becomes invisible.
By storing the hash in a separate location, a different service, a different database, or a hardware security module, you force the attacker to compromise two systems instead of one. Verification requires reading from both locations, but that extra step is the entire point. Even if the log database is breached, the hashes in the separate store still represent the original signed values, and the mismatch will surface during verification.
The exam will frame this as a compliance or financial logging problem. The setup goes something like this. A company handles sensitive financial transaction logs. They need every log entry to be verifiable, even against an insider with database access. What approach do you take?
The correct answer is to apply a cryptographic hash to each log entry and store the hash separately. The reasoning chain has three parts. The hash detects any change to the log entry. Storing it separately prevents the attacker from tampering with both the log and its verification data in a single compromise. Together, these two properties give you tamper evidence that satisfies audit and compliance requirements.
The wrong answers usually look reasonable on the surface. An encrypted, read-only Cloud Storage bucket sounds secure, but read-only access controls do not give you a way to verify integrity if someone with the right permissions still alters the data. Synchronizing logs across regions improves redundancy and disaster recovery, but a tampered log replicated to three regions is still a tampered log in three regions. Writing logs to both a SQL database and an on-premises server improves availability, but an attacker with credentials to both can modify both.
The pattern the exam wants you to recognize is that integrity is a different problem from confidentiality, availability, or access control. Hashing plus separation of storage is the architectural answer.
On Google Cloud, you would typically use Cloud KMS to manage the asymmetric keys for signing. The private key lives inside KMS and never leaves it. Your application calls the KMS asymmetric sign API to produce a signature, which means the signing happens inside Google's hardware-backed key store rather than in your application memory.
For separated storage, the hash or signature can live in a different Cloud Storage bucket with stricter access controls, in a separate database, or in another KMS-protected location. The point is administrative separation, not just physical separation. The identity that can write logs should not be the same identity that can write to the hash store.
For high-assurance scenarios, Cloud HSM gives you FIPS 140-2 Level 3 hardware-backed key storage, which is the same idea as KMS but with a stronger compliance posture for regulated industries.
My Professional Cloud Architect course covers PKI and log integrity alongside the rest of the architecture and compliance material.
