An AI system is only as trustworthy as the data it learns from and reads at run time. Secure data engineering means four things: checking that the data is good, hiding personal details people don't need, letting each person see only the data their job requires, and proving the data hasn't been changed. This lesson covers each of these and the AWS features that support them. On the exam, the scenario's main worry decides which one is the answer.
Data quality comes first
Bad data quietly becomes a bad model. Missing values, impossible numbers (an age of 250) or duplicated records all distort training and retrieval. The safest place to catch them is in the data pipeline, before anything reaches a training set or a knowledge base.
AWS Glue Data Quality lets a team write rules about what good data looks like, for example "this column is never empty" or "values fall in this range". It can also suggest starting rules by analysing the data. Each run produces a data quality score, the share of rules that passed. Inside a Glue ETL job, it can pick out the exact records that failed, so the team can quarantine them before loading. It also offers machine learning-based anomaly detection for problems that are hard to write rules for.
Privacy-enhancing technologies
Privacy-enhancing technologies reduce how much personal information people and models can see, while keeping the data useful. Common techniques include:
| Technique | What it does | Keeps joins working? |
|---|---|---|
| Masking out | Hides part of a value, such as all but the last four digits | No |
| Nulling out or deletion | Removes the value entirely | No |
| Hashing or deterministic encryption | Turns each value into the same stand-in every time | Yes |
| Probabilistic encryption | Produces a different result each time | No |
| Differential privacy | Adds calibrated noise to query results so no individual can be singled out | Not a row-level technique |
AWS Glue DataBrew can detect personal information during data preparation and apply most of these techniques, including substitution, shuffling, hashing and both kinds of encryption. AWS Clean Rooms Differential Privacy adds noise to aggregate query results when organisations analyse shared data together.
Access control on the data itself
Even cleaned data shouldn't be open to everyone. AWS Lake Formation controls access to tables in a data lake at a fine level:
- Column-level security hides chosen columns, such as a national ID number.
- Row-level security shows only rows matching a condition, such as one region's customers.
- Cell-level security combines the two, hiding particular columns only for particular rows.
This follows least privilege: each person, and each AI pipeline, gets only the data its task needs.
Data integrity
Integrity means proving the data is exactly what it was. For training data, this matters when an auditor asks what a model was trained on, or when someone might tamper with the data to poison a model.
- Checksums. Amazon S3 calculates a checksum on upload, and can recheck stored objects, so any change or corruption shows up.
- S3 Object Lock. Stores objects in a write-once, read-many way, so they can't be overwritten or deleted for a set retention period. In compliance mode, not even the account's root user can remove the lock early.
- Versioning and access logs. These show who changed what and when.
On the exam
Match the worry to the control. "Hide a column from most users" points to Lake Formation. "Stop bad records before training" points to Glue Data Quality. "Analysts must join records without seeing real IDs" points to hashing or deterministic encryption. "Prove the training data never changed" points to S3 Object Lock and checksums. Amazon Macie finds sensitive data in S3, but it doesn't mask, filter or lock anything.