If you do not control who can access your machine learning data and models, you could accidentally expose sensitive customer information, have your models tampered with, or incur unexpected costs from unauthorised resource usage. AWS IAM (Identity and Access Management) and data protection tools give you the power to define exactly who is allowed to do what with your ML assets, and they ensure that even if someone gains access, the data itself remains unreadable without the proper keys. This chapter explains the core concepts that every AIF-C01 candidate must understand to protect ML workloads on AWS.
Jump to a section
A simple way to picture AWS IAM and Data Protection for ML
A secure apartment building on a busy city street. The front desk is your IAM (Identity and Access Management) system, and the building manager is the AWS account owner.
You arrive to visit your friend in apartment 3B. The security guard checks your ID, confirms your name matches the visitor list (authentication), and then issues you a temporary keycard that only unlocks the front door and the door to the 3rd floor corridor (authorisation). You cannot enter the basement gym, the rooftop, or apartment 5A because your keycard simply won't open those doors. If you try to force them, the guard receives an alert and can deactivate your keycard instantly.
Now imagine the building contains sensitive data — not just apartments, but an AI model training lab on floor 2. The guard uses a policy book: 'Only senior residents with a special badge may enter the lab.' An ML engineer on the team has that badge; a data analyst does not. If the engineer leaves the company, the building manager deletes their profile from the system, so their badge stops working immediately. The guard never hands out spare keys; instead, each person gets a unique, time-limited credential. This is exactly how AWS IAM works: you define who can access which AWS resource (like an S3 bucket storing ML models) and what they can do (read, write, delete) using policies.
Additionally, the building has a special safe in the manager's office where important documents are stored encrypted. Only the manager holds the physical key to the safe (like AWS KMS keys), and documents are scrambled so even if someone steals them, they cannot read them without the key. The guard also keeps an audit log of every door opening, every failed attempt, and every keycard deactivation — just like AWS CloudTrail logs every API call against your ML resources.
AWS Identity and Access Management (IAM) is a service that lets you control access to AWS resources. A 'resource' is anything you create in AWS — like a storage bucket (Amazon S3 bucket), a virtual server (Amazon EC2 instance), or a machine learning model stored in SageMaker. Without IAM, anyone with your AWS account credentials could do anything: delete all your data, spin up expensive GPU instances, or steal your trained models. IAM solves that by letting you create separate users, groups, and roles, each with specific permissions.
An IAM user is a digital identity that represents a person or an application that needs to interact with AWS. You assign that user a set of credentials — typically a password for the AWS Management Console (the web interface) or access keys for programmatic access (using code or tools). A best practice is to never use the root user (the account owner) for everyday tasks. Instead, create individual IAM users and give them only the permissions they absolutely need. This is called the principle of least privilege.
Permissions are granted through policies. An IAM policy is a JSON document that lists allowed or denied actions on specific resources. For example, a policy might say: 'Allow the user to call the sagemaker:CreateTrainingJob action on any resource tagged with Department=ML'. JSON stands for JavaScript Object Notation, but you do not need to write it from scratch — AWS provides pre-built policy templates. When you attach a policy to a user, that user can perform the listed actions. You can attach policies to groups (which are collections of users) to manage permissions in bulk.
An IAM role is similar to a user, but it is not associated with a specific person. Instead, an AWS service like SageMaker or an EC2 instance assumes the role to gain temporary permissions. For instance, when a SageMaker notebook instance needs to read training data from an S3 bucket, you attach a role with the necessary read permissions to that notebook instance. The notebook instance 'assumes' the role and can access the data without needing static credentials stored in a file. This is much more secure because the credentials are automatically rotated and never hard-coded.
Now let's talk about data protection. Even if you control who accesses a resource, the data within that resource could still be exposed if it is stored in plain text. Encryption scrambles data so that only someone with the correct decryption key can read it. AWS offers two main types: encryption at rest (protecting data stored on disk) and encryption in transit (protecting data while it travels over the network).
AWS Key Management Service (KMS) is the service that manages the encryption keys. KMS lets you create, rotate, and delete keys. You can choose to have AWS manage the keys (AWS managed keys) or you can create your own customer managed keys. For ML workloads, you often need to encrypt data in S3 buckets, model artifacts in SageMaker, and even the communication between services. By using KMS, you centralise key management and audit every use of a key through AWS CloudTrail.
Access Control Lists (ACLs) are another way to manage permissions, but they are more granular and less flexible than IAM policies. For S3 buckets, you can use bucket policies (a type of IAM policy attached directly to the bucket) instead of ACLs. Bucket policies are easier to audit and scale.
Another important concept is the shared responsibility model. AWS is responsible for the security of the cloud (the physical data centres, network infrastructure, hypervisor). You, the customer, are responsible for security in the cloud (configuring IAM policies, managing keys, encrypting data). For the AIF-C01 exam, you must understand that no matter how secure AWS makes its infrastructure, if you misconfigure an IAM policy to allow public access to an S3 bucket containing a trained model, that data is exposed.
Services like AWS CloudTrail record every API call made in your account, including who made the call, from which IP address, and what action was attempted. This helps you audit who accessed your ML resources. Amazon GuardDuty can also detect suspicious behaviour, such as an IAM user accessing a SageMaker endpoint from an unexpected location.
For ML specifically, you will often use SageMaker with IAM roles to grant training jobs access to data, and you will use KMS to encrypt model artifacts. You need to know how to set up a SageMaker notebook instance with a role that can read from an S3 bucket, and how to enable encryption at rest for that bucket. The exam expects you to recognise that you should never embed access keys into code or notebooks — always use roles.
Finally, there is a concept called resource-based policies. Some AWS services, like S3 and SQS, allow you to attach a policy directly to the resource (like a bucket) rather than to a user. This is useful when you want to allow another AWS account to access your resource. In an ML context, you might use a resource-based policy to let a data science team from another department access your training dataset.
Identify your ML resources
List all the AWS resources involved in your ML pipeline: S3 buckets for data and models, SageMaker notebook instances, training jobs, endpoints, and any other services like DynamoDB or Lambda. This helps you understand what needs protecting.
Define who needs access
Identify users (data scientists, ML engineers, auditors) and services (SageMaker, Lambda, CloudWatch). Decide what actions each should be allowed to perform. For example, a data scientist needs read/write access to the S3 bucket with training data, but only read access to the model artifacts bucket.
Create IAM users and groups
Create an IAM user for each person and add them to groups like 'DataScientists' or 'MLOps'. Assign policies to groups rather than to individuals. This makes permission management scalable and reduces the chance of misconfiguration.
Create IAM roles for AWS services
For each AWS service that needs to act on your behalf (like a SageMaker training job or an EC2 instance), create a dedicated IAM role. Attach a trust policy that allows only that specific service to assume the role, then attach permissions policies that grant exactly the required access to resources.
Encrypt data at rest and in transit
Enable encryption at rest on all S3 buckets using AWS KMS customer managed keys. For SageMaker, specify the same key when creating notebook instances and training jobs. For encryption in transit, enforce HTTPS for all connections by adding a bucket policy that denies HTTP requests, and ensure all endpoints use TLS.
Enable auditing and monitoring
Turn on AWS CloudTrail to record every API call. Configure Amazon GuardDuty to detect unusual activity. Set up Amazon CloudWatch alarms for events like a sudden spike in SageMaker training job start requests or an IAM user accessing a model from an unrecognised IP address.
Test and iterate
Ask a colleague to perform typical tasks (like launching a notebook or uploading data) and verify that the IAM policies allow the intended actions but block unintended ones. Review CloudTrail logs to ensure no unauthorised attempts occurred. Adjust policies as needed.
A mid-sized healthcare company, HealixML, uses AWS to train and deploy machine learning models that predict patient readmission risk. Their ML pipeline involves: a SageMaker notebook instance for data exploration, an S3 bucket for storing raw electronic health records (EHRs), a SageMaker training job that runs every night, and a SageMaker endpoint for real-time predictions. The company's security team has mandated that all data must be encrypted at rest and in transit, and access must follow least privilege.
Here is how the IT professional (in this case, a cloud architect named Priya) sets up IAM and data protection for this pipeline:
Priya creates an IAM role named 'SageMaker-Execution-Role'. This role has policies that allow it to read from the specific S3 bucket containing EHRs, write model artifacts to a separate 'models' bucket, and log results to CloudWatch. She attaches the AWS managed policy 'AmazonSageMakerFullAccess' but also adds a custom policy that restricts S3 access to only the two necessary buckets.
She creates an IAM user for each data scientist. Each user has console access (with multi-factor authentication enabled) and belongs to a group called 'DataScientists'. The group policy grants permissions to list SageMaker notebook instances, start and stop them, but not to delete them or modify IAM roles.
For the nightly training job, Priya configures the training job to assume the 'SageMaker-Execution-Role'. She does not hard-code any credentials. The training job launches on a temporary EC2 instance, runs the training script, and terminates. The instance obtains temporary credentials from the role, which are valid only for the duration of the job.
She enables encryption at rest on the S3 bucket using an AWS KMS customer managed key. This key is also specified when creating the SageMaker notebook instance and the training job. Only the 'SageMaker-Execution-Role' is granted permission to use the key.
For encryption in transit, Priya ensures that the SageMaker endpoint uses HTTPS (TLS) for all inference requests. She also configures the S3 bucket to require HTTPS for all connections (bucket policy denying HTTP requests).
She sets up AWS CloudTrail to log all API calls, and Amazon GuardDuty to alert on any suspicious activity, such as an attempt to download the model artifact from an unusual IP.
Finally, she creates a simple lifecycle configuration script for the notebook instance that automatically stops the instance after an hour of inactivity, preventing runaway costs.
This setup ensures that the company's sensitive health data is encrypted, access is tightly controlled, and every action is auditable. No data scientist can accidentally delete the raw data or expose the model. When the team grows, Priya simply adds new users to the 'DataScientists' group, and they automatically inherit the correct permissions. She regularly reviews the CloudTrail logs to ensure no unexpected access patterns have emerged.
The AIF-C01 exam (Exam 2.2) specifically tests your understanding of how to apply IAM policies, encryption, and access controls to protect ML data and models. Expect 3-5 questions on this topic, often in scenario-based format.
Key concepts the exam loves to test:
The difference between an IAM user, an IAM role, and an IAM group. They will present a scenario like 'A SageMaker training job needs to read data from S3' and ask which entity to use. The correct answer is always an IAM role, not a user or group, because roles provide temporary credentials for services.
Principle of least privilege: The exam will give you a list of permissions and ask which is the most secure. The trap answer often gives 'FullAccess' or overly broad permissions. The correct answer limits actions to only what is needed.
Encryption types: Be able to differentiate between encryption at rest (protects data on disk) and encryption in transit (protects data over the network). The exam might ask: 'Which AWS service manages encryption keys?' Answer: AWS KMS.
Resource-based policies vs identity-based policies: When the question involves granting access to a resource (like an S3 bucket) to another AWS account, the correct approach is a resource-based policy (bucket policy).
Shared responsibility model: A common trap question asks who is responsible for encrypting the data in an S3 bucket. The answer: the customer (you) is responsible, because AWS provides the tools but you must configure them.
Data protection specifically for ML: The exam will ask how to protect a trained model stored in an S3 bucket. The correct answer involves enabling S3 server-side encryption with KMS and restricting bucket access via IAM policies.
CloudTrail and GuardDuty: Questions will ask which service provides an audit trail of who accessed a resource (CloudTrail) and which service detects suspicious activity (GuardDuty).
Common traps:
Thinking that the root user should be used for daily tasks (wrong — never use root for daily tasks).
Believing that encryption in transit is optional for internal services (wrong — always required for sensitive data).
Assuming that if an IAM user has access to a key, data is automatically secured (not true — the user must also have decrypt permissions).
Key definitions to memorise:
IAM: Identity and Access Management — controls who can do what with AWS resources.
KMS: Key Management Service — manages encryption keys.
Policy: a JSON document that defines permissions.
Role: an identity with temporary permissions assumed by AWS services.
Least privilege: granting only the minimum permissions needed.
The exam will also test your understanding of which combination of services is needed for a secure ML pipeline. For example: 'You need to store training data encrypted at rest, allow SageMaker to read it, and log all access.' The correct answer would involve KMS for encryption, an IAM role for SageMaker to assume, and CloudTrail for logging.
Least privilege means you grant only the permissions required to perform a specific task, nothing more.
Always use an IAM role for AWS services like SageMaker or EC2, never hard-code long-term credentials.
Encryption at rest protects data stored on disk, while encryption in transit protects data moving across the network.
AWS KMS lets you centrally manage encryption keys and audit their usage through CloudTrail.
An explicit Deny in any policy overrides an Allow — the Deny always wins.
The shared responsibility model means AWS secures the cloud, but you must configure tools like IAM and KMS to secure your data in the cloud.
CloudTrail logs all API calls, giving you a complete audit trail of who accessed your ML resources and when.
Never use the AWS root user for everyday tasks — create individual IAM users with multi-factor authentication.
These come up on the exam all the time. Here's how to tell them apart.
IAM User
Represents a specific person or application with long-term credentials.
Has a password (console) or access keys (programmatic) that do not expire automatically.
Best for human users or long-running services that need persistent access.
IAM Role
An identity assumed temporarily by an AWS service or federated user.
Provides short-term, automatically rotated credentials via AWS STS.
Best for EC2 instances, Lambda functions, and SageMaker jobs.
Encryption at Rest
Protects data stored on disk (e.g., S3 objects, EBS volumes).
Uses KMS keys or S3-managed keys to encrypt data before writing.
Does not protect data while it is being moved between services.
Encryption in Transit
Protects data travelling over the network (e.g., HTTPS, TLS).
Encrypts data between client and server or between AWS services.
Does not protect data once it is stored on disk.
Identity-Based Policy
Attached to an IAM user, group, or role.
Specifies what actions the identity can perform on which resources.
Cannot grant access to users from other AWS accounts directly.
Resource-Based Policy
Attached directly to a resource like an S3 bucket or SQS queue.
Specifies who (which identities or accounts) can access the resource.
Can grant access to principals in other AWS accounts.
AWS Managed Key (KMS)
Created and managed by AWS on your behalf.
Cannot be modified; rotated automatically every 1 year.
Less control, but simpler to set up.
Customer Managed Key (KMS)
You create, manage, and control the key lifecycle.
You can configure rotation schedule, import own key material, and define key policies.
More control, suitable for compliance requirements.
CloudTrail
Records API call history (who, what, when, from where).
Used for security auditing and compliance.
Does not analyse or detect threats automatically.
GuardDuty
Analyses logs and other telemetry for suspicious activity.
Uses machine learning to detect threats like compromised credentials.
Generates alerts but does not permanently store raw logs.
Mistake
Once I encrypt the S3 bucket with KMS, the data is completely secure and I don't need to worry about IAM policies.
Correct
KMS encrypts the data at the storage layer, but IAM policies still control who can access the bucket and the decryption keys. Without an IAM policy that grants decrypt permission, even encrypted data is inaccessible.
Beginners often assume encryption is a silver bullet, but access control is a separate layer. The exam tests that both are needed together.
Mistake
An IAM role and an IAM user are basically the same — both are identities that can access AWS resources.
Correct
An IAM user represents a person or application with long-term credentials (password or access keys). An IAM role is an identity that is assumed temporarily by an AWS service or a trusted entity, providing short-term security credentials.
The terms 'user' and 'role' are used loosely in everyday speech, but the exam differentiates them strictly. Many beginners confuse them because both involve permissions.
Mistake
You can use the same IAM role for both an EC2 instance and a SageMaker notebook instance without any changes.
Correct
Each AWS service needs a trust policy that explicitly allows that service to assume the role. A role created with a trust policy for EC2 cannot be assumed by SageMaker unless the trust policy is updated to include SageMaker as a trusted entity.
Beginners think roles are universal; they do not realise that trust policies define which services can use the role. This is a frequent trick on the exam.
Mistake
If you set an S3 bucket policy to 'Deny all' and then attach an IAM policy that allows a user, the user will have access.
Correct
An explicit Deny in a bucket policy overrides any Allow from IAM policies. The Deny always wins. So the user would be blocked.
This is a classic exam trap. Beginners assume that Allow always wins, but AWS evaluates policies with an explicit Deny as the highest priority.
Mistake
Encryption in transit is optional because the AWS internal network is already private.
Correct
Encryption in transit (using TLS/HTTPS) is essential to protect data from being intercepted as it travels between services, even within the AWS network. The exam expects you to require it for sensitive data.
Many beginners assume that inside AWS, the network is fully secure. But traffic between availability zones or across accounts can still be vulnerable if not encrypted.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IAM user represents a specific person or application with long-term credentials (password or access keys). An IAM role is an identity assumed temporarily by an AWS service or trusted entity, providing short-term, automatically rotated credentials.
You attach an IAM role to the SageMaker notebook instance. The role must have a trust policy that allows SageMaker to assume it, and a permissions policy that grants the required S3 actions (e.g., s3:GetObject) on the specific bucket.
No, you must enable it. You can choose server-side encryption with S3-managed keys (SSE-S3) or with KMS keys (SSE-KMS). The exam expects you to know how to set this up and that KMS gives more control.
AWS is responsible for the security of the cloud (physical infrastructure, network, hardware). You are responsible for security in the cloud (data, IAM configurations, encryption, OS patches on your EC2 instances).
Yes, you can reuse the same role for multiple training jobs, as long as the job needs the same permissions. It's best practice to create one role per logical set of permissions (e.g., one for training, one for inference).
The notebook instance will lose its ability to access any AWS resource (like S3) because it no longer has valid credentials. You must create a new role with the same permissions and reassign it to the notebook.
You've finished AWS IAM and Data Protection for ML. Continue through the AIF-C01 study guide to build a complete picture of the exam.
Done with this chapter?