DEA-C01 Column-level security Practice Question
A company uses Amazon Redshift for its data warehouse and needs to enforce column-level security on sensitive columns. Which TWO approaches can achieve this?
⚠ Common exam trap
DEA-C01 often tests the confusion between row-level security (filters rows) and column-level security (restricts columns), and the misconception that S3 bucket policies or Spectrum external schemas can enforce column-level access inside Redshift tables.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create views that expose only non-sensitive columns and grant access to the views.
Option B is correct because creating views that expose only non-sensitive columns and granting users access to those views (rather than the base tables) is a standard Redshift pattern for column-level security: users query the view and cannot see the restricted columns. Option D is correct because Amazon Redshift natively supports column-level access control via GRANT and REVOKE on individual columns (for example, GRANT SELECT(col1, col2) ON table TO user), which directly enforces column-level security. Option A is wrong because an S3 bucket policy governs access to objects in S3, not to columns within Redshift tables, and does not control SQL-level column visibility. Option C is wrong because Redshift Spectrum external schemas and tables do not provide a column-restriction mechanism for enforcing column-level security on Redshift data. Option E is wrong because Redshift row-level security (RLS) policies filter which rows a user can see, not which columns they can access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Apply an S3 bucket policy to the underlying data files.
Why it's wrong here
S3 bucket policies govern access to objects, not individual Redshift columns, so they cannot enforce column-level grants inside the warehouse. They are tempting because they secure the underlying data at rest, which is the right control when the requirement is protecting raw files rather than query-time column masking.
- ✓
Create views that expose only non-sensitive columns and grant access to the views.
Why this is correct
Views restrict the projection to non-sensitive columns, so grantees query only exposed attributes; the underlying sensitive columns remain inaccessible through the view. This delivers column-level security by omission, satisfying the requirement without granting base-table access.
- ✗
Use Redshift Spectrum to query external tables and restrict columns via the external schema.
Why it's wrong here
Spectrum external schema grants control access to external tables, not to individual columns of native Redshift tables, so it cannot enforce column-level security here. It is tempting because Spectrum supports fine-grained Lake Formation permissions, which is correct when the sensitive data resides in external tables in Amazon S3.
- ✓
Use Redshift column-level security to grant or revoke permissions on specific columns.
Why this is correct
Redshift's native column-level access control lets you GRANT or REVOKE SELECT on individual columns, directly satisfying the stem's requirement to enforce column-level security on sensitive columns. Privileges are managed per column via SQL, so users see only permitted columns without views or masking.
- ✗
Use Redshift row-level security policies to restrict column access.
Why it's wrong here
Row-level security filters which rows a user sees; it does not restrict column access, so it cannot satisfy the column-level requirement. It is tempting because it is a Redshift-native access control, and it would be correct where the requirement is limiting users to specific rows, such as per-region data.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This DEA-C01 question is part of Courseiva's 1,321-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DEA-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DEA-C01 exam.