Trace encrypted data and key dependencies, then test classification, location, and destruction claims against evidence.
50 min 165 XPSkills: Envelope encryption, Key lifecycle, Data location
Brief
Halcyon Clinics stores 80,000 patient exports in object storage. A release manager calls the system compliant because its public endpoint uses TLS. During a restore drill, an analyst discovers that a backup copy is outside the approved jurisdiction and that the only key capable of decrypting it is scheduled for deletion tomorrow. Neither problem appears on the endpoint certificate.
Your job is to separate transport protection, storage protection, key availability, and legal location. Follow one restricted export from upload to backup and restore: identify who can decrypt it, which key version it needs, where every copy travels, and what evidence proves those controls operated. A single encryption-enabled setting cannot answer all four questions.
Encryption limits disclosure under specific threats; it does not establish lawful processing, correct access, or recoverability by itself.
Protect each storage state and transport hop
Encryption at rest protects stored representations such as object bodies, database files, snapshots, and backup media. It does not normally stop an authorized application from returning plaintext. If a stolen application identity can read an object and invoke the necessary decryption operation, disk encryption alone does not prevent disclosure. Inventory copies and temporary exports rather than checking only the primary storage service.
Encryption in transit protects a connection between endpoints. Require TLS 1.2 or later with certificate chain and hostname validation, and prefer TLS 1.3 where supported. A gateway that terminates TLS creates a new trust boundary: a second connection from gateway to application needs its own protection. A valid public certificate says nothing about whether that second hop is plaintext or whether the endpoint is authorized to return a record.
For a confidentiality control, collect effective storage settings, a test that rejects an unencrypted request, certificate-validation results, and a connection map covering internal hops. An auditor can select a backup or an internal connection and ask for its actual configuration; a screenshot of the public listener covers neither population.
Envelope encryption separates bulk data from key custody
In envelope encryption, a data encryption key, or data key, encrypts the payload, while a key encryption key wraps that data key. For example, a fresh 256-bit data key can protect one export using an authenticated encryption mode. The application stores ciphertext, the wrapped data key, the wrapping-key identifier and version, and required nonce and authentication metadata. A nonce must obey the chosen mode's uniqueness rules; it is not a password or a replacement for the key.
A key management service authorizes and records operations such as generating, wrapping, and unwrapping keys. On a read, the authorized workload submits the wrapped data key, obtains or uses its plaintext form under the service's design, and decrypts the payload. Plaintext data keys must not enter logs or persistent configuration; limit their lifetime in memory. A customer-managed key gives the customer policy and lifecycle control, but does not necessarily mean the customer owns the physical key hardware or that the service operator can never access plaintext.
Separate key administration from routine decryption: the export reader may unwrap a data key without being permitted to delete its wrapping key. Audit effective grants and key-use logs against workload identities, resource scope, and intended operations. Ask whether a broadly privileged administrator can grant themselves decryption rights; a role name alone is not evidence of separation.
The bulk ciphertext and its wrapped data key travel together, but wrapping-key authority remains a separate dependency.
Rotation is not re-encryption, and deletion is not cleanup
Suppose key version 7 protected January exports and version 8 becomes active in February. Rotation changes the material used for new operations, while old ciphertext may still depend on version 7. Some systems retain old versions transparently; others require explicit version selection. Rewrapping replaces the wrapper around a data key without necessarily rewriting the payload. Re-encryption changes the payload's encryption. Confirm the service's behavior instead of treating those three actions as synonyms.
A seven-year archive may depend on a key long after its last new write. Disabling a key is generally reversible but can immediately break reads; permanent deletion can make dependent data unrecoverable. Before deletion, enumerate primary data, replicas, snapshots, and retained backups, resolve retention and legal holds, and test restoration with the intended surviving keys. A waiting period and two-person approval reduce mistakes but do not prove there are no dependencies.
Evidence for lifecycle controls includes version history, approvals, dependent-copy inventories, denied deletion tests, and restore results. Cryptographic erasure is credible only if all necessary decryption material is irrecoverably destroyed, no usable plaintext copies remain, and the applicable retention rules allow destruction. Deleting a key alias or rotating to a new version does not meet that claim.
Classification drives location; location does not settle sovereignty
Classification expresses sensitivity and handling requirements. In Halcyon's four-level scheme, public notices are public, staff procedures are internal, contracts are confidential, and identifiable patient exports are restricted. A restricted export remains restricted after encryption because authorized decryption still restores the sensitive data. Bind classification to an owner and a rule set covering access, retention, allowed locations, and exceptions rather than inferring sensitivity from a filename.
Residency concerns where data is stored or processed. If policy allows only jurisdiction J1, inspect replicas, backup targets, diagnostic logs, temporary staging, and support workflows as well as the primary region. Sovereignty concerns applicable legal authority and control: an operator or remote administrator subject to another jurisdiction can create obligations or exposure even when disks remain in J1. Encryption and local key custody can reduce risks but cannot by themselves determine legal compliance; legal specialists must assess the actual contracts and access arrangements.
For audit sampling, join a classified dataset inventory to replication configuration, location attestations, subprocessor agreements, support-access records, and key-location evidence. Ask which mechanisms block an unauthorized copy and who approves exceptions. A contract saying J1-only is design evidence; a backup manifest naming J2 is contradictory operating evidence that must be resolved.
Storage location and cross-border legal authority require related but distinct assessments.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The certificate that covered too much
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
A gateway receives exports over validated TLS, but forwards them to the worker over plaintext. Stored exports use a fresh per-export symmetric key, wrapped by a separate long-lived key. The release lead calls the public certificate 'end-to-end encryption' and calls the wrapping key the 'data key'.
Term bank, not all of these are right
encryption in transitkey encryption keyencryption at restdata key
1.1Which protection is missing on the gateway-to-worker hop: encryption at rest or encryption in transit? (three words)
1.2What is the role of the key that wraps each per-export key? (three words)
Task 2: A new version does not rescue the archive
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
Version 8 now wraps all new export keys. A retained backup still requires version 7, and no rewrapping has occurred. An operator labels the switch 'archive re-encryption' and proposes irreversible removal of version 7. The backup is still under mandatory retention; the proposed removal is not an approved destruction method.
Term bank, not all of these are right
rotationkey deletionrewrappingre-encryption
2.1What lifecycle action actually occurred when new writes switched to version 8? (one word)
The inventory proves all export copies are stored and processed in J1. A lawyer separately flags that the service operator is subject to compulsory-access law in J2. A manager says 'residency proves sovereignty' and downgrades encrypted patient exports to public, although the handling scheme classifies identifiable patient exports as restricted even when encrypted.
Term bank, not all of these are right
sovereigntyrestrictedresidencypublic
3.1Which concept describes the lawyer's concern about legal authority rather than physical location? (one word)
3.2Which classification applies to these encrypted identifiable patient exports under the stated scheme? (one word)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon's draft says a public TLS listener makes every copy compliant and that annual rotation permits immediate key deletion. Write a replacement plan for the restricted export service using the requirements in the fixture, not those claims.
Keep machine fields exact, use YAML booleans, and supply short rationale text for wrapping and deletion review. The retention hold is active: this exercise needs a recoverable archive, not cryptographic erasure. Key administration must remain separate from the reader's duties.
Approved requirements and active dependency
dataset: identifiable patient exports
classification: restricted
approved_jurisdiction: J1 (primary and every backup)
transport: TLS 1.2 minimum on every hop
storage: encrypted at rest
key_control: customer-managed
key_roles: data key encrypts payload; wrapping key protects data key
rotation_interval_days: 365 (internal policy, not a universal standard)
reader_can_delete_key: prohibited
retained_backup: requires old key version; active retention hold
deletion: prohibited while hold or key dependency remains
Review six independent claims for Halcyon's restricted-export service. Accept only claims supported by the stated facts. The reviewer insists that an encryption setting settles every compliance question; do not inherit that assumption.
For rejection choose the root failing: hop-gap for an uncovered network hop, rotation-confusion for treating rotation as migration, deletion-dependency for destroying a required key, and jurisdiction-gap for ignoring legal authority. Accepted claims need no reason.
Verdicts are accept or reject. Every rejection needs one reason code from: hop-gap | rotation-confusion | deletion-dependency | jurisdiction-gap.
Six claims with their supporting facts
CDP-1 | Claim: all transport hops are encrypted. Facts: public TLS is valid; gateway-to-worker traffic is plaintext.
CDP-2 | Claim: stored exports use envelope encryption. Facts: payloads use data keys; a separately controlled wrapping key protects those data keys; wrapped keys and metadata accompany ciphertext.
CDP-3 | Claim: rotation migrated all old exports. Facts: only new writes use the new version; old wrapped keys remain unchanged.
CDP-4 | Claim: old key deletion is safe today. Facts: an archive under retention still needs that key; no replacement wrapper exists.
CDP-5 | Claim: sovereignty obligations are settled by disk location alone. Facts: copies stay in J1 but the operator is subject to compulsory-access law in J2; no legal assessment exists.
CDP-6 | Claim: routine readers lack destructive key authority. Facts: an effective-policy review and denied deletion test show readers may unwrap for their dataset but cannot disable or delete keys or change grants.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Cloud Fundamentals
Infrastructure as Code and Immutability
Turn infrastructure changes into reviewed, reproducible deployments without mistaking state, plans, or images for security guarantees.
