AWS Resource-based Policies

• Resource-based policies allow attaching a policy directly to the resource you want to share, instead of using a role as a proxy.
• Resource-based policies allow granting usage permission to other AWS accounts or organizations on a per-resource basis.
• Resource-based policy specifies the Principal, in the form of a list of AWS account ID numbers, that can access that resource and what they can access.
• Using cross-account access with a resource-based policy, the User still works in the trusted account and does not have to give up their permissions in place of the role permissions.
• Users can work on the resources from both accounts at the same time and this can be useful for scenarios e.g. copying objects from one bucket to the other bucket in a different AWS account.
• Resource-based policies include a Principal element to specify which IAM identities can access that resource.
• Resources that support resource-based policies include:
  • Amazon S3 – Bucket policies, Access Point policies, Directory Bucket policies, S3 Tables policies
  • Amazon SNS (Simple Notification Service)
  • Amazon SQS (Simple Queue Service)
  • Amazon S3 Glacier Vaults
  • AWS Lambda functions
  • Amazon API Gateway
  • AWS KMS Key Policies
  • Amazon EFS File System Policies
  • Amazon ECR Repository Policies
  • AWS Secrets Manager – Secret Policies
  • Amazon EventBridge – Event Bus Policies
  • Amazon OpenSearch Service – Domain Access Policies
  • AWS Backup – Vault Access Policies
  • Amazon DynamoDB – Table and Stream Policies
  • Amazon Kinesis Data Streams – Stream Policies
  • Amazon CloudWatch Logs – Log Group Policies
  • AWS Glue – Data Catalog Resource Policies
  • AWS CodeArtifact – Repository and Domain Policies
  • AWS CodeBuild – Project Policies (for cross-account sharing via RAM)
  • Amazon SES v2 – Identity Policies
  • AWS Private CA – CA Policies
  • AWS Serverless Application Repository – Application Policies
  • AWS Organizations – Delegation Policies
  • AWS Elemental MediaStore – Container Policies
  • Amazon Lex V2 – Bot Policies
  • Amazon S3 Express – Directory Bucket Policies
• Resource-based policies need the trusted account to create users with permissions to be able to access the resources from the trusted account.
• Only permissions equivalent to, or less than, the permissions granted to the account by the resource owning account can be delegated.

Resource Control Policies (RCPs) – New in 2024

• Resource Control Policies (RCPs) are a new type of authorization policy in AWS Organizations, launched in November 2024.
• RCPs allow you to centrally restrict external access to your AWS resources at scale across your organization.
• RCPs complement Service Control Policies (SCPs) – SCPs restrict what principals can do, while RCPs restrict what can be done to resources.
• RCPs are attached to the organization root, OUs, or accounts through AWS Organizations.
• At launch, RCPs support: Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager.
• RCPs do not grant access themselves – they only set maximum permission boundaries on resources.
• RCPs do not affect resources in the management account; they only affect member accounts.
• Use cases include:
  • Preventing resources from being shared with untrusted external accounts
  • Enforcing encryption requirements across all S3 buckets
  • Restricting KMS key usage to internal principals only
• AWS Control Tower also supports managed controls implemented using RCPs.

S3 Bucket Policy

• S3 Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
• Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address).
• Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner.
• Policies can either add or deny permissions across all (or a subset) of objects within a bucket.
• Only the bucket owner is allowed to associate a policy with a bucket.
• S3 Object Ownership (Bucket owner enforced) is now the default – all ACLs are disabled, and the bucket owner owns all objects and manages access exclusively using policies.
• Bucket policies can cater to multiple use cases
  • Granting permissions to multiple accounts with added conditions
  • Granting read-only permission to an anonymous user
  • Limiting access to specific IP addresses
  • Restricting access to a specific HTTP referer
  • Restricting access to a specific HTTP header for e.g. to enforce encryption
  • Granting permission to a CloudFront Origin Access Control (OAC)
  • Adding a bucket policy to require MFA
  • Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
  • Granting permissions for S3 inventory and Amazon S3 analytics
  • Granting permissions for S3 Storage Lens
  • Restricting access to a specific VPC endpoint
  • Requiring specific encryption (SSE-S3, SSE-KMS, or DSSE-KMS)
• S3 Access Points – Each access point has its own resource-based access point policy, enabling fine-grained access to shared datasets without complex bucket policies.
• S3 Directory Buckets (S3 Express One Zone) – Support bucket policies for controlling access to high-performance directory buckets.
• S3 Tables – Support resource-based policies at the table bucket, namespace, or table level for analytics workloads.

Glacier Vault Policy

• S3 Glacier vault access policy is a resource-based policy that can be used to manage permissions to the vault.
• A Vault Lock policy is a Vault Access policy that can be locked. After you lock a Vault Lock policy, the policy can’t be changed. You can use a Vault Lock Policy to enforce compliance controls.
• Modern Alternative: Use S3 Object Lock with S3 Glacier storage classes for WORM (Write Once Read Many) compliance. S3 Object Lock provides Governance and Compliance modes with retention periods.

KMS Key Policy

• KMS Key Policy helps determine who can use and manage those keys and is a primary mechanism for controlling access to a key.
• KMS Key Policy can be used alone to control access to the keys.
• A KMS key policy MUST be used, either alone or in combination with IAM policies or grants to allow access to a KMS key.
• IAM policies by themselves are not sufficient to allow access to keys, though they can be used in combination with a key policy.
• IAM user who creates a KMS key is not considered to be the key owner and they don’t automatically have permission to use or manage the KMS key that they created.
• KMS keys are now supported by Resource Control Policies (RCPs) for organization-wide access restrictions.
• KMS supports key policies with conditions including kms:ViaService, kms:CallerAccount, and aws:PrincipalOrgID for restricting key usage to specific services, accounts, or organization members.

API Gateway Resource Policy

• API Gateway resource policies are attached to an API to control whether a specified principal (typically an IAM role or group) can invoke the API.
• API Gateway resource policies can be used to allow the API to be securely invoked by:
  • Users from a specified AWS account.
  • Specified source IP address ranges or CIDR blocks.
  • Specified virtual private clouds (VPCs) or VPC endpoints (in any account).
• Resource policies can be used for all API endpoint types in API Gateway: private, edge-optimized, and Regional.
• Resource policies work alongside Lambda authorizers and IAM authorization for layered security.

Lambda Function Policy

• Lambda supports resource-based permissions policies for Lambda functions and layers.
• Resource-based policy can be used to allow an AWS service to invoke the function on your behalf.
• Resource-based policies apply to a single function, version, alias, or layer version.
• Common use cases include allowing API Gateway, S3, EventBridge, SNS, or SQS to invoke the function.
• Lambda function URLs also use resource-based policies to control who can invoke the function via the URL endpoint.

EFS File System Policy

• EFS supports IAM resource policy using file system policy.
• EFS evaluates file system policy, along with any identity-based IAM policies to determine the appropriate file system access permissions to grant.
• An “allow” permission on an action in either an IAM identity policy or a file system resource policy allows access for that action.
• EFS file system policies can enforce encryption in transit, prevent root access, or enforce read-only access by default.

ECR Repository Policy

• Repository policies are resource-based policies that can help control access to the repositories and the images within them.
• Repository policies are a subset of IAM policies that are scoped for, and specifically used for, controlling access to individual ECR repositories.
• A user or role only needs to be allowed permission for an action through either a repository policy or an IAM policy but not both for the action to be allowed.
• Resource-based policies also help grant the usage permission to other accounts on a per-resource basis.

Secrets Manager Resource Policy

• Secrets Manager supports resource-based policies attached directly to secrets for cross-account access.
• Resource policies can grant specific principals in other accounts permission to retrieve or manage the secret.
• Secrets Manager validates resource policies to prevent overly broad access (BlockPublicPolicy parameter).
• Secrets Manager is supported by Resource Control Policies (RCPs) for organization-wide access restrictions.
• Use aws:PrincipalOrgID condition to restrict secret access to principals within your AWS Organization.

EventBridge Event Bus Policy

• EventBridge supports resource-based policies on event buses to control which accounts or organizations can put events.
• Event bus policies enable cross-account event delivery without creating IAM roles in the receiving account.
• EventBridge Schema Registry also supports resource-based policies for sharing schemas across accounts.
• Use conditions like aws:PrincipalOrgID to restrict event sources to your organization.

OpenSearch Service Domain Policy

• Amazon OpenSearch Service supports resource-based access policies attached to domains.
• Domain access policies control which principals can access the OpenSearch domain and its APIs.
• Access policies can restrict access by IP address, IAM principal, or VPC endpoint.
• For VPC-based domains, security groups provide network-level access control in addition to resource-based policies.

DynamoDB Resource Policy

• DynamoDB supports resource-based policies on tables and streams for cross-account access.
• Table policies allow granting specific DynamoDB actions (read, write, query) to principals in other accounts without creating IAM roles.
• Stream policies control who can read from DynamoDB Streams for change data capture scenarios.

SNS Policy

• SNS policy can be used with a particular topic to restrict who can work with that topic e.g, who can publish messages to it, subscribe to it, etc.
• SNS policies can grant access to other AWS accounts, or to users within your own AWS account.
• Common use cases include allowing S3, CloudWatch, or other services to publish notifications to an SNS topic.

SQS Policy

• SQS policy system lets you grant permission to other AWS Accounts, whereas IAM doesn’t.
• SQS is supported by Resource Control Policies (RCPs) for organization-wide access restrictions.
• Common use cases include allowing SNS topics or S3 event notifications to send messages to the queue.

IAM Access Analyzer for Resource-based Policies

• IAM Access Analyzer helps identify resources shared with external entities by analyzing resource-based policies.
• External access analyzers use logic-based reasoning to identify resource policies that grant access to principals outside your account or organization.
• Internal access analyzers (launched June 2025) identify who within your organization can access resources.
• Access Analyzer supports analyzing policies for S3, KMS, SQS, IAM roles, Lambda, Secrets Manager, SNS, EFS, ECR, and more.
• Custom policy checks can validate that resource-based policies don’t grant public access before deployment.
• Guided revocation provides recommendations for removing unnecessary access granted by resource-based policies.

Cross-Account Access: Resource-based Policy vs. IAM Role

• Resource-based Policy:
  • User retains permissions in their own account while accessing the shared resource.
  • Both accounts’ resources are accessible simultaneously.
  • No need to assume a role (no STS AssumeRole call).
  • Simpler for service-to-service integrations (e.g., allowing SNS to write to SQS).
• IAM Role (AssumeRole):
  • User gives up their original permissions and acquires the role’s permissions.
  • Can only access resources permitted by the role at a time.
  • Works with any AWS service regardless of resource policy support.
  • Provides temporary credentials with configurable session duration.

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company needs to allow an application in Account A to access an S3 bucket in Account B. The application must retain its permissions in Account A while accessing the bucket. Which approach should be used?
   1. Create an IAM role in Account B and have the application assume the role
   2. Add a resource-based policy (bucket policy) on the S3 bucket in Account B granting access to Account A’s principal
   3. Create a cross-account IAM user in Account B
   4. Use AWS Organizations to share the bucket

   Answer: b – Resource-based policies allow the principal to retain its permissions in the home account while accessing the shared resource.

2. An organization wants to centrally prevent all S3 buckets across member accounts from being shared with external principals. Which policy type should they use?
   1. Service Control Policy (SCP)
   2. Resource-based policy on each bucket
   3. Resource Control Policy (RCP)
   4. IAM permission boundary

   Answer: c – Resource Control Policies (RCPs) centrally restrict external access to resources at the organization level. SCPs control what principals can do, while RCPs control what can be done to resources.

3. Which AWS service should be used to automatically identify S3 buckets, KMS keys, and SQS queues that have resource-based policies granting access to external accounts?
   1. AWS Config
   2. Amazon GuardDuty
   3. IAM Access Analyzer
   4. AWS CloudTrail

   Answer: c – IAM Access Analyzer uses logic-based reasoning to analyze resource-based policies and identify resources shared with external entities.
4. A KMS key policy is required for which of the following scenarios? (Choose TWO)
   1. To allow any access to a KMS key, whether used alone or with IAM policies
   2. To create an IAM user
   3. To enable IAM policies to grant access to the key
   4. To enable S3 bucket encryption
   5. To create an AWS Lambda function

   Answer: a, c – A key policy MUST exist for any access to a KMS key. The default key policy enables IAM policies to also grant access.

5. Which of the following correctly describes the behavior when a resource-based policy grants access to a principal in the SAME account? (Choose the correct statement)
   1. The principal needs both an identity policy AND the resource policy to grant access
   2. Either the identity-based policy OR the resource-based policy can grant access independently
   3. Only the resource-based policy is evaluated
   4. Resource-based policies don’t work within the same account

   Answer: b – Within the same account, an allow in either the identity-based policy or the resource-based policy is sufficient to grant access (assuming no explicit deny).

References

• IAM Identity-based vs Resource-based Policies
• AWS Services That Work with IAM
• S3 Bucket Policy
• KMS Key Policy
• Lambda Function Policy
• SQS Policy
• Glacier Vault Policies
• EFS File System Policy
• Secrets Manager Resource Policy
• Resource Control Policies (RCPs)
• IAM Access Analyzer
• EventBridge Resource-based Policies