Data Security Technologies & Strategies

One axis sorts the whole toolbox

A bank stores a customer's card number five different ways across its systems: encrypted in the payment database, tokenized in the analytics warehouse, masked in the developers' test copy, anonymized in the fraud-research dataset, and hashed when it checks a typed card against a stored value. Same data, five technologies, and CCSP item writers love to swap one for another in the answer choices. The way to keep them straight is to stop memorizing them as a list and sort them on one axis: can the original value be recovered, and if so, what holds the secret that recovers it?

That single question splits the toolbox cleanly. Encryption is reversible, and the secret is the cryptographic key. Tokenization is reversible, but the secret is a separate lookup table (the token vault) that maps each surrogate back to its real value. Static masking and anonymization are deliberately not reversible from the protected copy: the original is discarded or generalized away, so there is no secret to hold. Hashing is one-way by mathematical design and exists to verify a value, not to recover it. Data loss prevention (DLP) sits on top of all of these as the policy layer that decides which technique a given piece of data must get.

Two consequences fall out of the axis and answer most exam stems by themselves. First, only the two reversible techniques can give you the original back, so any question that says "the application must later display the real value" rules out masking, anonymization, and hashing immediately. Second, where the recoverable secret lives decides regulatory scope: encryption keeps the real value present (as ciphertext) so the system stays in scope, while tokenization moves the real value out to the vault so the surrogate-holding systems leave scope. The rest of this page is that axis applied technique by technique.

The reversibility axis: only encryption and tokenization return the original; masking, anonymization, and hashing do not.

Encryption and key management

Encrypting a cloud object does not make the secret disappear; it relocates the secret from the data to the key that decrypts it. That is the whole reason key management, not the cipher, is where CCSP spends its attention. NIST SP 800-57 frames key management as a lifecycle, and an exam answer that names a single step ("rotate the key") while ignoring the rest is usually the wrong one.

The key lifecycle

NIST SP 800-57 Part 1 describes keys moving through phases: generation, distribution, storage, use, rotation, and destruction. Each phase is a control point. Keys are generated with a strong random source; distributed without ever traversing an untrusted channel in the clear; stored apart from the data they protect; rotated on a schedule so a compromised key has a bounded blast radius; and finally destroyed, which in the cloud is how you actually delete data (covered below). A hardware security module (HSM) validated to FIPS 140-2 or 140-3^[1] generates and stores keys in tamper-resistant hardware so the key material never leaves in plaintext.

Envelope encryption and who holds the key

Cloud platforms rarely encrypt large data directly with one master key. They use envelope encryption: a per-object data encryption key (DEK) encrypts the data, and a key encryption key (KEK) held in the key service encrypts the DEK. This is the same model introduced for Domain 1 in cloud security concepts; here the data-security angle is operational. The decision that drives most questions is who controls the KEK:

Provider-managed keys: the cloud provider generates and holds the KEK. Lowest effort, but you cannot independently rotate or revoke, and the provider can technically decrypt.
Customer-managed keys (CMK): you own the KEK inside the provider's key service, so you control rotation, can disable the key to revoke access instantly, and get an audit trail. This is the usual right answer when a question demands control plus convenience.
Bring/hold your own key (BYOK/HYOK): you generate the key in your own HSM and either import it or keep it entirely outside the provider, so the provider cannot decrypt without you. Highest assurance, highest operational burden.

Storage encryption itself follows NIST SP 800-111^[2], which distinguishes full-disk, volume/virtual-disk, and file/folder-level encryption for data at rest.

Cryptographic erase

In a multi-tenant cloud you can never physically destroy the shared disk a tenant's data sat on, so secure deletion is achieved by destroying the key: with the KEK gone, the ciphertext is unrecoverable noise. NIST SP 800-88 lists this cryptographic erase as a sanitization method for encrypted media. It is why key destruction is a confidentiality control, not just housekeeping, and why "delete the encryption key" is the correct way to render cloud data unrecoverable on demand.

Envelope encryption per NIST SP 800-57: a DEK encrypts the object, the KEK in the key service wraps the DEK; destroying the KEK is cryptographic erase.

Tokenization, masking, anonymization, hashing

These four are the techniques candidates confuse, so the exam tests the boundaries between them rather than each in isolation. Hold them against the one axis from the top of the page: reversibility, and where the secret lives.

Tokenization

Tokenization replaces a sensitive value (classically a payment card's primary account number) with a non-sensitive surrogate, the token, and stores the real value in a separate, tightly controlled token vault. The token has no mathematical relationship to the original, so even if it leaks it reveals nothing. The decisive property for the exam: because the real value now lives only in the vault, every other system that holds only tokens falls out of compliance scope. This is the standard PCI DSS scope-reduction answer, and the reason it beats encryption for that goal is purely about where the value lives, not about strength.

Data masking (static and dynamic)

Masking substitutes a realistic but fake value for the real one so people who must work with the data's shape never see the secret. Static masking writes a sanitized copy: production data is irreversibly transformed on the way into a dev, test, or analytics environment, so the lower-trust copy never contained the real values. Dynamic masking leaves the source untouched and redacts at read time based on the requester's role, so a support agent sees ****-****-****-1234 while a payments service sees the full value. Static is for making a safe copy; dynamic is for gating a live view.

Anonymization

Anonymization removes or generalizes identifiers so a record can no longer be linked to a specific person, even by the holder. Done properly it takes the data outside privacy regimes such as the GDPR^[3], whose Recital 26 states the regulation does not apply to truly anonymous information. The bar is high: pseudonymization (e.g. replacing a name with a stable code, or tokenizing) is still personal data because the mapping exists, whereas anonymization must make re-identification infeasible. Confusing the two is a frequent privacy-domain trap.

Hashing

A cryptographic hash is a one-way function producing a fixed-length digest; the same input always hashes to the same output, and you cannot invert it. It is the tool for integrity (has this file changed?), deduplication, and password storage, where you store the hash and compare hashes rather than ever holding the secret. Passwords add a per-user salt and a deliberately slow key-derivation function (such as PBKDF2, bcrypt, scrypt, or Argon2) to defeat precomputed rainbow tables and slow brute force. Because there is no key and no decrypt, hashing is never a way to protect a value you must read back, which is the misuse the exam baits.

Same card value through four techniques: only tokenization is recoverable (via the vault); masking, anonymization, and hashing are one-way.

DLP and managing keys, secrets, and certificates

The techniques above protect a value; the two capabilities here decide and enforce which value gets which protection, and keep the secrets that back encryption out of harm's way.

Data loss prevention

Data loss prevention (DLP) discovers and classifies sensitive data, then enforces policy on it across three states: data at rest in storage, data in motion across the network, and data in use at the endpoint. A policy might be "any object matching a credit-card pattern leaving to personal webmail is blocked," and DLP is what detects the match and acts (block, quarantine, alert, or auto-encrypt). DLP is therefore the orchestration layer above the toolbox: it is the thing that says this field must be tokenized, that file must be encrypted before it leaves.

In the cloud the perimeter appliance cannot see traffic that goes browser-to-SaaS, so coverage shifts to a cloud access security broker (CASB) or a provider-native DLP service. A CASB sits inline or via API between users and cloud apps and applies DLP, access, and threat controls to sanctioned and unsanctioned (shadow IT) cloud use alike. Note DLP is a detective-and-preventive control on movement and exposure; it does not replace encryption or access control, it triggers them.

Keys, secrets, and certificates

These three are related but distinct, and the exam expects you to keep the management of each separate:

Keys are cryptographic key material, managed by a key management service or HSM through the SP 800-57 lifecycle above. Access is controlled, use is logged, rotation is scheduled.
Secrets are application credentials: database passwords, API keys, OAuth client secrets. A managed secrets store holds them encrypted, serves them to workloads at runtime by identity, and supports automatic rotation, so nothing is hardcoded in source or config. Hardcoded secrets in a repository or container image is the canonical finding.
Certificates are X.509 identities for TLS and signing. A certificate manager or internal certificate authority issues them, tracks expiry, automates renewal, and crucially supports revocation through a certificate revocation list (CRL) or OCSP^[4] so a compromised certificate can be invalidated before it expires. Expired or unrotated certificates causing outages, and the inability to revoke quickly, are the recurring operational risks.

The unifying rule: every long-lived secret needs a managed home that can issue, rotate, and revoke it centrally, because the weakest link in cloud cryptography is almost always a mishandled key, password, or certificate rather than a broken algorithm.

DLP applies one classification policy across data at rest, in motion (via CASB), and in use, then blocks, quarantines, alerts, or encrypts.

Exam-pattern recognition

Domain 2.3 items rarely ask for a definition; they describe a goal and offer technologies that all sound plausible, betting you will pick the wrong member of the family. Map the stem's goal to the axis and the answer falls out.

Recognizing the cue

"Reduce PCI DSS scope" / "systems should no longer handle real card numbers." Answer: tokenization. The trap is encryption, which protects the value but leaves it present, so the system stays in scope.
"Developers need realistic data in a test environment without exposing real customers." Answer: static data masking. The trap is encryption (devs would need the key, defeating the point) or dynamic masking (which gates a live view, not a copy).
"Hide a column from some roles but show it to others, on the live system." Answer: dynamic masking. The trap is static masking, which makes a separate copy rather than gating the source per query.
"Publish a dataset so GDPR no longer applies." Answer: anonymization. The trap is pseudonymization or tokenization, which are still personal data because the mapping exists.
"Store passwords / verify a value without ever recovering it." Answer: salted hashing with a slow KDF. The trap is encryption, which is reversible and so the wrong tool for a value you should never be able to read back.
"Make cloud data unrecoverable on demand in a multi-tenant store." Answer: cryptographic erase, destroy the key. The trap is physical destruction or overwriting, which you cannot do on shared cloud media.
"Revoke access to encrypted data instantly across petabytes." Answer: disable the customer-managed key. The trap is re-encrypting everything, which is slow and unnecessary when one key gates all of it.

Why the distractors are wrong

The single discriminator behind nearly all of these is reversibility and secret location. If the stem needs the original back, only encryption or tokenization qualify, and the choice between them is scope (tokenization removes the value, encryption keeps it). If the stem must never recover the original, it is masking, anonymization, or hashing, and the choice is purpose (safe copy, de-identification, or verification). When key control is the subject, customer-managed beats provider-managed for revocation and audit, and key destruction is how cloud deletion works. Read for the goal, place it on the axis, and the tempting wrong family eliminates itself.

Map the goal to the axis: recover the value (tokenize to drop scope, else encrypt) or one-way it (anonymize to de-identify, else mask/hash by purpose).

Data-protection techniques by reversibility and where the secret lives

Technique	Reversible?	What holds the secret	Primary purpose	Typical exam cue
Encryption	Yes, with the key	The cryptographic key	Confidentiality of data kept in place	Protect data at rest/in transit; value stays in scope
Tokenization	Yes, via the token vault	The token-to-value vault	Remove the real value from scope	PCI DSS scope reduction; surrogate replaces the value
Static masking	No (one-way copy)	Nothing; original discarded	Safe non-production / lower-trust data	Realistic fake values for dev/test/analytics
Dynamic masking	No to the viewer	Source data, gated by role at read	Redact per query without copying	Hide columns from some roles at query time
Anonymization	No, by design	Nothing; identifiers removed	Leave the privacy regime (de-identify)	GDPR no longer applies; cannot re-identify
Hashing	No, never	No secret to recover	Integrity, dedup, password storage	One-way digest; verify, do not read back

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Sort data-protection techniques by reversibility and where the recovery secret lives

The whole 2.3 toolbox separates on one axis: can you recover the original, and what holds the secret that does it. Encryption is reversible and the secret is the key; tokenization is reversible and the secret is the token vault; static masking, anonymization, and hashing are one-way with no recovery secret at all. Place any stem's goal on that axis and the wrong family eliminates itself, which is exactly what the distractors bait you to miss.

Tokenization removes the real value from scope; encryption keeps it present but unreadable

Tokenization swaps a sensitive value for a surrogate with no mathematical link to the original and parks the real value in a separate vault, so systems holding only tokens leave compliance scope. Encryption leaves the real value in place as ciphertext, so the system is still processing regulated data and stays in scope, just protected. For PCI DSS scope reduction the answer turns on where the value lives, not on which is stronger.

Trap Reaching for encryption to take a system out of PCI DSS scope; the real value is still present as ciphertext, so the system remains in scope.

2 questions test this

Tokens carry no mathematical relationship to the value they replace

A token is an arbitrary surrogate, not a transform of the input, so a leaked token reveals nothing and there is no algorithm to reverse it; recovery happens only by lookup in the hardened vault. That property, plus the separate vault, is what lets tokenization shrink the systems that handle real data. It is the opposite of format-preserving encryption, where the protected output is still derived from the value under a key.

Static masking writes a one-way safe copy; dynamic masking gates a live view by role

Static data masking irreversibly transforms production data into a sanitized copy for dev, test, or analytics, so the lower-trust environment never held real values. Dynamic masking leaves the source untouched and redacts at read time based on the requester's role, so one query sees a card number and another sees only the last four digits. Use static to make a safe copy, dynamic to gate a live system per query.

Trap Using static masking when the requirement is to hide a column from some roles on the live system; static produces a separate copy rather than gating the source at query time.

8 questions test this

Masking is for usable non-production data, not for storing data securely

Masking substitutes realistic but fake values so people can work with data's shape without seeing the secret, which fits test data and partial-display views. It is not a confidentiality control for the system of record, because the masked output is fake and the technique is one-way. When the real value must survive somewhere recoverable, masking is the wrong tool; encryption or tokenization is.

4 questions test this

Anonymization leaves the privacy regime; pseudonymization and tokenization do not

Anonymization removes or generalizes identifiers so a record can no longer be tied to a person even by the holder, which under GDPR Recital 26 takes the data outside the regulation. Pseudonymization (a stable code in place of a name) and tokenization still count as personal data because the mapping back exists. Confusing reversible de-identification with true anonymization is a recurring privacy trap.

Trap Treating tokenized or pseudonymized records as anonymous; the mapping still links to the individual, so privacy law still applies.

Hashing is one-way verification, never confidentiality you can read back

A cryptographic hash is a fixed-length digest where the same input always yields the same output and no key or inverse exists. That makes it right for integrity checks, deduplication, and password storage, and wrong for any value you must later recover. Calling hashing a way to encrypt a recoverable field is the mistake the exam baits, because there is nothing to decrypt.

Trap Using a hash to protect a field the application must later display; hashing has no decrypt, so the value is gone.

Store passwords as a salted hash with a slow KDF, never encrypted or plain

Passwords are stored hashed with a per-user salt and a deliberately slow key-derivation function such as PBKDF2, bcrypt, scrypt, or Argon2. The salt defeats precomputed rainbow tables by making identical passwords hash differently, and the slow KDF caps brute-force speed. Encryption would be wrong here because it is reversible: you should never be able to recover a stored password.

Trap Encrypting stored passwords instead of hashing them; encryption is reversible, so a key compromise exposes every password in plaintext.

Encryption only relocates the secret to the key, so key management is the real control

Encrypting cloud data moves the protected secret from the data to the key that decrypts it, which is why NIST SP 800-57 treats the full key lifecycle as the control: generation, distribution, storage, use, rotation, and destruction. Lose the key and the ciphertext is plaintext to whoever holds it. An answer that secures only one phase while ignoring storage or destruction is usually incomplete.

One KEK gates everything under it, which is what makes fast revocation and crypto-erase possible

Because envelope encryption wraps every object's data key under a single key-encryption key in the key service, that one KEK controls access to all the data beneath it. Disable the KEK and every object under it becomes undecryptable at once; destroy the KEK and that data is cryptographically erased. This one-key-gates-many structure is why you never have to re-encrypt at scale to revoke or delete.

5 questions test this

Customer-managed keys give you rotation, instant revocation, and audit; provider-managed do not

With a customer-managed key you own the KEK inside the provider's key service, so you schedule rotation, disable the key to revoke access immediately, and get a usage audit trail. Provider-managed keys are lower effort but you cannot independently rotate or revoke, and the provider can technically decrypt. When a stem wants control with convenience, customer-managed is the answer; BYOK/HYOK is for keeping the key entirely outside the provider at higher operational cost.

Trap Choosing provider-managed keys when the requirement is independent revocation or an audit trail; only customer-managed (or BYOK) gives you that control.

8 questions test this

Disable the key to revoke access to encrypted data instantly across any volume

Because one KEK gates all data encrypted under it, disabling that customer-managed key cuts off decryption for petabytes at once, with no need to re-encrypt anything. Re-encrypting everything to cut off access is slow, costly, and unnecessary when the key already controls all of it. This is the practical payoff of envelope encryption plus customer-managed keys.

Trap Re-encrypting all the data to revoke access when disabling the single key that gates it achieves the same thing instantly.

1 question tests this

A security architect is designing a block storage encryption architecture where the organization wants to maintain control over encryption…

Cryptographic erase destroys data by destroying its key, not the blocks

Cryptographic erase is a key-destruction technique: the data was written encrypted, so deleting the key that protects it, the KEK that gates the DEK, turns the ciphertext into unrecoverable noise without ever touching the storage blocks. The recovery secret lives entirely in the key, so once every copy of the key is gone the data is irretrievable on demand. This makes key destruction itself a confidentiality control and is why it can sanitize media you can never physically reach.

Trap Believing the data is gone after deleting the ciphertext or disabling the key while a copy survives; cryptographic erase requires destroying every copy of the key, since that key is the only thing protecting the data.

5 questions test this

An HSM keeps key material in tamper-resistant hardware and is validated to FIPS 140-2/3

A hardware security module generates, stores, and uses keys inside tamper-resistant hardware so the key never leaves in plaintext, and its assurance level is certified under FIPS 140-2 or 140-3. Reach for an HSM (or BYOK/HYOK backed by one) when the requirement is the highest key assurance or keeping keys outside the provider's reach. Software-only key storage cannot make the same hardware tamper-resistance claim.

5 questions test this

Storage encryption (NIST SP 800-111) protects data at rest at disk, volume, or file level

NIST SP 800-111 covers encrypting stored data and distinguishes full-disk, volume or virtual-disk, and file/folder-level encryption, each protecting against a different exposure of media at rest. The granularity you pick decides what an attacker who gets the raw media or a stray snapshot can read. It governs data at rest specifically, not data in transit, which is a separate TLS concern.

2 questions test this

DLP enforces classification-driven policy across data at rest, in motion, and in use

Data loss prevention discovers and classifies sensitive content, then blocks, quarantines, alerts, or encrypts it across three states: at rest in stores, in motion on the network, and in use at the endpoint. It is the policy layer that decides which technique a given piece of data must get, not a replacement for encryption or access control. Coverage across all three states is what a strong DLP answer requires.

Trap Assuming network-only DLP is sufficient; it misses data at rest in stores and data in use at the endpoint, leaving two of the three states uncovered.

6 questions test this

In the cloud a CASB carries the DLP coverage a perimeter appliance cannot reach

A cloud access security broker sits inline or via API between users and cloud apps and applies DLP, access, and threat controls to both sanctioned and unsanctioned (shadow IT) cloud use. It exists because browser-to-SaaS traffic never crosses a traditional network perimeter, so a gateway appliance simply cannot see it. When a stem describes controlling data going to cloud apps, the CASB is the cloud-native enforcement point.

Trap Relying on a traditional perimeter DLP appliance for SaaS traffic; browser-to-cloud flows bypass it, which is why a CASB is needed.

7 questions test this

Keys, secrets, and certificates are managed separately, each with issue, rotate, and revoke

Keys are cryptographic material in a KMS or HSM; secrets are application credentials like database passwords and API keys in a managed secrets store; certificates are X.509 identities from a certificate manager or CA. Each needs a managed home that can issue, rotate, and revoke centrally so nothing is hardcoded. The exam expects you to keep the three distinct rather than treating them as one bucket.

Hardcoded secrets in source or images are the canonical finding; use a managed secrets store

A managed secrets store holds credentials encrypted, serves them to workloads at runtime by identity, and rotates them automatically, so no password or API key sits in a repository, container image, or config file. Hardcoded secrets are the recurring vulnerability because anyone who reads the artifact reads the credential. The fix the exam wants is centralizing the secret with runtime retrieval and rotation, not obscuring it in config.

Trap Storing credentials in environment files or config baked into an image instead of a secrets manager; the secret travels with the artifact and leaks with it.

Certificate management must support revocation via CRL or OCSP, not just expiry

A certificate manager or internal CA issues X.509 certs, tracks expiry, and automates renewal, but the load-bearing capability is revocation: a compromised certificate must be invalidated before it expires using a certificate revocation list (CRL) or OCSP. Relying only on expiry leaves a compromised key trusted for its remaining lifetime. Expired or unrotated certs causing outages, and slow revocation, are the recurring operational risks.

Trap Treating certificate expiry as the only control; without CRL or OCSP a compromised certificate stays trusted until it would have expired anyway.

Encryption protects against the provider only when you control the key

Provider-managed encryption protects data from outside attackers and stolen media, but if the provider holds the key it can technically decrypt your data, so it does not protect you from the provider itself. To exclude the provider you must hold the key, through customer-managed keys at minimum or BYOK/HYOK with your own HSM. The threat model the stem names decides which is required.

Trap Assuming provider-managed encryption keeps your data confidential from the provider; whoever holds the key can decrypt, so provider-held keys do not exclude the provider.

6 questions test this

A CASB risk-scores discovered apps on dozens of security, compliance, and legal factors to prioritize them

After discovery surfaces hundreds of apps, a CASB's catalog scores each one against many risk factors (often 80-90+) spanning security controls, compliance certifications (SOC 2, HIPAA), and legal factors (data residency, terms of service). This scoring is what lets the team prioritize which shadow-IT apps to sanction or block first.

2 questions test this

DLP detects more than regex can: fingerprinting for forms, EDM for exact records, OCR for images

Regular-expression pattern matching suits structured, predictable formats (credit-card, SSN). For other data, DLP uses stronger techniques: document fingerprinting hashes a blank form or template's unique word pattern to catch any filled-in copy by structure, even when values vary; Exact Data Match (EDM), also called structured-data fingerprinting, indexes specific values from a source database and flags only those exact records, slashing false positives; OCR extracts text from images, scanned PDFs, and screenshots so the classifiers can inspect it.

Trap Reaching for a generic regex when the requirement is to catch a known template or an exact database record — fingerprinting matches by structure and EDM matches by indexed values, both far more precise than a format pattern.

9 questions test this

Cut DLP false positives with context keywords, exclusion rules, and predefined sensitive-info types

Over-broad patterns produce excessive matches. Reduce false positives without losing recall by: adding context keywords (hotwords like 'Employee ID') near the pattern so a match needs supporting evidence; writing exclusion rules that filter known non-sensitive values (test SSNs, product SKUs); and using predefined sensitive-information types that combine pattern matching, dictionaries, and confidence levels. These tune accuracy rather than weakening detection.

5 questions test this

DLP policy templates ship pre-built detection rules for PCI-DSS, HIPAA, and GDPR

DLP engines include regulatory policy templates with pre-configured sensitive-information types, conditions, and actions for frameworks like PCI-DSS, HIPAA, and GDPR. Using a template is the fastest way to align a deployment with a specific regulation, cutting setup time while ensuring coverage of the required data types.

3 questions test this

Roll out a DLP policy in simulation/audit mode first, then enforce gradually

Best practice is to deploy a new DLP policy in simulation mode (also called audit or monitor mode), which logs matches and potential violations without blocking users. This lets the team measure impact, surface false positives, and tune rules before turning on enforcement, minimizing business disruption. Enforcement actions can then be tiered (audit-only, block-with-override requiring justification, full block) by severity.

7 questions test this

Vaulted tokenization keeps a token-to-value database; vaultless derives tokens cryptographically with no mapping store

Vaulted tokenization stores the mapping between each token and its real value in a central vault, which becomes the highest-value target and must be protected to full PCI-DSS scope because it holds the actual PANs. Vaultless tokenization uses cryptographic methods (often HSM-backed) to generate and reverse tokens by computation rather than database lookup, eliminating the central mapping store and shrinking the attack surface.

Trap Assuming vaultless removes all risk — vaultless built on format-preserving encryption inherits FPE's weakness on small domain sizes, which NIST flags as exploitable.

3 questions test this

Deterministic tokenization yields the same token for the same input so tokenized data still joins

Deterministic tokenization produces an identical token every time for a given input value under the same key and context, preserving referential integrity. This lets analytics teams join and aggregate de-identified records across multiple tables and datasets without exposing the real values. Format-preserving encryption on the identifier can serve the same purpose where field length and format must be retained.

5 questions test this

Format-preserving encryption (NIST FF1) keeps a field's original length and format

Format-preserving encryption (FPE) encrypts data while keeping the ciphertext in the same format and length as the input, so a 16-digit card number stays 16 digits and fits legacy schemas, foreign keys, and validation. NIST SP 800-38G specifies FPE modes built on AES; the published standard defined FF1 and FF3-1, but cryptanalysis (notably Beyne 2021) prompted NIST's draft revision to drop FF3/FF3-1, leaving FF1 as the recommended mode. NIST also warns that FPE weakens when the domain (range of possible inputs) is small (it now requires a minimum domain of one million).

Trap Choosing standard AES when the database field cannot change length or format — only a format-preserving mode like FF1 keeps the original structure.

4 questions test this

BYOK imports your key into the cloud KMS; HYOK keeps the key entirely outside the provider

Bring Your Own Key (BYOK) generates keys on your own HSM and imports them into the cloud KMS, demonstrating control over key generation while still using KMS features. Hold Your Own Key (HYOK), also called external key manager integration, keeps key material in your own KMS outside any single cloud so the provider never holds the key, even during operations. Client-side encryption likewise encrypts before upload so the CSP never sees plaintext. The more the provider must never access the key, the further you move from provider-managed toward HYOK/client-side.

Trap Picking provider-managed or BYOK when the requirement is the CSP never has the key material — only HYOK/external key manager (or client-side encryption) keeps the key out of the provider's reach.

7 questions test this

ABAC makes access decisions from subject, resource, and environment attributes, solving role explosion

Attribute-Based Access Control evaluates attributes of the subject (department, project), the resource (classification label), and the environment (time, location) against policy to decide access dynamically (NIST SP 800-162). One attribute policy replaces the many roles that cause role explosion, and decisions adjust automatically as attributes change. A hybrid RBAC+ABAC model uses roles for baseline permissions and ABAC conditions for classification-driven granularity.

Trap Reaching for more RBAC roles when access must turn on data classification and changing context — that is what drives role explosion; ABAC evaluates classification as a resource attribute instead.

6 questions test this

DAM dynamic profiling baselines each account's normal objects and alerts on deviations

Database Activity Monitoring with dynamic profiling automatically builds, per database account, the list of data objects that account regularly accesses, forming a behavioral baseline. When a profiled account (including a privileged DBA) touches an object outside its baseline, DAM alerts or blocks. DAM also provides near-real-time policy-violation alerting and built-in sensitive-data discovery for standards like HIPAA and GDPR.

3 questions test this

Agent-based DAM sees local DBA sessions that network-based DAM misses

Network-based DAM inspects database traffic on the wire and cannot see local connections that bypass the network, such as direct console access or local sockets used by DBAs. Host/agent-based DAM runs on the database server and captures both network and local privileged activity, which is why agent-based deployment connecting to a central collector is the common cloud DAM approach when local DBA actions must be monitored.

Trap Blaming a DAM gap on misconfiguration when local DBA sessions go unseen — network-only monitoring structurally cannot observe local connections; host-based agents are required.

3 questions test this

Data Security Technologies & Strategies

One axis sorts the whole toolbox

Encryption and key management

The key lifecycle

Envelope encryption and who holds the key

Cryptographic erase

Tokenization, masking, anonymization, hashing

Tokenization

Data masking (static and dynamic)

Anonymization

Hashing

DLP and managing keys, secrets, and certificates

Data loss prevention

Keys, secrets, and certificates

Exam-pattern recognition

Recognizing the cue

Why the distractors are wrong

Data-protection techniques by reversibility and where the secret lives

Decision tree

Cheat sheet

Also tested in

References