Data Security and Governance: free practice questions

Only a customer-managed KMS key (CMK) gives the company full control over key policies, rotation schedules, and the ability to revoke access by disabling the key. Option A (AWS owned key) is managed entirely by AWS and cannot be controlled, rotated, or revoked by the customer. Option B (AWS managed key) is managed by AWS on behalf of the customer—AWS controls rotation, and the customer cannot disable it directly. Option D (client-side encryption with PITR) addresses encryption but does not use KMS-managed server-side encryption; PITR is a backup feature, not an encryption control.

AWS Lake Formation supports row-level and cell-level security through Data Filters. A data filter defines a row filter expression (e.g., `region = 'us-east-1'`) and optionally a column filter. When the data engineer grants table access to the data scientist and attaches this data filter, the data scientist only sees matching rows — other users with their own grants are unaffected. Option B (Glue Data Catalog resource policies) controls access to catalog API operations (e.g., GetTable, GetDatabase) but does not filter data at the row level. Option C (Athena named query) is not an access control mechanism — the data scientist could still run her own queries without the WHERE clause; named queries are just saved queries, not enforced restrictions. Option D (IAM S3 condition keys) can restrict access to specific S3 prefixes or objects by tag, but S3 object tags operate at the object (file) level, not at the row level within a Parquet or ORC file. This would not achieve row-level filtering within a table.

Least privilege mandates granting only the permissions required for the specific task. The Glue job needs to READ from the raw bucket (s3:GetObject, s3:ListBucket) and WRITE to the processed bucket (s3:PutObject). No other S3 permissions are needed. Option A (AmazonS3FullAccess) grants read/write/delete access to all S3 buckets in the account—far exceeding what the job needs and violating least privilege. Option C (s3:* on both buckets) similarly grants excessive permissions including delete, ACL changes, and bucket configuration, and the AWSGlueServiceRole managed policy is designed for the AWS Glue service role, not a scoped job execution role. Option D adds s3:DeleteObject on both buckets, which the job does not need and should not have—especially on the raw data bucket where accidental deletion could be catastrophic.

AWS Secrets Manager is designed exactly for this use case: it stores credentials securely, supports automatic rotation on a configurable schedule (e.g., every 30 days) using Lambda functions, and provides an API that applications can call at runtime to retrieve the latest secret — requiring no code changes when rotation occurs. Option A (job parameters) exposes credentials in plaintext in logs and the Glue console, is insecure, and does not support automatic rotation. Option B (KMS-encrypted S3 file) adds some encryption protection but still requires a manual process to update the file when credentials rotate, and the file itself is an additional artifact to manage securely. Option D (IAM database authentication) is a valid approach for passwordless RDS access using short-lived tokens, but the question explicitly states credentials that rotate every 30 days, which aligns with Secrets Manager's rotation model; also, IAM DB auth tokens expire in 15 minutes and are not stored — a different mechanism entirely.

Apache Iceberg's ACID-compliant DELETE operation is purpose-built for this use case. When you issue a DELETE for a specific customer ID, Iceberg writes positional or equality delete files that logically remove those records immediately — without rewriting the entire underlying Parquet files. Periodic compaction (expire snapshots + rewrite data files) then physically removes the data. This minimizes reprocessing overhead while meeting the 30-day physical deletion window required by GDPR. Option A (Athena CTAS to recreate entire dataset) would work but requires rewriting ALL data across thousands of objects for every erasure request — the compute and storage cost at petabyte scale is prohibitive and is the opposite of 'least reprocessing overhead.' Option C (DynamoDB 'deleted customers' filter at query time) is a soft-delete/suppression pattern. It does NOT physically delete the data, which means the customer's records still exist in S3 in plaintext. GDPR's right to erasure requires actual deletion of the personal data, not just suppression from query results. Option D (S3 Object Lock + Governance bypass for individual objects) fundamentally misunderstands the problem: Object Lock is designed to PREVENT deletion, not facilitate it. Furthermore, customer data is typically spread across many Parquet files that contain records from many customers — you cannot delete individual rows by deleting entire S3 objects without destroying other customers' data.