IAM Policy Examples: AWS KMS & Secrets Manager for Cloud Security

IAM policy examples are JSON documents that grant or deny AWS API actions to users, roles, or groups on specific resources. Common examples include read-only S3 access, KMS encrypt and decrypt permissions scoped to one key ARN, and Secrets Manager GetSecretValue on a single secret — each built on the least-privilege principle.

• IAM policies are JSON documents that explicitly allow or deny AWS API actions on specific resources.
• AWS KMS handles envelope encryption so your data keys never leave the service unprotected.
• AWS Secrets Manager stores, rotates, and audits credentials so you don’t hardcode passwords in your code.
• Least privilege means starting with zero permissions and adding only what a workload actually needs.

IAM Policy Examples Every Cloud Learner Should Know

There are two broad types of IAM policies: identity-based policies attached to users, groups, or roles, and resource-based policies attached directly to services like S3 or KMS. Most day-to-day work involves identity-based policies, so that is where the most useful IAM policy examples live. Understanding both types is essential for any AWS security audit or compliance review.

Read-Only S3 Access

This is the most common starter IAM policy example. You allow s3:GetObject and s3:ListBucket on a specific bucket ARN, and you deny everything else by default. The key discipline is specifying the exact bucket, not using a wildcard on the resource field.

A wildcard resource like “Resource”: “*” on an S3 GetObject statement gives the principal read access to every bucket in the account. That is almost never what you want, and it is one of the most common misconfigurations AWS Security Hub flags.

What Is the Difference Between IAM Policies and Roles in AWS?

A policy is the permission document. A role is an identity that can be assumed by a service, user, or external account, and it carries policies with it. Think of a role as a temporary identity that an EC2 instance or Lambda function uses to get permissions, without needing long-term access keys.

According to the AWS Well-Architected Framework, using roles instead of IAM users for workloads is a core security best practice because temporary credentials expire automatically and do not need rotation scripts.

AWS IAM Policy JSON Example: KMS Key Usage

When you want a Lambda function to encrypt and decrypt data using a KMS key, you attach a least-privilege IAM policy that allows kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey on the specific key ARN. You never grant kms:* to a compute workload. That would let it delete or disable the key, which is a catastrophic permission to hand out casually. This KMS IAM policy example is one of the most frequently tested patterns in AWS security interviews.

Secrets Manager IAM Policy Example

A scoped Secrets Manager IAM policy example allows secretsmanager:GetSecretValue on one specific secret ARN, nothing else. If your application only reads a database password, it does not need secretsmanager:PutSecretValue or secretsmanager:DeleteSecret. That single restriction stops a compromised Lambda from wiping your entire secrets store.

How Do You Follow Least Privilege in AWS?

Start by using AWS IAM Access Analyzer to generate policy templates based on actual CloudTrail activity. This tells you exactly which actions a principal has used in the last 90 days. Remove everything else. According to Gartner’s report How to Manage the Growing Risk of Cloud IAM (2023), over-permissioned identities are involved in more than 50% of cloud data breaches.

Run a permission boundary on developer roles so they cannot escalate their own privileges. Set a Service Control Policy (SCP) at the AWS Organizations level to hard-block actions like disabling CloudTrail or deleting KMS keys, regardless of what individual IAM policies say.

AWS KMS Explained: How Encryption Actually Works

AWS Key Management Service uses envelope encryption. When you encrypt an S3 object, KMS generates a data key, encrypts your data with that data key locally, then encrypts the data key itself with your KMS Customer Master Key (CMK). Only the encrypted data key is stored alongside your data. The plaintext data key never persists anywhere.

KMS Key Policy vs IAM Policy: Understanding the Two-Layer Model

Every KMS key has its own key policy, separate from IAM. The key policy must explicitly allow the AWS account root or specific IAM principals to use it. If the key policy does not grant access, an IAM policy alone will not work. This KMS key policy vs IAM policy distinction is intentional and prevents a single misconfigured IAM policy from unlocking encrypted data.

KMS Key Types and When to Use Them

AWS offers AWS-managed keys (free, less control), customer-managed keys (CMKs, full control over rotation and policy), and AWS-owned keys (used by services internally, no visibility). For any regulated workload, including fintech applications under the RBI IT Framework 2021 or healthcare data under India’s Digital Personal Data Protection Act 2023, you want CMKs so you control who can use the key and can revoke access instantly.

According to AWS’s pricing page (verified June 2025), each CMK costs $1 per month and $0.03 per 10,000 API calls. For most startups and learners, this is negligible compared to the compliance risk of unmanaged encryption.

KMS Key Type	Control Level	Key Rotation	Monthly Cost	Best For
AWS-Owned Key	None	AWS-managed	Free	Default service encryption
AWS-Managed Key	Low	Automatic (annual)	Free	Simple encryption needs
Customer-Managed Key (CMK)	Full	Configurable (annual or on-demand)	$1 USD	Compliance, regulated data, fintech
CMK (Asymmetric)	Full	Not supported	$1 USD	Digital signing, public-key workflows

If you are studying for cloud security certifications or building toward a career in cloud security, understanding the KMS key policy vs IAM policy two-layer model is the kind of detail that separates a strong candidate from an average one. Check out the technical interview preparation guide on 3.0 University to see exactly how these concepts come up in hiring panels.

AWS Secrets Manager: Stop Hardcoding Credentials

AWS Secrets Manager stores API keys, database passwords, OAuth tokens, and any other sensitive string your application needs at runtime. Your code calls the Secrets Manager API at startup, retrieves the secret, and uses it. The secret never touches your codebase, your CI/CD pipeline config, or your environment variables in plain text.

A 2023 GitGuardian report found that over 10 million secrets were exposed in public GitHub repositories that year, with hardcoded AWS credentials among the most common. A scoped Secrets Manager IAM policy example directly eliminates that entire attack surface by ensuring only the right Lambda or EC2 role can call GetSecretValue.

Automatic Rotation

Secrets Manager can rotate credentials automatically using a Lambda function. For supported databases like Amazon RDS, it handles the rotation natively. You set a rotation schedule (say, every 30 days), and the service updates both the secret value and the database password without any downtime to your application.

Indian fintech companies operating under PCI-DSS compliance, and SaaS startups dealing with SOC 2 audits, find automatic rotation particularly valuable because it replaces a manual process that teams routinely skip under delivery pressure. For example, a Bengaluru-based payments startup using UPI integrations can use Secrets Manager to rotate third-party API credentials on a 30-day cycle without touching application code.

Secrets Manager vs AWS Systems Manager Parameter Store

Parameter Store is cheaper and works well for non-sensitive configuration values. Secrets Manager is built specifically for secrets: it costs more ($0.40 per secret per month, per AWS pricing), but it adds automatic rotation, cross-account access, and full CloudTrail audit logging out of the box. For anything that would cause a breach if exposed, use Secrets Manager.

If you are just getting started with cloud security concepts and want a structured path, the Cybersecurity 101 course at 3.0 University covers the fundamentals you need before tackling IAM policy examples and secrets management in depth.

Frequently Asked Questions

What are common IAM policy examples?

Common IAM policy examples include read-only S3 bucket access, KMS encrypt and decrypt permissions scoped to a single key ARN, Secrets Manager GetSecretValue on one secret, and EC2 describe-only policies for monitoring tools. Each follows the same pattern: specify the exact action, the exact resource ARN, and nothing more than what the workload actually needs.

How does AWS KMS encrypt data?

AWS KMS uses envelope encryption. It generates a plaintext data key, encrypts your data locally with that key, then encrypts the data key itself using your Customer Master Key. Only the encrypted data key is stored. The plaintext key never persists. Decryption reverses the process, requiring explicit KMS API access controlled by both the key policy and IAM.

What is AWS Secrets Manager used for?

AWS Secrets Manager stores sensitive credentials like database passwords, API keys, and OAuth tokens so applications retrieve them at runtime via API instead of reading from hardcoded config files or environment variables. It also supports automatic credential rotation for RDS and other services, and logs every retrieval event to CloudTrail for audit purposes.

What is the difference between IAM policies and roles in AWS?

An IAM policy is a JSON document defining allowed or denied API actions. An IAM role is an identity that carries one or more policies and can be assumed temporarily by services, users, or external accounts. Roles use short-lived credentials that expire automatically. Policies are the rules; roles are the identity that holds those rules for a specific workload or session.

How do you follow least privilege in AWS?

Start with zero permissions and add only what your workload’s CloudTrail logs show it actually uses. Use IAM Access Analyzer to generate minimal policy templates from real activity. Apply permission boundaries to developer roles to block privilege escalation. Set Service Control Policies at the AWS Organizations level to hard-deny destructive actions like disabling CloudTrail or deleting KMS keys account-wide.

What is the difference between a KMS key policy and an IAM policy?

A KMS key policy is attached directly to the KMS key and must explicitly grant access to IAM principals before any IAM policy can take effect. An IAM policy is attached to a user, group, or role and defines what actions that identity can perform. Both must allow an action for a principal to successfully use a KMS key — neither alone is sufficient.

Getting comfortable with IAM policy examples, KMS, and Secrets Manager is one of the fastest ways to build practical cloud security skills that employers in India and globally are hiring for right now. These concepts appear in every AWS security audit, every compliance review, and most cloud security interview rounds.

If you want a structured, hands-on path to cloud and cybersecurity expertise, the Certified Cybersecurity Technician Program at 3.0 University gives you exactly that, with real labs, mentor support, and career-ready skills built from the ground up.

Last updated: June 2025. Reviewed by the 3University editorial team.