Cloud Data Security practice questions

Apply data classification labels and enable DLP scanning

Why it fails: Classification labels and DLP scanning identify and monitor sensitive data but do not render objects unreadable; a public bucket would still expose plaintext PHI. They are tempting because both are data-governance controls, and would be correct for visibility and compliance reporting rather than cryptographic protection.

Enable bucket versioning and cross-region replication

Why it fails: Versioning and cross-region replication preserve and duplicate objects; neither encrypts content, so a public bucket still exposes readable PHI. They are tempting as resilience controls, and would be correct for durability, ransomware recovery or regional failover, not for confidentiality against accidental exposure.

Use pre-signed URLs and IAM policies

Why it fails: Pre-signed URLs and IAM policies govern access requests, but a bucket made public bypasses those controls, leaving objects readable. They are tempting because they are standard access-management tools, and would be correct for granting time-limited or least-privilege access, not for rendering data unreadable at rest.

Pseudonymization

Why it fails: Pseudonymization replaces identifiers with pseudonyms, but is usually not reversible without additional information.

Bucketing

Why it fails: Bucketing generalises values into ranges (for example, ages 20–29), so it cannot map a token back to the original PII via a lookup table. It is tempting because bucketing reduces identifiability while preserving analytical utility, and would be the right choice when aggregate statistics are needed rather than reversible tokenisation.

Masking

Why it fails: Masking partially obscures data (e.g., showing only last 4 digits) but is not reversible.

Cloud provider default encryption

Why it fails: Cloud provider default encryption offers no customer-controlled rotation schedule or key access policies; keys are provider-managed and invisible to tenants. It is tempting because it secures data at rest with zero configuration, and would be the right choice when compliance mandates only encryption, not customer-managed keys or 90-day rotation.

Customer-supplied encryption keys (CSEK)

Why it fails: Customer-supplied encryption keys are supplied by the customer and never stored in the cloud provider's KMS, so the provider cannot rotate them automatically every 90 days. They suit organisations retaining sole key custody for compliance. Granular access policies and scheduled rotation require a cloud-managed key model instead.

Bring your own key (BYOK)

Why it fails: BYOK imports customer-generated key material into the provider's KMS, but rotation and access policy remain governed by the provider's key hierarchy, not the customer's. It suits regulatory mandates requiring customer-controlled key origin, not granular per-key usage policies with scheduled rotation.

Use client-side encryption but store the key in the cloud provider's key vault

Why it fails: Storing the key in the provider's vault hands the provider custody, so it can access plaintext, contradicting the requirement that the provider cannot access keys. It is tempting for operational convenience, but the stem needs keys held outside provider control while still permitting analytics processing.

Use envelope encryption with a cloud KMS key and store the data key alongside the encrypted data

Why it fails: Envelope encryption with a cloud KMS key lets the provider unwrap the data key, so it can access plaintext, violating the no-provider-access requirement. Storing the data key alongside ciphertext compounds this. It suits provider-managed encryption, not the client-side control the stem demands.

Switch to server-side encryption with customer-managed keys and grant the analytics service access to the key management service (KMS)

Why it fails: Server-side encryption with customer-managed keys stores the key in the cloud KMS, which is operated by the provider, so the provider can access the key. This does not meet the requirement.

Overwrite the objects with random data multiple times before deletion

Why it fails: Cloud object storage abstracts physical media, so overwriting objects with random data does not guarantee erasure of replicated copies or residual blocks. It is tempting because overwriting is the classic sanitisation method for self-managed magnetic disks, but cryptographic erasure is required here.

Enable MFA delete and then delete the objects

Why it fails: MFA delete only adds authentication to delete operations; it does not destroy data, and objects may persist in versions or replicas. It is tempting because it prevents accidental or unauthorised deletion, which suits retention protection, but the requirement is irretrievable destruction after the retention period.

Delete the objects and then delete the bucket

Why it fails: Deleting objects and the bucket removes references, yet provider-side replicas, backups and residual storage may retain recoverable data. It is tempting because it appears to remove the entire container, but cryptographic erasure of the customer-managed key is what makes data irretrievable in cloud object storage.

Cloud storage bucket policies with principal identification

Why it fails: Resource-based policies with principal identifiers control access based on the identity of the requester, not on data classification tags.

Object storage ACLs with predefined permissions

Why it fails: ACLs with predefined permissions grant access based on fixed roles or users, not dynamic classification tags.

Time-limited access URLs with expiration time

Why it fails: Time-limited access URLs provide temporary access but do not consider data classification tags for enforcement.

Enable cross-region replication to a secondary EU region.

Why it fails: Replication may create copies in other regions, potentially violating data residency if the secondary region is outside the EU.

Configure object-level access controls to restrict access to EU-based users only.

Why it fails: Access controls do not control where data is stored; data could still reside outside the EU.

Apply data classification labels to all objects to indicate EU data.

Why it fails: Classification labels help manage data but do not enforce geographic storage location.

Pseudonymisation

Why it fails: Pseudonymisation replaces values with consistent reversible tokens, preserving linkage so the original can be re-identified via a mapping — not irreversible. It suits analytics needing correlation across records. The stem demands irreversible placeholder substitution retaining the original format, which masking performs.

Bucketing

Why it fails: Bucketing replaces values with range labels (for example, age bands), which destroys the original credit card digit format and is reversible only by inference, not by design. It suits analytics on grouped numeric ranges, not format-preserving placeholder substitution.

Tokenization

Why it fails: Tokenization substitutes a surrogate value that maps back to the original through a token vault, so it is reversible, not irreversible as the stem demands. It is the right choice when detokenisation or referential integrity across systems is required.

Bucket policies

Why it fails: Bucket policies apply uniformly to an entire bucket or prefix, so they cannot scope access to individual objects for named external auditors. They are tempting because they are the standard mechanism for broad, resource-level permissions, and would be correct if the requirement were bucket-wide rather than per-object.

IAM roles

Why it fails: IAM roles grant permissions to identities within your account or trusted accounts, not to external auditors needing object-specific, time-bound access. They are tempting because roles are the standard way to delegate access without long-term credentials, and would be correct for internal workloads assuming temporary credentials.

Access keys

Why it fails: Access keys are long-lived credentials tied to an identity, providing neither object-level granularity nor automatic expiry for external auditors. They are tempting because they are the classic programmatic access method, and would be correct for service accounts needing persistent API access, not temporary scoped access.

Encryption

Why it fails: Encryption is reversible, not anonymising: the ciphertext still maps to an identifiable individual once decrypted, so it fails the anonymisation requirement. It is tempting because encryption protects PII at rest and satisfies confidentiality controls, and would be correct where the goal is protecting stored data rather than producing de-identified datasets for analytics.

Bucketing

Why it fails: Bucketing generalises values into ranges, which reduces precision and can destroy the granularity analytics need, so it does not anonymise while preserving utility as required. It is tempting because bucketing is a recognised de-identification transform, and would be correct where coarse categorical grouping, such as age bands, is the analytical goal.

Hold your own key (HYOK)

Why it fails: HYOK keeps key material outside the provider's control, so the cloud-native encryption service cannot decrypt or re-key data, and revocation depends on the external key holder rather than immediate provider-side action. It suits strict sovereignty mandates, not cloud-native revocation.

Bring your own key (BYOK)

Why it fails: BYOK uploads customer key material into the provider's key management service, where the provider retains the ability to use it; revoking access requires key deletion or rotation rather than instant tenant-wide revocation. It suits control over key provenance, not immediate cut-off.

Cloud provider default server-side encryption

Why it fails: Provider default server-side encryption leaves key custody entirely with the cloud provider, so the organisation cannot revoke its own access to the encrypted data at will. It suits low-sensitivity workloads where key management overhead is unwanted.

Client-side encryption before upload

Why it fails: Client-side encryption protects data at rest before upload, not the network path between data centre and VPC, and provides no dedicated tunnel or throughput guarantee. It is the right choice when the cloud provider itself must never hold plaintext.

TLS 1.2 for all API communication

Why it fails: TLS is for API calls, not a persistent tunnel between networks.

Cloud KMS key for envelope encryption

Why it fails: A Cloud KMS key encrypts data at rest, not the network path between your data centre and the VPC, so it cannot provide a dedicated encrypted tunnel or consistent throughput. It is tempting because envelope encryption with KMS keys is the standard approach for protecting stored objects and volumes, which is the correct choice when the requirement is data-at-rest protection.

Customer-managed encryption keys (CMEK)

Why it fails: Customer-managed encryption keys remain stored in the provider's KMS, so the provider retains the technical capability to access key material, failing the isolation requirement. CMEK is tempting because it gives the customer control over key rotation and policy, but it does not exclude the provider.

Bring your own key (BYOK)

Why it fails: BYOK uploads customer-generated key material into the provider's key management service, so the provider can still access the keys, breaching the stated requirement. It is tempting because the customer creates the key, but true provider exclusion requires an external or HYOK model where keys never enter provider infrastructure.

Cloud provider default server-side encryption

Why it fails: Provider default server-side encryption uses keys the provider generates and manages, so keys are neither customer-isolated nor inaccessible to the provider. It is tempting because it encrypts data at rest with no configuration effort, but it satisfies neither the per-customer isolation nor the provider-exclusion requirement.

Use default server-side encryption with cloud-managed keys

Why it fails: Default provider-managed encryption keys leave key custody with the cloud provider and do not enforce data-residency or produce the access logging the regulation demands. It is tempting because it secures data at rest with minimal effort, and would suffice where the only requirement is baseline encryption without residency or monitoring obligations.

Enable cross-region replication for disaster recovery

Why it fails: Cross-region replication copies data into additional geographies, directly violating the requirement that sensitive data remain only in specified regions. It is tempting because it strengthens availability and disaster recovery, and would be the right control where resilience across regions is required and no residency constraint restricts where replicas may reside.

Bucket ACL restricting write access

Why it fails: Bucket ACLs govern read/write permissions on buckets and objects; they are not immutability controls, so an authorised principal could still delete or overwrite objects. They are tempting because ACLs do restrict write access, and would be correct for limiting who may write, but they cannot enforce retention.

Lifecycle policy to transition to archival storage

Why it fails: Lifecycle policies move objects between storage classes; they do not prevent modification or deletion, so retention is not enforced. They are tempting because transitioning to archival storage sounds like long-term preservation, and would be correct for cost optimisation, but they leave objects mutable and deletable.

Cross-region replication

Why it fails: Replication copies objects to another region for durability and latency, but it does not lock versions; a replicated object can still be overwritten or deleted in either location. It is tempting because replication supports disaster recovery and availability, and would be correct where regional resilience, not regulatory immutability, is the requirement.

Make the object publicly readable

Why it fails: Public readability exposes the object to anyone with the URL, granting far broader access than the partner alone and bypassing authentication entirely. It suits genuinely public assets such as website images, not temporary scoped partner downloads.

Use cross-region replication to the partner's account

Why it fails: Replication copies objects into a bucket the partner controls, granting durable possession rather than a scoped, expiring download right, and it cannot target a single object. It suits disaster recovery or latency reduction across regions, not delegated temporary access to one object.

Grant the partner a role with read access to the bucket

Why it fails: IAM role grants access to all objects in the bucket, not specific.

Pre-signed URLs

Why it fails: Pre-signed URLs grant time-limited access to specific objects; they provide no recovery mechanism. They are tempting because they securely share objects without exposing credentials, but the feature that preserved unencrypted prior copies after the ransomware overwrote current versions is object versioning.

Cross-region replication

Why it fails: Cross-region replication copies objects to another region, so encrypted current versions replicate as encrypted data; it does not preserve prior unencrypted copies. It is tempting for disaster recovery and durability, but versioning is what retained the earlier versions the organisation recovered.

Object lock

Why it fails: Object lock prevents deletion or overwriting for a fixed retention period, so it cannot explain recovery of files already encrypted in place; versioning alone provides that. Object lock is tempting because it does protect against ransomware deletion, but only for immutability requirements, not encryption of current versions.

Masking

Why it fails: Masking obscures characters in place, typically irreversibly, so it cannot produce a consistent token that maps the same SSN to the same value across records. It is tempting because masking is the standard choice for displaying partial values, such as showing only the last four digits to support staff.

Date shifting

Why it fails: Date shifting alters timestamps by a random offset to preserve chronological relationships, so it cannot tokenise an SSN at all. It is tempting because it is a genuine de-identification technique, and it would be correct when datasets containing dates must retain relative ordering for analysis.

Pseudonymization

Why it fails: Pseudonymization replaces values with tokens, but the mapping is reversible via a separately held key, which the requirement's non-reversible condition excludes. It is tempting because it delivers the consistent mapping sought, and it would be correct where re-identification is permitted under strict access controls.

Customer-Managed Encryption Key (CMEK)

Why it fails: CMEK keys are generated and stored inside the cloud provider's KMS, so they fail the on-premises generation and storage requirement. It is tempting because CMEK gives the customer control over key rotation and access policy within the provider's key hierarchy, which suits single-cloud workloads needing separation from provider-managed keys.

Cloud provider default encryption

Why it fails: Provider default encryption generates and stores keys entirely within the cloud service, giving the customer no on-premises custody. It is tempting because it delivers encryption at rest with zero configuration overhead, which suits workloads with no regulatory mandate over key location or key ownership.

Client-side encryption

Why it fails: Client-side encryption encrypts data before upload, but the cloud service never performs the encryption operation, so it fails the requirement that cloud services use the keys. It is tempting because it keeps plaintext and keys wholly outside the provider, which suits highly sensitive data where the provider must never see cleartext.

Use pre-signed URLs for all access

Why it fails: Pre-signed URLs grant time-limited access to a specific object; they do not constrain where data is stored or processed, so they cannot enforce geographic boundaries. They are tempting because they are a legitimate mechanism for secure, temporary access delegation without exposing credentials, which suits sharing scenarios rather than residency control.

Enable cross-region replication for disaster recovery

Why it fails: Cross-region replication copies data into another region, directly violating the requirement that customer data remain within specified geographic boundaries. It is tempting because it is a valid resilience measure for disaster recovery, and would be correct where residency rules permit replication to an approved in-jurisdiction region.