AWS DEA-C01: Data Security and Governance Practice Questions

Enabling S3 Block Public Access at the account level applies four settings (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) to all current and future buckets in one action, providing a single authoritative control. This overrides any bucket-level policy or ACL that would otherwise grant public access. An SCP restricting s3:PutBucketPolicy would prevent creation of bucket policies but would not block public access granted via ACLs, and it does not cover existing policies. Attaching a bucket policy to every bucket is operationally burdensome and does not prevent future buckets from being created without such a policy. Amazon Macie is a data discovery and classification service; it can alert on public buckets but does not automatically remediate them.

An AWS KMS customer-managed key (CMK) gives the company full control over the key policy, including who can use or manage the key. Enabling automatic key rotation on a CMK rotates the backing key material annually; KMS transparently re-wraps the Redshift cluster's data encryption key without any re-encryption of the actual cluster data. AWS managed keys (aws/redshift) are controlled by AWS, not the company, so the company does not 'fully control' them, and rotation is automatic but the key policy is not customer-managed. CloudHSM provides hardware-level key management but requires significantly more operational overhead; scheduling Lambda for key rotation does not integrate natively with Redshift's encryption workflow. Redshift's built-in encryption requires KMS or CloudHSM and has no standalone annual rotation mechanism via parameter groups.

Lake Formation data filters support both column-level security and row-level security through a row filter expression (e.g., region = 'US-EAST'). When attached to a GRANT statement for the analyst's IAM principal, only matching rows are returned. Column-level permissions restrict which columns are visible but do not filter rows, so the analyst would still see rows for other regions. An IAM policy with an s3:prefix condition restricts S3 object access but does not enforce row-level filtering within a Glue-cataloged table, and Lake Formation fine-grained access would still need to be configured. A Glue Data Catalog resource policy controls access to catalog metadata itself (databases, tables), not the row-level contents of the underlying data.

When AWS Lake Formation is enabled and the account has moved beyond the legacy IAM-only access model, Lake Formation acts as an authorization layer on top of the Glue Data Catalog. Even if a user has full IAM permissions to Glue, they will not be able to see or query a table unless Lake Formation has granted them at least SELECT (and the parent database's DESCRIBE) permissions. The 'Table not found' error is Lake Formation's way of hiding tables from unauthorized principals. A corrupt crawler output (Option A) would show the table as broken or absent from the catalog, not as 'not found' for specific users while visible to others. Athena workgroup permissions (Option C) control query result locations and cost controls, not catalog table visibility. S3 Block Public Access settings (Option D) affect public access to objects and would cause query execution failures, not a 'Table not found' error at the metadata level.

Lake Formation column-level permissions allow an administrator to explicitly GRANT SELECT on specific columns of a Glue Data Catalog table to a given IAM principal. When junior analysts query through Athena, Lake Formation enforces the column-level access; the excluded columns are simply not returned. This is enforced at the catalog layer and cannot be bypassed by crafting a different query. Creating separate S3 prefixes (Option A) requires physically duplicating or transforming data, adds storage costs, and is operationally complex to maintain as schemas change. An Athena saved query view (Option C) is not a security control—a determined user can query the underlying table directly, bypassing the view. A KMS key policy (Option D) controls decryption at the object level but cannot selectively restrict access to individual columns within a Parquet or ORC file.