Tutorial: AWS Certified Developer - Associate (DVA-C02)

Resource-based policies, service policies, and principal policies

Concepts

Resource-Based Policies

Resource-based policies are attached directly to the resource that they are meant to control access to. These are also known as inline policies when embedded directly into the resource, and they specify what actions are allowed or denied on that particular resource. Common AWS services that support resource-based policies include S3 (for S3 buckets), KMS (for keys), and Lambda (for functions).

These policies typically include a Principal element, which specifies the account, user, role, or service that is allowed or denied access to the resource. Here’s an example of a resource-based policy for an Amazon S3 bucket:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Stmt1”,
“Effect”: “Allow”,
“Principal”: “*”,
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::example-bucket/*”
}
]
}

In this policy, we’re allowing any user to get objects from example-bucket.

Service Policies

Service policies, sometimes referred to as service control policies (SCPs), are policies applied to AWS Organizations units like accounts, organizational units (OUs), or an entire organization to manage permissions across the organization. SCPs do not grant permissions but set limits on the AWS services and actions that users and roles within the scoped organization units can access.

The following is an example of an SCP that prevents users from deleting Amazon EC2 instances:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “DenyInstanceDeletion”,
“Effect”: “Deny”,
“Action”: “ec2:TerminateInstances”,
“Resource”: “*”
}
]
}

Principal Policies

Principal policies (commonly known as IAM policies) are attached to IAM users, groups, or roles and specify what actions are allowed or denied across AWS. Principal policies are the most common type of policy you work with in IAM. These policies do not have a Principal element in their structure since the IAM entity (user, group, or role) to which they are attached is the principal.

Here is an example of an IAM policy that allows reading objects from a specific S3 bucket:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”: [
“arn:aws:s3:::example-bucket”,
“arn:aws:s3:::example-bucket/*”
]
}
]
}

Comparing Policy Types

Policy Type	Attached To	Controls Access For	Includes Principal?	Use Case
Resource-Based	AWS Resources (e.g., S3 bucket)	Specific resource	Yes	Granting access to a single resource regardless of the user
Service Policies	AWS Organizations (Accounts/OUs)	Account/Organizational level	No (implicit)	Restricting or configuring permissions across multiple accounts or the entire organization
Principal Policies	IAM Users/Groups/Roles	User/Group/Role level	No (implicit)	Assigning permissions to IAM principals directly, governing their interactions with AWS services

Important Considerations

Policy Evaluation Logic: AWS evaluates all policies (identity-based, resource-based, SCPs, etc.) when a request is made, combining all the applicable policies. If any policy denies an action, it is denied unless an explicit “allow” with a condition such as aws:RequestTag/${TagKey} or aws:ResourceTag/${TagKey} applies.
Least Privilege Principle: It’s a best practice to grant only the permissions required to perform a task. IAM policies should be as restrictive as necessary.
Policy Conditions: Policies can include conditions to fine-tune permissions. For example, a condition might require that a request is made within a specific IP range or at a certain time of day.
Policy Simulation: AWS provides a Policy Simulator tool that lets you test the effects of your policies before applying them, minimizing the chance of unintentional access changes.

Understanding these policy types and how they interact with AWS resources is essential for securing your AWS environment and is a fundamental part of the AWS Certified Developer – Associate exam. Remember to keep in mind the purpose of each policy type and use the one that best fits the scenario you are addressing.

Answer the Questions in Comment Section

True or False: Resource-based policies can only be applied to AWS S3 buckets.

(A) True
(B) False

Answer: B

Explanation: Resource-based policies can be applied to various AWS resources, not just S3 buckets. These include S3 buckets, but also Amazon Glacier vaults, AWS KMS keys, Amazon SQS queues, and more.

Which of these is NOT a type of policy available in AWS IAM?

(A) User policies
(B) Group policies
(C) Principal policies
(D) Resource-based policies

Answer: C

Explanation: In AWS IAM, the types of policies include identity-based policies (user or group), resource-based policies, but there is no specific policy type called ‘principal policies.’ Principal information can be part of a policy statement indicating who is allowed or denied access.

True or False: Inline policies are always the best choice when it comes to granting permissions in AWS.

(A) True
(B) False

Answer: B

Explanation: Inline policies are not always the best choice. They are directly attached to a single IAM user, group, or role, which can be less flexible and harder to manage compared to managed policies which can be attached to multiple entities.

An IAM managed policy that is created and managed by AWS is known as:

(A) Customer managed policy
(B) AWS managed policy
(C) Inline policy
(D) Group managed policy

Answer: B

Explanation: An IAM managed policy that is created and managed by AWS is known as an AWS managed policy. Customer managed policies are created by users, and inline policies are directly inserted into the user, group, or role.

True or False: Service control policies (SCPs) are used to manage permissions in AWS Organizations.

(A) True
(B) False

Answer: A

Explanation: Service control policies (SCPs) are used to manage permissions in AWS Organizations. They allow you to set permission boundaries for all AWS accounts within an organization.

Which AWS service is used to manage fine-grained access control to AWS resources?

(A) AWS IAM
(B) AWS Organizations
(C) Amazon S3
(D) AWS KMS

Answer: A

Explanation: AWS Identity and Access Management (IAM) is used to manage fine-grained access control to AWS resources by creating and managing AWS users and groups, and using permissions to allow and deny their access to AWS resources.

True or False: Principal policies are standalone policies that you can attach to multiple AWS resources.

(A) True
(B) False

Answer: B

Explanation: Principal policies do not exist as a standalone policy type in AWS IAM. Policies in IAM are either attached to identities (users, groups, roles) or resources, and policy documents include a “Principal” element to specify the identities that the policy applies to.

Which of the following can be used to provide temporary access to AWS resources?

(A) IAM user
(B) IAM group
(C) IAM role
(D) IAM managed policy

Answer: C

Explanation: IAM roles can be used to provide temporary access to AWS resources. Roles can be assumed by authorized entities such as IAM users, AWS services, or federated users.

True or False: Attachments of managed policies to IAM entities are limited to 10 for any AWS account.

(A) True
(B) False

Answer: B

Explanation: You can attach up to 10 managed policies to an IAM user, role, or group. However, AWS organizations can use service control policies (SCPs) to raise boundaries, and the limits can vary depending on the type of entity and specific circumstances.

What is the maximum number of inline policies that you can attach to an IAM user?

(A) 10
(B) 50
(C) There is no limit other than overall policy size
(D) 100

Answer: C

Explanation: There is no limit on the number of inline policies you can attach to an IAM user other than the overall size limit for each policy and entity. The policy size limit varies if the policy is in JSON format or if it includes certain policy features.