Your company's most sensitive customer data — payment details, medical records, sales figures — could be accidentally deleted or maliciously stolen by a single wrong click. That is the real-world consequence of ignoring how to control access to data on AWS. For the DEA-C01 exam, you must prove you can write and attach IAM policies to protect data stores like S3, DynamoDB, and Redshift, so only the right people and services can touch the right data at the right time.
Jump to a section
A simple way to picture IAM Policies and Data Access Control for AWS Data Services
3 envelopes sit on your desk. One is addressed to your landlord, one to your doctor, and one to your friend. Each envelope has a specific stamp: a red 'PAID' stamp for the landlord's rent cheque, a blue 'MEDICAL' stamp for the doctor's appointment request, and a green 'PERSONAL' stamp for your friend's birthday card. You cannot send the birthday card with the 'PAID' stamp; the post office will reject it because the stamp doesn't match the letter's purpose.
Now, 3 different people want to post letters through your letterbox. Your neighbour wants to post a parcel, the postman wants to deliver a bill, and your cousin wants to drop off a house key. You give each person a different coloured key to your front door. The neighbour gets a yellow key that only works between 9am and 5pm. The postman gets a blue key that only opens the letterbox flap. Your cousin gets a green key that opens the whole door. Each key is a 'policy' that says exactly what that person can do, with which item, and at what time.
In AWS data services, you write these 'policies' to control who can read, write, or delete data in services like Amazon S3 or DynamoDB. A policy is a set of rules attached to a user or a service, defining the exact actions allowed on specific data resources. Just as your green key doesn't work on the letterbox, an IAM policy can say 'this user can only read files in this folder, and never delete them'.
IAM stands for Identity and Access Management. It is a free service inside AWS that lets you create 'users' (people), 'groups' (collections of people), and 'roles' (identities for services) and then attach 'policies' to them. A policy is a formal document written in JSON (JavaScript Object Notation) — a simple text format with keys and values — that lists what actions are allowed or denied on which AWS resources.
Think of a policy as a rule book. Each rule has three main parts: the 'Effect' (either Allow or Deny), the 'Action' (what you can do, like 's3:GetObject' which means read an object in S3), and the 'Resource' (exactly which bucket or table or file you can do it to). For example, a policy might say: 'Allow the action s3:GetObject on the resource arn:aws:s3:::customer-data-bucket/*'. The 'arn' is Amazon Resource Name — a unique address for every AWS resource. The '/*' at the end means 'any file inside this bucket'.
Why does this matter for data services? AWS data services like S3 (Simple Storage Service — for files), DynamoDB (a NoSQL database — for fast key-value lookups), Redshift (a data warehouse — for big analytics queries), and RDS (Relational Database Service — for traditional SQL databases) all store your precious data. Without IAM policies, either everyone in your AWS account can access everything (dangerous) or nobody can access anything (useless). Policies give you fine-grained control.
There are two main types of policies you need to know for DEA-C01:
Identity-based policies: These are attached to a user, group, or role. They say 'this identity can do X on resource Y'.
Resource-based policies: These are attached directly to the resource itself (like an S3 bucket policy). They say 'anyone who tries to access this resource must meet these conditions'.
A common exam concept is the 'least privilege principle'. This means you should give a user or role only the exact permissions they need to do their job — no more. For example, a data analyst who only needs to run SELECT queries on a Redshift database should not have permission to DELETE tables. You write a policy that allows only 'redshift-data:ExecuteStatement' with a SQL action of 'SELECT' and deny all other actions.
Another critical idea is 'conditions' in policies. A condition is an extra rule that must be true for the policy to apply. Common conditions include: 'IpAddress' (the user must be connecting from a specific IP range, like your office network), 'StringEquals' (the request must come from a specific AWS account), and 'Bool' (e.g., 'aws:SecureTransport' must be true — meaning the connection must use HTTPS).
For data services, you often combine IAM policies with 'encryption' — protecting data by scrambling it so only someone with a key can read it. AWS Key Management Service (KMS) manages these keys. You can write a policy that says 'this role can decrypt data only if they are using a specific KMS key'.
Finally, AWS evaluates policies using a logic called 'explicit deny overrides allow'. If one policy says 'allow read' but another policy says 'deny read', the deny wins — the user cannot read. This is a safety net to prevent accidental over-permissioning.
In summary: IAM policies are your barrier and gatekeeper for all AWS data services. They define identities, attach rules, and enforce conditions so your data stays secure. On the DEA-C01 exam, you will be asked to read JSON policies, identify what they do, and choose the correct policy to meet a specific security requirement.
Define the identity
Decide who or what needs access. If it is a human, create an IAM user or add them to an IAM group. If it is an AWS service like an EC2 instance or a Lambda function, create an IAM role. The identity is the 'who' in the access control equation.
Identify the data resource and required actions
Determine exactly which AWS data service the identity needs to access (e.g., an S3 bucket called 'sales-data', a DynamoDB table called 'Users', or a Redshift cluster). Then list the specific API actions required (e.g., s3:GetObject to read, dynamodb:Query to search items). This step follows the least privilege principle.
Write the policy JSON
Open the IAM policy editor and write a JSON document. Include a Statement block with Effect (Allow or Deny), Action (the list of API calls), Resource (the ARN of the data resource, often with a wildcard for sub-resources like files inside a bucket), and optionally a Condition block (e.g., IpAddress or Bool). Use the ARN format arn:aws:s3:::bucket-name/* for all objects in a bucket.
Attach the policy to the identity
If you wrote an identity-based policy, attach it to the IAM user, group, or role under the 'Permissions' tab. If you wrote a resource-based policy (like an S3 bucket policy), go to the resource's settings (e.g., S3 bucket > Permissions > Bucket Policy) and paste the JSON there. This step enforces the rules you wrote.
Test and audit the access
Use AWS's IAM Access Analyzer or the 'Policy Simulator' tool to test what actions the identity can actually perform. This step catches mistakes like missing conditions or incorrect ARNs. Regularly review policies to ensure they still follow least privilege as roles change over time.
An IT professional at a mid-sized e-commerce company, let us call her Priya, is responsible for setting up data access controls for a new analytics project. The company stores customer orders in an S3 bucket called 'orders-bucket', and a team of 5 data scientists need to read those files to build sales forecasts.
Step 1: Priya logs into the AWS Management Console and goes to the IAM service. She creates a new IAM group called 'DataScientists'. She creates 5 IAM users (one for each scientist) and adds them all to this group. This is more efficient than attaching policies to each user individually.
Step 2: Priya needs to write a policy that allows only read access to 'orders-bucket'. She opens the policy editor and writes a JSON policy that says:
- Effect: Allow - Action: s3:GetObject, s3:ListBucket - Resource: arn:aws:s3:::orders-bucket/* (for GetObject) and arn:aws:s3:::orders-bucket (for ListBucket) She also adds a condition that the request must come from the company's office IP range (192.168.1.0/24) and must use HTTPS (aws:SecureTransport is true).
Step 3: Priya attaches this policy to the 'DataScientists' group. Now every user in that group can list the files in the bucket and download them, but they cannot upload, delete, or change any files.
Step 4: A few weeks later, the company starts using a new AWS Glue job (an extract-transform-load service that runs code automatically) to clean the data before the scientists use it. The Glue job needs write access to a separate 'staging-bucket'. Priya creates an IAM role (not a user — because services, not people, need this access) called 'GlueServiceRole'. She writes a policy that allows s3:PutObject and s3:GetObject on 'staging-bucket'. She attaches this role to the Glue job configuration.
Step 5: An auditor later asks which users have access to sensitive payment data. Priya uses IAM's 'Access Analyzer' tool to generate a report showing all policies and their effective permissions. She discovers that an old admin user accidentally has full access to all S3 buckets. She removes that policy immediately.
Key actions Priya performed:
Created IAM groups and users
Wrote a custom JSON policy with conditions
Attached policies to a group
Created an IAM role for a service
Used Access Analyzer for auditing
This scenario is exactly what DEA-C01 expects you to understand: how to design policies for different identities (human users vs. automated services), how to use conditions to add security layers, and how to audit existing permissions.
DEA-C01 tests IAM policies and data access control heavily, usually as part of multiple-choice questions where you need to analyse a policy JSON or choose the correct policy for a given scenario. Here are the specific areas they love to test:
Policy evaluation logic: Expect at least one question where they give you two policies attached to the same user — one allows, one denies — and ask what the effective permission is. The answer is always 'Deny' because explicit deny overrides allow. Trap: beginners think the most specific policy wins, but it is the deny that always wins.
Resource-based vs. identity-based policies: They will give you a scenario like 'a user in Account A needs to read data from an S3 bucket in Account B'. The correct answer is that you need both: an identity-based policy on the user (or role) in Account A allowing s3:GetObject, AND a resource-based policy (bucket policy) on the S3 bucket in Account B that allows the Account A user's ARN. Trap: candidates only set one policy and think that is enough.
Conditions: Questions will include conditions like 'IpAddress' or 'StringEquals'. You must know that 'IpAddress' checks the source IP, and 'StringEquals' checks exact string matches (like a specific AWS account ID). Trap: they might include a condition that seems logical but uses the wrong condition key (e.g., using 'StringEquals' for an IP range, which would fail).
Least privilege principle: They will describe a role that needs only read access to a DynamoDB table and ask for the correct policy. The correct answer will have only 'dynamodb:GetItem' and 'dynamodb:Query' actions, and the resource will point to the specific table ARN. Trap: a distractor answer will list broader actions like 'dynamodb:*' or forget to specify the resource, effectively granting too much access.
IAM roles vs. IAM users: You will be asked 'should you create a user or a role for an EC2 instance that needs to access an S3 bucket?'. The answer is always a role, because roles are designed for AWS services. Trap: a distractor says 'create a user and store the access key on the instance' — that is insecure and against best practice.
S3 bucket policies specifically: They love to test the difference between a bucket policy that grants public access (Principal: '*') and a policy that restricts access to a specific IAM role. Public access is almost never the correct answer for data security questions. Trap: they might phrase the question as 'allow anyone to read objects' but include a condition that looks secure but is not.
Encryption and KMS: A common question type is 'a user gets an access denied error when trying to read an encrypted S3 object even though they have s3:GetObject permission'. The answer is that the user also needs kms:Decrypt permission on the KMS key. Trap: candidates forget that IAM policies on the key itself (KMS key policies) must also allow the user.
Policy structure: You must be able to read a JSON policy and identify the Effect, Action, Resource, and Condition blocks. They may present a malformed policy (missing a required field) and ask what is wrong. Trap: a policy without a 'Principal' field is fine for identity-based policies but required for resource-based policies.
Cross-account access: Expect a question about granting access to a user from another AWS account. The correct approach is to create a role in the target account with a trust policy that allows the external account to assume that role. Trap: candidates try to attach a policy directly to the external user, which does not work across accounts without a role.
Key definitions to memorise:
ARN (Amazon Resource Name): the unique identifier for any AWS resource
Principal: the entity (user, role, service) that the policy applies to
Effect: Allow or Deny
Action: the specific API call (e.g., s3:PutObject)
Resource: the ARN of the resource
Condition: an optional block that adds extra requirements
STS (Security Token Service): the service that issues temporary credentials when you assume a role
An IAM policy is a JSON document that defines the Effect (Allow or Deny), Action (specific API call), Resource (ARN of the target), and optional Conditions that must be met.
The explicit Deny in any policy always overrides any Allow, making Deny the ultimate safety mechanism in AWS access control.
Resource-based policies (like S3 bucket policies) are attached to the resource itself, while identity-based policies are attached to a user, group, or role.
To grant cross-account access to an S3 bucket, you must configure both a bucket policy (resource-based) in the target account and an IAM role (identity-based) in the source account.
When an S3 object is encrypted with a customer-managed KMS key, the user needs both s3:GetObject and kms:Decrypt permissions to read the object.
IAM roles are designed for AWS services like EC2, Lambda, and Glue, not for human users; they use temporary credentials from AWS STS.
The least privilege principle means you should grant only the exact actions and resources a user or service needs — never use wildcard (*) actions or resources unnecessarily.
Conditions in policies can restrict access based on IP address, time of day, encryption in transit (HTTPS), and many other factors.
These come up on the exam all the time. Here's how to tell them apart.
IAM User
Represents a person with a long-term password or access key
Best used for individual human beings or applications with static credentials
Cannot be assumed by AWS services directly
IAM Role
Represents a set of permissions with temporary credentials from STS
Best used for AWS services like EC2, Lambda, or Glue
Can be assumed by both users and services via trust policies
Identity-based Policy
Attached to a user, group, or role
Controls what actions the identity can perform across all resources
Does not require a Principal field
Resource-based Policy
Attached to the resource itself (e.g., S3 bucket)
Controls who can access that specific resource
Requires a Principal field to specify who is allowed
S3 Bucket Policy
Resource-based, attached to the bucket
Can grant access to users from other AWS accounts
Evaluated before IAM user policies for the same bucket
IAM User Policy (S3 Access)
Identity-based, attached to a user
Only applies to the user it is attached to
Cannot grant cross-account access alone; needs a resource-based policy
Allow Effect
Permits a specific action on a resource
Multiple Allows can stack to grant broader permissions
Overridden by an explicit Deny on the same action
Deny Effect
Blocks a specific action on a resource
A single Deny overrides all Allows for that action
Used as a safety measure to prevent accidental over-permissioning
Action: s3:GetObject
Grants read access only to individual S3 objects
Follows the least privilege principle
Safe for users who only need to download files
Action: s3:*
Grants all S3 actions including delete, put, and list
Violates least privilege principle
Risky for any user who does not need full administrative access
Mistake
An IAM policy attached to a user automatically applies to any AWS service that user accesses, regardless of the resource.
Correct
An IAM policy only applies to the resources explicitly listed in the policy's Resource field. If the resource is not mentioned, the action is denied by default.
Beginners think IAM is a blanket permission system, but it is resource-specific. Without specifying the resource ARN, the policy gives no access.
Mistake
If you have both an Allow and a Deny policy, AWS chooses the one that is more specific.
Correct
AWS's evaluation logic always prioritises an explicit Deny over any Allow, regardless of specificity. The Deny always wins.
This comes from real-world IT where a deny override is a safety feature to prevent accidental over-permissioning. It is counter-intuitive because specificity often wins in other contexts.
Mistake
An S3 bucket policy and an IAM user policy are interchangeable and achieve the same thing.
Correct
A bucket policy is resource-based and controls access to the bucket itself, including from other accounts. An IAM user policy is identity-based and controls what that user can do across all services. They work together but are not interchangeable.
Because the exam often gives one or the other in a scenario, and candidates pick the wrong one because they do not understand the difference between identity-based and resource-based.
Mistake
IAM roles are only for human users who need temporary access.
Correct
IAM roles are primarily used for AWS services (like EC2, Lambda, or Glue) to grant them permissions. Human users can assume roles, but the main purpose is to give AWS resources permissions to act on your behalf.
The name 'role' sounds like something a person would 'play', so beginners associate it with humans, not machines.
Mistake
A condition in a policy is optional and rarely used in practice.
Correct
Conditions are extremely common and powerful. They are used to enforce IP address restrictions, require HTTPS, enforce encryption, and much more. The exam tests them frequently.
Beginners focus on the core Effect-Action-Resource structure and skip reading about conditions, missing a major exam topic.
Mistake
If a user has s3:GetObject permission, they can always read any S3 object in the bucket.
Correct
If the object is encrypted with a customer-managed KMS key, the user also needs kms:Decrypt permission on that key. S3 permissions alone are not enough for encrypted objects.
Candidates forget that encryption adds another layer of access control beyond the data service itself.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IAM user represents a person with a long-term password or access key. An IAM role represents a set of permissions that can be assumed temporarily by an AWS service or a trusted user, using temporary credentials from AWS STS.
You need to do two things: create a bucket policy on your S3 bucket that allows the external user's account principal, and have the external account create an IAM role with a trust policy that allows their user to assume it.
It means the identity is allowed to perform every possible action on S3 (read, write, delete, list, etc.). This violates the least privilege principle and is generally not recommended for security.
Conditions add extra security requirements that must be met for the policy to apply, such as requiring the request to come from a specific IP address or use an encrypted connection. They help prevent unauthorised access even if the policy is attached to the wrong user.
Yes, but that is called a bucket policy — it is a resource-based policy. Identity-based policies are attached to users, groups, or roles. Both types can coexist for the same bucket.
The Deny always wins. AWS evaluates all policies and if any explicit Deny applies to the request, the action is denied regardless of any Allow from another policy.
You've finished IAM Policies and Data Access Control for AWS Data Services. Continue through the DEA-C01 study guide to build a complete picture of the exam.
Done with this chapter?