In our MLA-C01 question bank, about 40 questions deal with security and compliance, one of the largest groups of all. Task 4.3 of the exam guide covers IAM roles, policies, and bucket policies, SageMaker security and compliance features, network access controls for ML resources, and CI/CD pipeline security, while Task 1.3 adds compliance requirements such as data encryption, classification, anonymization and masking, PII, PHI, and data residency. Questions usually give you conditions like "must comply with HIPAA" or "must not traverse the internet" and ask you to combine several settings.
This post splits ML security into four layers (network, encryption, permissions, and auditing) and lays out the SageMaker settings for each, then moves on to handling sensitive data, CI/CD and secrets management, and assembling a HIPAA scenario. The big picture of security was covered first in Model Monitoring, Cost Optimization, and Security.
---
Split Security into Four Layers
To protect a bank vault, you control who enters the building (network), lock the vault (encryption), decide who holds the keys (permissions), and record everything on CCTV (auditing). If any one is missing, the whole system gets weaker. The options in security questions usually come one from each of these four layers.
| Layer | Question it answers | Typical settings | |------|------|------| | Network | Which path does the data travel? | VPC, VPC endpoints, network isolation, security groups | | Encryption | Is stolen data unreadable? | KMS (data at rest), TLS and inter-container encryption (in transit) | | Permissions | Who can do what? | IAM execution roles, least privilege, condition keys, bucket policies | | Auditing | Who did what, and when? | CloudTrail, CloudWatch Logs, AWS Config |
!The four layers of ML security, network, encryption, permissions, and auditing, with the typical AWS settings for each
---
Layer 1, Network: VPCs, VPC Endpoints, and Network Isolation
Running SageMaker Jobs Inside a VPC
When you create a training job, a processing job, or a model (endpoint), specifying private subnets and security groups in VpcConfig runs the containers inside your VPC. Without a path to the internet (a NAT gateway), the containers cannot reach S3 either, so you must create an S3 gateway VPC endpoint for them to read training data and write model artifacts.
| Requirement | Setting | |------|------| | Training containers reach S3 without the internet | S3 gateway VPC endpoint | | Apps in the VPC invoke the endpoint without the internet | SageMaker Runtime interface endpoint (PrivateLink) | | Call the SageMaker API (create jobs, etc.) from inside the VPC | SageMaker API interface endpoint (PrivateLink) | | Access from on premises without the internet | Direct Connect (or VPN) + interface endpoints | | The bucket accepts only requests coming through our VPC endpoint | aws:SourceVpce condition in the bucket policy |
Network Isolation: Cut Off the Container's Outbound Traffic Entirely
With EnableNetworkIsolation turned on, training and inference containers cannot make outbound calls to anything, including S3, and no AWS credentials are made available inside the container. Training still works, because SageMaker downloads data from S3 and uploads results outside the container using the execution role. Use it to prevent data exfiltration by code whose origin you cannot fully verify, or by AWS Marketplace algorithms (isolation is required for Marketplace resources).
Inter-Container Traffic Encryption
In distributed training across several instances, the instances exchange information such as weights. If a requirement says this traffic must be encrypted too, turn on inter-container traffic encryption. It is a recommended best practice in healthcare, but it can increase training time and cost for distributed deep learning.
Exam tip: "Training data must not traverse the internet" is private subnets + an S3 gateway endpoint, "unverified training code must not be able to send data out" is network isolation, and "encrypt the traffic between distributed training nodes too" is inter-container traffic encryption.
---
Layer 2, Encryption: KMS and Encryption in Transit
Data at Rest: Where to Specify the Key
| Target | Where to set it | |------|------| | Training data and model artifacts in S3 | Default bucket encryption (SSE-KMS) and the job's output KMS key | | Storage volumes of training and processing instances | The job's volume KMS key | | Storage volumes of endpoint instances | The KMS key in the endpoint configuration | | Feature Store | KMS keys for the online store and the offline store (S3) |
SSE-S3 is the simplest option, where AWS manages the keys entirely, while SSE-KMS encrypts with a KMS key and records key usage in CloudTrail. Among those, a customer managed key (CMK) lets you decide through the key policy who may use the key, turn on automatic rotation, and disable the key to block access to the data immediately.
KMS Permissions Are Checked in Two Places
To read data encrypted with a customer managed key, access must be allowed in both the IAM policy and the key policy. If a training job fails with "AccessDenied" even though its S3 permissions are sufficient, check whether the execution role is missing kms:Decrypt (for reads) or kms:GenerateDataKey (for writes), and whether the key policy allows that role.
Encryption in Transit
Calls to AWS APIs and endpoints are encrypted with TLS (HTTPS). Adding a statement to the bucket policy that denies requests where aws:SecureTransport is false blocks unencrypted access.
Exam tip: "Audit key usage and directly control key rotation and access" is a customer managed KMS key. "S3 permissions are in place, but the encrypted objects cannot be read" means the KMS key policy or the kms:Decrypt permission is missing.
---
Layer 3, Permissions: Execution Roles and Least Privilege
Separate the Roles of People from the Role of SageMaker
The SageMaker execution role is the role that training jobs and endpoints use to access S3, ECR, and CloudWatch. Create it separately from the roles of people (data scientists, MLOps engineers), and give the people who create jobs only the iam:PassRole permission they need to hand that execution role over.
| Technique | What it does | Example | |------|------|------| | Role separation | Only the permissions each person and service needs | Data scientists only train, MLOps also deploys | | Resource-level permissions | Allow only specific buckets, prefixes, or models | Team A gets only s3://data/team-a/ | | Enforcing condition keys | Deny job creation outright without the security settings | sagemaker:VpcSubnets, sagemaker:VolumeKmsKey, sagemaker:NetworkIsolation | | Bucket policies | Restrict principals and paths on the bucket side | Only a specific role in another account, only through the VPC endpoint |
Condition keys let you enforce security settings, for example so that "a training job without VPC subnets and a KMS key cannot be created at all." To apply the same rule across many accounts, use service control policies (SCPs) in AWS Organizations.
SageMaker Role Manager, which created roles per persona, no longer accepts new customers. AWS points to a combination of native IAM tools, IAM Identity Center, and infrastructure as code such as CloudFormation and the CDK as the replacement.
Exam tip: "Prevent data scientists from creating training jobs without the security settings" is the SageMaker condition keys in IAM policies.
---
Layer 4, Auditing: CloudTrail, CloudWatch, and AWS Config
| Tool | Question it answers | Use in ML security | |------|------|------| | CloudTrail | Who called which API, and when? | Tracking endpoint configuration changes, model deletions, key usage | | CloudWatch Logs | What happened inside the container? | Training and inference logs, causes of errors | | AWS Config | Does the current configuration follow the rules? | Managed rules such as whether a KMS key is set in endpoint configurations or notebooks have direct internet access |
By default, CloudTrail keeps management events in its event history for 90 days. To keep them longer, create a trail that delivers to S3, and if tampering must be prevented, add S3 Object Lock and log file integrity validation. There is an exam trap here. Inference calls such as InvokeEndpoint are data events, so they are not recorded by default. If inference calls must be audited, you have to turn on data event logging separately, which costs extra, and the request body (the input data) is not recorded.
Exam tip: "Who changed the endpoint configuration" is CloudTrail, "automatically find SageMaker resources that break the rules" is AWS Config, and "audit logs must not be modifiable or deletable" is S3 Object Lock.
---
Handling Sensitive Data: Find It, Mask It, Keep It in Region
| Tool | What it does | Target | |------|------|------| | Amazon Macie | Automatically discovers and classifies sensitive data such as personal data in S3 buckets | S3 objects | | Comprehend PII | Detects personal data in text and produces redacted copies | English and Spanish text | | AWS Glue sensitive data detection | Finds personal data columns during ETL and masks or hashes them | Data pipelines | | Redshift dynamic data masking | Masks query results according to the querying user's role | Data warehouse | | Lake Formation | Controls access at the column and row level | Data lake tables |
Anonymization removes direct identifiers such as names and national ID numbers, replaces them with hashes or tokens, or groups values such as age into ranges (generalization). Data residency requirements (data must not leave a certain country) are met by keeping S3 buckets and SageMaker resources only in that Region and not using cross-Region replication.
Exam tip: "We do not know which of thousands of buckets hold objects with personal data" is Macie. "Show the analyst role onl