# IAM policy

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/iam-policy

## Quick definition

An IAM policy is like a permission slip for cloud services. It defines which users or services can access specific resources and what they can do with them. You attach policies to users, groups, or roles to control access securely.

## Simple meaning

Imagine you work in a large office building with many rooms. Some rooms contain sensitive files, others have expensive equipment, and some are just common areas. To keep things organized and secure, the building manager gives each employee a keycard. That keycard only opens the doors you are allowed to enter. A security guard at the front desk also checks your badge when you come in, and a central computer logs every door you open. In cloud computing, an IAM policy works exactly like that keycard and security guard combined. It is a digital document that states who can do what with which cloud resource. 

 For example, a policy might say: 'User Alice can read files from the company's storage bucket but cannot delete them' or 'The automated backup service can write logs to a specific folder but cannot access customer data.' These policies are written in a structured language, often JSON, which both humans and computers can read. The cloud provider's system checks every single request against the relevant policies before allowing any action. If the policy does not explicitly grant permission, the request is denied by default. This principle is called 'default deny.' 

 IAM policies are central to cloud security because they let you enforce the principle of least privilege, meaning you give each user or service only the exact permissions they need to do their job, nothing more. Without IAM policies, anyone with access to your cloud account could accidentally or maliciously delete databases, expose customer data, or run up huge bills. By writing careful policies, you prevent these risks while still allowing legitimate work to happen smoothly. 

 Think of it like a recipe. The policy is the recipe that says who is allowed to cook, which ingredients they can use, and what kitchen tools they can touch. If the recipe says 'only the head chef can use the oven,' then even if a line cook has a key to the kitchen, they cannot turn on the oven. This layered control helps keep the whole operation safe and efficient.

## Technical definition

An IAM (Identity and Access Management) policy is a JSON-formatted document that defines a set of permissions. It is attached to an IAM identity (user, group, or role) or to a resource, and it dictates what actions are allowed or denied on that resource. The policy is evaluated by the cloud provider's authorization engine whenever a principal (a user or service) makes an API request. The engine checks the policy statements in order, looking for an explicit allow or deny. If no explicit allow is found, the request is denied by default. 

 The core structure of an IAM policy includes several key elements. The Version element specifies the policy language version, typically '2012-10-17' for AWS and similar formats in GCP and Azure. The Statement element is the main building block. Each statement contains an Effect (either Allow or Deny), an Action (a list of specific API operations, such as 's3:GetObject' or 'compute.instances.start'), a Resource (the specific cloud resource the policy applies to, often identified by an ARN or resource name), and optionally a Condition (additional constraints like requiring multi-factor authentication or restricting access to a specific IP range). 

 IAM policies can be categorized into two main types: identity-based policies and resource-based policies. Identity-based policies are attached to a user, group, or role. They grant permissions to that identity. Resource-based policies are attached directly to a resource, such as an S3 bucket or a GCP Cloud Storage bucket. They specify which principals can access that resource. In some cloud providers, you can also use permission boundaries, which are managed policies that set the maximum permissions an identity-based policy can grant. This adds an extra layer of control. 

 When a request is made, the authorization engine collects all applicable policies: the identity-based policies of the principal, any resource-based policies on the target resource, and any organizational policies (like AWS Organizations SCPs or GCP Organization Policies). It then evaluates them. The key evaluation logic is: an explicit deny in any policy overrides any allow. If there is no explicit allow, the request is denied. This is known as the 'deny override' rule. 

 In real IT implementation, you must understand how to structure policies correctly. For example, in AWS, you use ARNs (Amazon Resource Names) to specify resources. In GCP, you use resource names and roles. In Azure, you use Azure RBAC (Role-Based Access Control) with role definitions. The policy language is slightly different for each cloud, but the conceptual principles are identical. Common best practices include using managed policies for common use cases (like read-only access), writing custom policies for specific needs, and always testing policies in a sandbox environment before applying them to production. 

 A common mistake is writing overly permissive policies, such as using a wildcard '*' for actions or resources. This violates least privilege and can lead to security breaches. Another issue is not understanding the difference between user-based and resource-based policies, which can cause unexpected permission errors. The proper use of conditions is also critical for security. For instance, you can add a condition that requires requests to come from a specific VPC (Virtual Private Cloud) or that the request be made using SSL/TLS. 

 Standards like the NIST SP 800-53 framework and the CIS Benchmarks for cloud providers recommend specific IAM policy configurations. For example, they advise against using root or super-admin accounts for daily tasks and recommend enabling MFA (Multi-Factor Authentication) for console access. Implementing IAM policies correctly is a key part of passing security audits and maintaining compliance with regulations like GDPR or HIPAA.

## Real-life example

Imagine you are the manager of a large public library. The library has different sections: children's books, reference materials, rare manuscripts, a computer lab, and a storage room with cleaning supplies. You have several employees: librarians, assistants, volunteers, and a janitor. You cannot give every employee a key to every room because the rare manuscripts must be protected, the computer lab has expensive equipment, and the storage room has hazardous chemicals. Instead, you give each employee a keycard that only opens the doors they need for their job. The children's librarian gets access to the children's section and the story-time room. The reference librarian gets access to the reference desk and the rare manuscripts room, but only during business hours. The janitor gets access to the storage room, the bathrooms, and the main hall, but not the computer lab. 

 This keycard system is your IAM policy. The library is your cloud account. The different rooms are your cloud resources, like databases, storage buckets, and virtual machines. The employees are the users and services that need access. The keycard permissions are the IAM policy statements. Each statement says: 'This employee can open this door (resource) to perform this action (enter, clean, shelve books).' You can also add conditions: the janitor can only enter the storage room between 9 PM and 6 AM when the library is closed. The volunteers can only use the computer lab if they have completed a training course. 

 Now, suppose a volunteer tries to enter the rare manuscripts room. Their keycard does not have that permission, so the door stays locked. The library's central security system checks their card against the policy and denies access. This is exactly how a cloud IAM policy works. When a user or service tries to read a database or start a virtual machine, the cloud provider's authorization engine checks the IAM policy. If the policy does not explicitly allow that specific action on that specific resource, the request is denied. 

 The library also has a policy that the head librarian can override any lock in an emergency. This is like an admin role with full permissions. But you would not give that keycard to every employee because that would be a huge security risk. Similarly, in the cloud, you should never give full administrative access to all users. The library example shows how IAM policies create a secure, organized environment where everyone can do their job without accidentally causing damage or stealing resources.

## Why it matters

In practical IT, IAM policies are the foundation of cloud security. Without them, every user and service would have unrestricted access to everything in your cloud account. That would be like handing out master keys to every employee in a bank vault. One mistake or malicious insider could delete all your data, spin up thousands of expensive virtual machines, or expose sensitive customer information. IAM policies prevent this by enforcing least privilege, ensuring that each identity has only the permissions necessary to perform its function. 

 IAM policies also help with compliance. Regulations like HIPAA, GDPR, and SOC 2 require strict access controls. Auditors will ask to see your IAM policies to verify that only authorized personnel can access protected health information or personal data. A well-documented set of IAM policies demonstrates that you have implemented proper access controls and can pass an audit. 

 From an operational standpoint, IAM policies allow you to delegate tasks safely. You can give developers permission to deploy code to a testing environment without giving them access to production data. You can give a junior administrator permission to restart a server but not to create new virtual networks. This separation of duties reduces the risk of human error and makes troubleshooting easier because you know exactly what each user is allowed to do. 

 Finally, IAM policies are essential for cost management. If you give every user permission to launch expensive GPU instances, your cloud bill could skyrocket. By restricting those actions to only the users who genuinely need them, you keep costs under control. IAM is not just about security; it is also about operational efficiency and financial governance.

## Why it matters in exams

IAM policy is a core topic in many cloud and security certification exams. It appears directly in AWS Certified Cloud Practitioner, AWS Developer Associate, AWS SysOps Administrator, AWS Solutions Architect, Azure Fundamentals, Azure Administrator (AZ-104), Google Associate Cloud Engineer, and Google Cloud Digital Leader. For security exams like CompTIA Security+, CompTIA CySA+, ISC2 CISSP, Microsoft SC-900, MD-102, and MS-102, IAM policy concepts are fundamental to understanding access control models and identity management. 

 In AWS exams, you will see questions about policy evaluation logic, the difference between identity-based and resource-based policies, and how to write policies that follow the principle of least privilege. You must understand how to use conditions, like requiring MFA or restricting to a specific VPC endpoint. The 'explicit deny overrides allow' rule is a frequent exam trap. You must also know how to use managed policies vs. inline policies and when to use permission boundaries. 

 For Azure exams like AZ-104 and SC-900, you need to know about Azure RBAC roles, role definitions, and how to assign policies to users, groups, and managed identities. You must understand the difference between Azure Policy (which enforces compliance rules on resources) and IAM policies (which control access to resources). Azure exams also test your knowledge of conditional access policies and how they integrate with Azure AD. 

 In Google Cloud exams, you need to understand how IAM roles work, including primitive roles, predefined roles, and custom roles. You must know how to attach policies at the project, folder, or organization level. Google also uses conditions in policies, and you will see questions about the evaluation order: deny always takes precedence. 

 For security exams, IAM concepts appear in questions about access control models (DAC, MAC, RBAC), the principle of least privilege, separation of duties, and the AAA framework (Authentication, Authorization, Accounting). The CISSP exam specifically covers IAM in the Identity and Access Management domain. You may be asked to identify which policy component corresponds to a given scenario or to choose the correct policy statement that satisfies a requirement. 

 To prepare, you should practice reading and writing JSON policy documents. Understand every field: Effect, Action, Resource, Condition, and Principal (for resource-based policies). Use the official cloud provider documentation and exam guides. Many exam questions present a scenario and ask which policy change would fix a permission error. You need to trace through the policy evaluation logic step by step. IAM policy questions are often high stakes because they test your ability to design secure systems, which is a core skill for any cloud professional.

## How it appears in exam questions

Exam questions about IAM policies typically fall into three categories: scenario, configuration, and troubleshooting. In scenario questions, you are given a business requirement, such as 'A developer needs to deploy code to a staging environment but should not be able to delete the production database.' You must choose the IAM policy that implements this requirement. These questions test your ability to translate a business need into a concrete policy statement. They often include distractors that allow too much access or that use incorrect resource identifiers. 

 Configuration questions ask you to identify the correct structure of a policy. For example, you may be shown a JSON policy with a syntax error, like a missing comma or an incorrect ARN format. You must pick the corrected version. In AWS exams, you might be asked how to attach a policy to a user, group, or role. In Azure, you might need to know how to assign a role at the subscription scope vs. the resource group scope. In GCP, you might be asked how to grant a custom role to a service account. 

 Troubleshooting questions present a scenario where a user is getting an 'AccessDenied' error. You must determine which policy is blocking the request. For example, a user can list objects in an S3 bucket but cannot download them. The solution might be that the bucket policy denies 's3:GetObject' for that user, even though the user's identity-based policy allows it. You need to understand the evaluation logic to see that the explicit deny on the bucket overrides the allow. Another common troubleshooting pattern: a service cannot write logs to a CloudWatch log group. The cause is often a missing resource-based policy on the log group that grants the 'logs:PutLogEvents' action to the service's principal. 

 Some questions combine IAM with other services. For instance, you might see a question about an EC2 instance that needs to access an S3 bucket. You must decide whether to use an IAM role attached to the instance or hardcode credentials. The correct answer is to use an IAM role because it is more secure and eliminates the need to manage access keys. Similarly, you might see questions about cross-account access: 'Company A wants to allow users from Company B to read data from an S3 bucket in Company A's account.' You need to configure both a bucket policy (resource-based) and an IAM policy (identity-based) in Company B's account. 

 In all these questions, attention to detail is critical. You need to read each policy statement carefully, understand the Effect, Action, Resource, and Condition fields, and apply the evaluation logic. Practice with sample questions from official exam guides and online resources. The more you work with actual policy documents, the easier it becomes to spot the correct answer.

## Example scenario

You are a cloud administrator at a company called TechFlow. TechFlow has a Google Cloud project with a Cloud Storage bucket named 'techflow-backup-logs.' The company's policy team needs to be able to read the logs stored in this bucket to perform analysis. However, they should not be able to delete any objects. The development team needs to be able to write new log files into the bucket, but they should not be able to read or delete existing logs. 

 You need to create IAM policies to enforce these permissions. For the policy team, you create a custom role with the permission 'storage.objects.get' and assign that role to the group 'policy-team@techflow.com.' For the development team, you create a custom role with the permission 'storage.objects.create' and assign that role to the group 'dev-team@techflow.com.' You do not include any delete permissions, and you do not include the 'storage.objects.list' permission for the development team, because they only need to upload files, not see what is already there. 

 Now, imagine a developer named Sarah tries to use the 'gsutil cp' command to download a log file from the bucket. The Google Cloud IAM system checks Sarah's permissions. Since she only has 'storage.objects.create,' the system denies the request. Sarah gets an access denied error. This is exactly what the policy intended. Meanwhile, a policy analyst named John tries to upload a test file to the bucket. The system checks John's permissions. He only has 'storage.objects.get,' so the upload is denied. Both groups can do their jobs without accidentally modifying or deleting each other's data. 

 The real world is more complex because you often have multiple policies and roles that interact. But this simple scenario shows the fundamental purpose of IAM policies: to grant exactly the right permissions to the right people. In an exam, you might be asked to write the JSON for this policy or to choose the correct role from a list of options.

## How IAM Policy Evaluation Logic Determines Access

IAM policy evaluation logic is the core mechanism that determines whether a principal (user, group, or role) is granted or denied access to a specific resource. In cloud providers like AWS, Azure, and GCP, the evaluation process follows a consistent order: by default, all requests are implicitly denied. Explicit allow statements in identity-based or resource-based policies grant access, but an explicit deny overrides any allow. This means that if a policy attached to a user allows S3 read access, but a separate deny policy exists (for example, a service control policy in AWS or an organization policy in GCP), the deny takes precedence. Understanding this hierarchy is critical for exam questions because misconfigurations often arise from overlapping policies. For instance, an AWS IAM policy that allows s3:GetObject might be overridden by a bucket policy that denies access to a specific IP range. The evaluation logic also considers permissions boundaries, session policies, and conditions. In AWS, permissions boundaries define the maximum permissions a role can have, and any policy that grants more than the boundary is reduced. In GCP, IAM roles are additive, but deny policies (introduced in 2021) work similarly to AWS explicit denies. Exams such as the AWS Certified Solutions Architect Associate and Google ACE frequently test this logic by presenting scenarios where a user has multiple policies attached and asking whether access is ultimately allowed or denied. A common pitfall is forgetting that an explicit deny always wins, even if an allow exists. Another exam trap is assuming that a deny in a resource-based policy (like an S3 bucket policy) can be bypassed by an identity-based policy-this is false because the deny, if applicable, blocks all access. In Azure, RBAC roles work on an allow-only basis, but Azure Policy can create deny effects that override role assignments. For the CompTIA Security+ and CySA+ exams, understanding this logic is essential for identifying privilege escalation risks. For example, if a developer attaches a policy with both Allow and Deny statements for the same action, the evaluation engine will process the deny first and block the allow. This is why best practices recommend using explicit denies sparingly and only for specific constraints, such as denying access to sensitive API actions unless originating from a VPC endpoint. In multi-cloud environments, the evaluation logic may differ: AWS uses a deny-by-default model with explicit override rules, while GCP roles are additive and deny policies are separate. However, both follow the principle of least privilege. The IAM evaluation logic is also tested in the context of condition keys: a condition like 'aws:SourceIp': '10.0.0.0/8' can restrict an allow to a specific network, but if a deny condition is broader, the deny still wins. Mastering this logic helps in designing secure architectures and passing exams that focus on identity management.

## Using IAM Policy Condition Keys to Restrict Access

IAM policy condition keys are powerful tools that allow administrators to fine-tune access permissions based on contextual attributes such as IP address, time of day, user agent, MFA status, or resource tags. In AWS, conditions are written in the 'Condition' block of an IAM policy using operators like 'StringEquals', 'IpAddress', 'Bool', and 'DateLessThan'. For example, a condition 'aws:MultiFactorAuthPresent': 'true' ensures that only authenticated users with MFA can perform sensitive actions. This is a common exam topic for the AWS Certified Security – Specialty and the ISC2 CISSP because it addresses a critical security control: requiring step-up authentication for high-risk operations. In GCP, conditions are part of IAM roles and use Common Expression Language (CEL) syntax, such as 'resource.name.startsWith("projects/example/instances/")'. Azure uses Azure Active Directory conditional access policies and Azure Policy conditions for RBAC. The key exam concept is that condition keys can prevent broad policy statements from being too permissive. For instance, an AWS IAM policy that allows ec2:TerminateInstances can be restricted with a condition that the instance must have a tag 'Environment=Production' to avoid accidental termination of critical resources. Without conditions, a single policy might grant dangerous permissions to all resources. Exams also test edge cases like using multiple conditions: if you have two conditions in a policy statement, all conditions must be met (AND logic) for the policy to apply. However, if you have multiple condition blocks in different statements, the evaluation uses OR logic across statements. Another exam trap involves the use of the 'IfExists' suffix: 'StringEqualsIfExists' only applies the condition if the key is present, preventing errors when the key is missing. For the Google ACE exam, condition keys like 'iam.googleapis.com/workforcePoolUser' are used to limit access to specific identities. The CySA+ exam might test how condition keys reduce the risk of credential theft: a stolen password alone doesn't grant access if MFA is required. In practice, condition keys are also used for compliance: for example, 'aws:RequestedRegion' restricts actions to specific regions, which is crucial for data sovereignty. When writing exam-level answers, always consider whether a condition could have prevented a breach scenario described in the question. A typical scenario: a developer has full S3 access; the exam asks how to restrict it to only objects with a certain prefix. The answer is to add a condition like 's3:prefix': 'logs/'. Another scenario: preventing access from outside corporate IP range. The condition would be 'aws:SourceIp': '203.0.113.0/24'. These details are frequently tested in the AWS Developer Associate and SysOps Administrator exams. Understanding condition keys is also vital for troubleshooting permission errors: if a user has an allow policy but access is denied, check if a condition is blocking the request due to IP, time, or missing tags.

## Resource-Based IAM Policies vs Identity-Based Policies

IAM policies are broadly categorized into identity-based and resource-based policies, and understanding the difference is essential for both real-world administration and cloud certification exams. Identity-based policies are attached to a user, group, or role, and they define what actions that identity can perform on which resources. Resource-based policies, on the other hand, are attached directly to a resource (like an S3 bucket, AWS KMS key, or GCP Cloud Storage bucket) and define who can access that resource and what actions they can take. The key exam insight is that resource-based policies can grant access to identities from other AWS accounts or GCP projects without needing cross-account roles. For example, an S3 bucket policy can allow a user from a different AWS account to read objects, whereas an identity-based policy in the source account cannot grant access outside its own account. This is a classic exam question for the AWS Solutions Architect Associate: 'How do you grant cross-account access to an S3 bucket without creating an IAM role?' The answer is to use a bucket policy. In GCP, resource-based policies are called 'IAM policies on resources' and are set using commands like gsutil iam ch. For Azure, similar concepts exist, but Azure uses role assignments at the resource scope. The evaluation of resource-based policies is also distinct: when a principal makes a request, AWS evaluates both the identity-based policies and the resource-based policies. If either grants permission, and no explicit deny exists, access is allowed. This is known as the 'union of policies' model, but note that explicit denies in either policy will block access. This model is tested in the AWS Security Specialty exam, where candidates must identify that a user might have full S3 access via identity-based policy, but a bucket policy restricting access to a specific VPC will override the allow. Resource-based policies support 'Principal' element, which defines the target identity. In AWS, you can specify an entire account, a specific user, or a role. A common exam scenario involves granting cross-account access to a Lambda function: the Lambda resource-based policy (function policy) must allow the source account's identity to invoke the function. For GCP, resource-based policies often involve setting bucket-level permissions for Compute Engine service accounts. The CISSP exam tests the concept of resource-based policies in the context of access control models (DAC vs MAC), noting that resource-based policies are characteristic of discretionary access control because the resource owner can grant access. In contrast, identity-based policies are more centralized and similar to mandatory access control when enforced by an administrator. For practical troubleshooting, if a user with full admin permissions cannot access a resource, check if a resource-based policy explicitly denies the action or restricts access to a specific network. Another exam clue: in AWS, resource-based policies are limited to specific services-S3, SQS, SNS, Lambda, KMS, and a few others. For services without resource-based policies, cross-account access requires IAM roles. This distinction is frequently tested in the Azure Administrator (AZ-104) exam, where Azure RBAC is identity-based, but Azure resource-specific policies (like Azure Policy) can override. Understanding these differences helps in designing secure and scalable cloud architectures.

## IAM Permissions Boundaries as a Security Control

IAM permissions boundaries are a feature in AWS that allow administrators to set the maximum permissions that an IAM entity (user or role) can have. They act as a guardrail, ensuring that even if a policy grants extensive permissions, the effective permissions are limited by the boundary. This is a critical security control for environments where developers or teams need to create their own roles. For example, an administrator can create a permissions boundary that allows EC2 access but denies access to IAM management. If a developer then creates a role and attaches a policy that allows IAM full access, the role's effective permissions will be the intersection of the boundary and the attached policies. Therefore, the role cannot perform IAM actions. This concept is heavily tested in the AWS Certified SysOps Administrator and DevOps Engineer exams. The exam questions often present a scenario where a junior admin creates a role with overly permissive policies, and the task is to identify why certain actions are blocked-the answer often lies in a permissions boundary that was set at the account level. Permissions boundaries are also used to enforce the principle of least privilege: they prevent privilege escalation. For instance, if a role has a policy that allows iam:PassRole, without a boundary, the role could pass a role with higher privileges. With a boundary, the PassRole action is limited to roles that are within the boundary's scope. Another important exam detail is that permissions boundaries only apply to identity-based policies, not resource-based policies. So if an S3 bucket policy grants access to a role, the boundary does not affect that access. This is a common exam trap: candidates think boundaries restrict all access, but they only affect identity-based actions. Also, permissions boundaries can be set only on IAM roles (not users) in many contexts, though AWS now supports user boundaries. For the Google ACE exam, a similar concept exists with IAM conditions and roles that restrict the ability to grant roles-but not a direct boundary. Azure uses Azure Policy with 'deny' effect and management groups to achieve similar outcomes. The CySA+ and Security+ exams test permissions boundaries as a form of defense in depth: even if an attacker compromises a set of credentials, the boundary limits the blast radius. For example, a developer's role might have a boundary that restricts actions to a single region. If the attacker tries to launch resources in another region, the boundary denies it. In exam scenarios, you must identify when to use a permissions boundary versus a specific deny policy. The key difference: a permissions boundary is a ceiling-it does not grant permissions, it only limits them. An explicit deny can be used to block specific actions regardless of the boundary. A typical question: 'An admin wants to ensure that any role created in a specific account cannot access the billing dashboard. What should they do?' Answer: Create a permissions boundary that denies billing:GetAccountBilling and billing:ViewBilling. When setting up a permissions boundary, the policy document uses the same syntax as a standard IAM policy. For example, the 'Effect' can be 'Allow' to define allowed actions, but the boundary only contains Allow statements; the effective outcome is that actions not listed are implicitly denied. However, if the attached policy has a Deny statement, that deny still takes effect. This nuance is important for advanced exam questions. In practice, permissions boundaries are used in multi-account architectures with AWS Organizations to enforce compliance.

## Common mistakes

- **Mistake:** Using a wildcard '*' for the Action field in a policy.
  - Why it is wrong: Granting all actions to any user violates the principle of least privilege. It gives users the ability to perform operations they do not need, such as deleting resources or changing configurations, which can lead to security incidents and accidental damage.
  - Fix: Specify only the exact actions the user needs, like 's3:GetObject' and 's3:PutObject' instead of 's3:*'.
- **Mistake:** Confusing identity-based policies with resource-based policies.
  - Why it is wrong: Identity-based policies are attached to users, groups, or roles and grant permissions to that identity. Resource-based policies are attached to resources and specify who can access that resource. Using one when you need the other will not work as expected. For example, if you attach a policy to an S3 bucket that allows a user to read it, but the user's identity-based policy does not allow 's3:GetObject,' the request will still be denied.
  - Fix: Understand the difference. Use identity-based policies to grant permissions to a user or role. Use resource-based policies to control access to a resource from any principal (including users from other accounts) that tries to access it.
- **Mistake:** Forgetting about the default deny and the explicit deny override.
  - Why it is wrong: If you only create an allow policy without considering denials, you might think a user has access when they do not (because of default deny). Conversely, if you have an explicit deny policy anywhere, it will block access even if another policy allows it. Not understanding this logic leads to permission errors that are hard to debug.
  - Fix: Always remember that an explicit deny overrides any allow. If you get an unexpected access denied error, check for explicit deny statements in all policies (identity-based, resource-based, and organizational policies).
- **Mistake:** Hardcoding access keys in code or configuration files instead of using IAM roles.
  - Why it is wrong: Access keys are long-term credentials. If they are hardcoded, they can be leaked in source code repositories, logs, or accidental exposures. An IAM role provides temporary credentials that are rotated automatically, reducing the risk of compromise.
  - Fix: Always use IAM roles for applications running on cloud compute services (like EC2, Compute Engine, or Azure VMs). Use IAM roles for Lambda functions, and use service accounts in Kubernetes.
- **Mistake:** Not using conditions in policies to add security constraints.
  - Why it is wrong: Without conditions, a policy applies everywhere and under all circumstances. For example, a policy that allows 's3:GetObject' on a bucket means anyone from anywhere can read the data if they have the access key. This is risky, especially for sensitive data.
  - Fix: Add conditions to your policies, such as requiring MFA, restricting to a specific IP range, or limiting access to a specific VPC endpoint. This adds a layer of security and ensures that even if credentials are stolen, the attacker cannot use them from an unauthorized location.
- **Mistake:** Using the root user or super-admin account for daily tasks.
  - Why it is wrong: The root user has unrestricted access and there is no way to limit it. If an attacker gains access to the root user account, they can do anything, including deleting all resources and billing information. Using the root user for daily tasks greatly increases the attack surface.
  - Fix: Create administrative IAM users or roles and use them for daily tasks. Enable MFA on the root account and store its credentials securely. Only use the root account for tasks that specifically require it, such as changing account-level settings.

## Exam trap

{"trap":"An exam question presents a scenario where a user has an identity-based policy that allows 's3:PutObject' on a bucket, but the user gets an access denied error when trying to upload a file. The question suggests that the user does not have the correct permissions on their identity-based policy.","why_learners_choose_it":"Learners tend to focus only on the identity-based policy because that is the most common way to grant permissions. They forget that the resource-based policy (the bucket policy) must also allow the action. If the bucket policy explicitly denies 's3:PutObject' for that user, the deny overrides the allow, causing the error.","how_to_avoid_it":"Always check both sides of the permission: the identity-based policy of the user and the resource-based policy of the target resource. Remember the evaluation logic: an explicit deny from any policy overrides any allow. When troubleshooting access denied errors, look for deny statements in all applicable policies, not just the user's own policy."}

## Commonly confused with

- **IAM policy vs IAM role:** An IAM policy is a document that defines permissions. An IAM role is an identity that you can attach a policy to. The role is assumed by a user or service to obtain temporary credentials. Think of the policy as the rulebook and the role as the hat you put on to use those rules. (Example: You create a policy that allows reading from a database. You then attach that policy to a role called 'DBReaderRole.' When an EC2 instance assumes 'DBReaderRole,' it gets permission to read the database. The policy is the document; the role is the entity that carries it.)
- **IAM policy vs IAM group:** An IAM policy is attached to a group to grant permissions to all members of the group. The group itself is a container for users. Without the policy, the group has no permissions. The policy provides the permissions; the group organizes users. (Example: You create a group called 'Developers' and attach a policy that allows deploying code to a staging environment. Any user added to the 'Developers' group automatically gets those permissions because the policy is attached to the group.)
- **IAM policy vs IAM user:** An IAM user is a specific person or service with long-term credentials. An IAM policy can be attached directly to a user to grant permissions. The user is the identity; the policy defines what that identity can do. (Example: You create an IAM user named 'Alice' and attach a policy that allows her to manage S3 buckets. Now Alice can sign in to the AWS console and perform those actions. The policy is the set of permissions; Alice is the person using them.)
- **IAM policy vs Azure Policy:** Azure Policy is a service that enforces rules on Azure resources to ensure compliance (e.g., all resources must be tagged with a cost center). IAM policy (Azure RBAC) controls who can access resources and what actions they can perform. Azure Policy is about resource configuration; IAM policy is about access control. (Example: An Azure Policy might say 'All VMs must use managed disks.' An IAM policy says 'User Bob can start and stop VMs but cannot delete them.' They serve different purposes.)
- **IAM policy vs IAM permission boundary:** A permission boundary is a managed policy that sets the maximum permissions an identity-based policy can grant. It does not grant permissions itself. It acts as a ceiling. An IAM policy is the actual set of permissions. The permission boundary limits how high the policy can go. (Example: You set a permission boundary that says 'max permissions include EC2 and S3 only.' Then you attach an identity-based policy that allows 's3:*' and 'ec2:*' and 'iam:*.' The user actually gets only 's3:*' and 'ec2:*' because the boundary blocks the IAM actions.)

## Step-by-step breakdown

1. **Identify the principal** — Determine who or what needs access. This could be a user, a group, a role, or a service (like a virtual machine or a serverless function). In IAM, the principal is the entity that will make the API request. Knowing the principal helps you decide whether to attach the policy to that principal or to the resource.
2. **Define the resource** — Identify the cloud resource that the principal needs to access. This could be an S3 bucket, a Cloud Storage bucket, an Azure VM, a database, or any other resource. The resource is identified by a unique identifier, such as an Amazon Resource Name (ARN) in AWS, a resource name in GCP, or an Azure resource ID.
3. **List the required actions** — Specify the exact API operations the principal needs to perform on the resource. Examples include reading a file (s3:GetObject), writing a file (s3:PutObject), starting a VM (ec2:StartInstances), or querying a database (dynamodb:Query). Keep the list as narrow as possible to follow least privilege.
4. **Decide the effect** — Choose between Allow or Deny. Most policies use Allow to grant permissions. Deny is used when you want to explicitly block a specific action even if another policy would allow it. Remember that an explicit deny always overrides any allow, so use Deny sparingly.
5. **Add conditions (optional but recommended)** — Add conditions to restrict when the policy is in effect. Common conditions include requiring MFA, limiting access to a specific IP range, restricting to a specific time of day, or requiring that the request come from within a specific VPC. Conditions add an extra layer of security and help meet compliance requirements.
6. **Write the policy document** — Format the policy as a JSON document with the Version, Statement, and the required fields (Effect, Action, Resource). For resource-based policies, also include the Principal field to specify who the policy applies to. Ensure correct syntax: no trailing commas, proper quotes, and valid JSON. Use the cloud provider's policy generator tool to avoid errors.
7. **Attach the policy** — Attach the policy to the appropriate identity (user, group, role) or to the resource. In AWS, you attach identity-based policies to users, groups, or roles. Resource-based policies are attached to the resource itself. In GCP, you attach policies at the project, folder, or organization level, or you assign roles to direct members. In Azure, you assign role definitions at the management group, subscription, resource group, or resource scope.
8. **Test the policy** — Verify that the policy works as intended. Use the cloud provider's IAM policy simulator (AWS), Policy Troubleshooter (Azure), or the IAM Policy Analyzer (GCP). Test both allowed and denied actions. Make sure that legitimate actions are permitted and that forbidden actions are blocked. Also, test with conditions to ensure they are evaluated correctly.
9. **Monitor and audit** — Enable logging for IAM actions, such as AWS CloudTrail, GCP Cloud Audit Logs, or Azure Activity Logs. Regularly review who has what permissions. Look for overly permissive policies or unused roles. Use tools like AWS IAM Access Analyzer or Azure AD Identity Protection to detect potential security issues. Adjust policies as roles and requirements change.
10. **Iterate and refine** — Policies are not static. As your organization grows and new services are added, you will need to update policies. Remove permissions that are no longer needed. Add new permissions for new use cases. Always follow the principle of least privilege. Use automation to enforce policy standards, such as using Infrastructure as Code (IaC) tools like Terraform or CloudFormation to deploy policies consistently.

## Practical mini-lesson

In practice, writing and managing IAM policies is a daily task for cloud administrators and security engineers. You will often start by using managed policies provided by the cloud provider, such as 'AmazonS3ReadOnlyAccess' or 'Azure Backup Contributor.' These are pre-built policies that cover common use cases. However, many real-world situations require custom policies. For example, your application might need to read from a specific S3 bucket and write to a specific DynamoDB table. You would write a custom policy that lists only those exact actions and resources. 

 

 One critical practice is to use the principle of least privilege. This means you should start with minimum permissions and add more only when necessary. For instance, if a developer needs to deploy code to an Elastic Beanstalk environment, do not give them full Elastic Beanstalk access. Instead, give them permissions only for the specific environment and only for the actions they need, like 'elasticbeanstalk:UpdateEnvironment' and 'elasticbeanstalk:DescribeEnvironmentHealth.' This reduces the risk of accidental changes to other environments. 

 

 Another important concept is the use of conditions. Conditions are powerful. They allow you to add context to your policies. For example, you can write a condition that says 'Allow s3:PutObject only if the request comes from the corporate network (IP range 203.0.113.0/24).' This way, even if a developer's access keys are compromised, an attacker outside the corporate network cannot use them to upload malicious files. You can also require MFA for sensitive actions. In Azure, you can use Conditional Access policies to require a compliant device before granting access. 

 

 What can go wrong? The most common problem is creating policies that are too permissive. Using a wildcard '*' for the Action field is a classic mistake. Another issue is not testing policies before deploying them to production. You might accidentally lock yourself out of your own account if you delete or modify a policy that grants you administrative access. Always have a break glass account or a recovery process in place. Also, be aware of policy inheritance. In GCP, policies at the organization level apply to all projects underneath. In Azure, policies at the subscription level apply to all resource groups. Understand the hierarchy to avoid unintended permissions. 

 

 For professionals, learning to read and write JSON policies is essential. Use the cloud provider's policy editor or a JSON validator to check syntax. Many cloud providers offer a visual policy builder, but understanding the raw JSON is still important for exams and for complex configurations. Finally, remember that IAM policies are just one part of a defense-in-depth strategy. Combine them with network security groups, firewalls, encryption, and monitoring to create a comprehensive security posture.

## Commands

```
aws iam create-policy --policy-name MyPolicy --policy-document file://policy.json
```
Creates a customer managed IAM policy in AWS from a JSON file, which can then be attached to users, groups, or roles.

*Exam note: Tests the distinction between managed and inline policies. Exam questions often require creating a policy for cross-account access or compliance.*

```
gcloud iam roles create MyRole --project=my-project --file=role.yaml
```
Creates a custom IAM role in GCP using a YAML definition file, allowing fine-grained permissions beyond predefined roles.

*Exam note: Google ACE and Digital Leader exams test custom roles to enforce least privilege. The YAML file defines permissions and stages.*

```
az role assignment create --assignee user@example.com --role Contributor --scope /subscriptions/12345/resourceGroups/MyRG
```
Assigns the built-in Contributor role to a user at a resource group scope in Azure, granting them permissions to manage resources within that group.

*Exam note: Azure AZ-104 and SC-900 exams test RBAC scope hierarchy (subscription, resource group, resource). Understanding scope inheritance is critical.*

```
aws iam attach-user-policy --user-name Bob --policy-arn arn:aws:iam::123456789012:policy/MyPolicy
```
Attaches a managed policy directly to an IAM user, granting the permissions defined in the policy document.

*Exam note: CompTIA Security+ and CySA+ exams test the difference between attaching a policy to a user vs. a group. This command is used when direct assignment is needed.*

```
gsutil iam ch user:alice@example.com:objectViewer gs://my-bucket
```
Adds a user as an object viewer on a GCP Cloud Storage bucket via a resource-based policy, granting read access to objects.

*Exam note: Google ACE exam tests resource-based policies. This command shows how to grant cross-identity access without roles.*

```
aws iam put-user-permissions-boundary --user-name DevUser --permissions-boundary arn:aws:iam::123456789012:policy/DevBoundary
```
Applies a permissions boundary to an IAM user, limiting the maximum permissions the user can have through any attached policies.

*Exam note: AWS SysOps and Security Specialty exams test permissions boundaries as a privilege escalation prevention. Questions often present scenarios where boundaries block overly permissive policies.*

```
gcloud projects set-iam-policy my-project policy.json
```
Sets the full IAM policy for a GCP project, replacing any existing bindings. Policy file must be correctly formatted.

*Exam note: GCP ACE exam warns against overwriting existing policies without careful planning. This command can inadvertently remove existing access if not merged.*

## Troubleshooting clues

- **Access Denied Despite Allow Policy** — symptom: User receives 'AccessDenied' error even though they have an IAM policy that explicitly allows the action.. An explicit deny in another policy (resource-based, service control policy, or permissions boundary) overrides the allow. Also, conditions may not be met (e.g., wrong IP or missing MFA). (Exam clue: Exam questions often present a user with full admin access but denied to a specific S3 bucket. The answer is an explicit deny in the bucket policy or SCP.)
- **Cross-Account Access Fails** — symptom: User from Account A cannot access a resource in Account B even after setting up a trust policy.. The resource-based policy (e.g., S3 bucket policy) must have a Principal that includes the Account A user/role. Also, the identity policy in Account A must allow the action, and the trust policy in Account B must trust the Account A identity. (Exam clue: The AWS Solutions Architect exam tests the three-part configuration: trust policy, identity policy, and resource policy. Missing any one causes failure.)
- **Permission Boundary Blocks Role Creation** — symptom: Administrator cannot create an IAM role with a desired set of permissions.. A permissions boundary policy attached to the role (or one assigned to the creating user) limits the maximum permissions. The role's effective permissions are the intersection of the policy and boundary. (Exam clue: This is a classic exam scenario: a developer creates a role with admin permissions but it fails because a boundary restricts iam:CreateRole or the role's permissions.)
- **Condition Key Not Evaluated Correctly** — symptom: Access is allowed or denied when the condition should have blocked it.. Condition keys might be case-sensitive (e.g., 'aws:SourceIp' vs 'sourceIp') or the operator is wrong (e.g., using StringEquals instead of IpAddress). Also, some condition keys require specific services to support them (e.g., 'aws:RequestedRegion' works with EC2 but not all services). (Exam clue: The AWS Developer Associate exam tests condition key typos. A common trap is using 'StringEquals' for IP address instead of 'IpAddress'.)
- **Identity-Based Policy Not Inherited by Service Role** — symptom: A service (e.g., Lambda) assumes a role, but the role's actions are more restrictive than expected.. The service role's identity-based policy is evaluated, but if the service also has a resource-based policy (e.g., Lambda function policy), the union of permissions is considered. The trust policy must allow the service to assume the role. (Exam clue: AWS Security Specialty questions test the interaction between service roles and resource policies. For example, a Lambda function might fail to write to CloudWatch if the role lacks logs:CreateLogGroup.)
- **GCP IAM Role Permissions Not Additive** — symptom: User gets 'Permission denied' for an action that seems to be allowed by multiple roles.. In GCP, custom roles might not include the necessary permissions. Even if multiple roles grant overlapping permissions, the missing permission must be explicitly included. Also, deny policies (separate from roles) can block actions. (Exam clue: Google ACE exam tests that custom roles require explicit listing of permissions. A user with both Viewer and Editor roles may still be denied if the action is not in the role definitions.)
- **Azure RBAC Role Assignment Not Applying** — symptom: User added to a built-in role at resource group scope but cannot manage resources within that group.. The role assignment might have been made at a higher scope (e.g., subscription) that has a deny assignment from Azure Policy overriding the RBAC allow. Also, the role may not include necessary data actions (e.g., reading data in a storage account requires a separate data role). (Exam clue: AZ-104 exam scenarios: a user is a Contributor but cannot read blobs because the Contributor role does not include data actions. The solution is to assign Storage Blob Data Reader.)

## Memory tip

Deny always wins. Default is deny. Write allow only for what is needed.

## FAQ

**What is the difference between an IAM policy and an IAM role?**

An IAM policy is a document that defines permissions. An IAM role is an identity that can assume the policy to get temporary credentials. You attach policies to roles, users, or groups.

**Can I use the same IAM policy for multiple users?**

Yes, you can attach the same policy to multiple users, groups, or roles. This is efficient because you only need to update one policy to change permissions for all attached identities.

**What happens if I have two policies that conflict?**

If one policy allows an action and another denies it, the deny wins. If both allow, the action is allowed. If neither allows, it is denied by default.

**How do I troubleshoot an access denied error?**

Check the user's identity-based policy, the resource-based policy, any permission boundaries, and organizational policies. Use the cloud provider's policy simulator to trace the decision.

**Do I need to use IAM policies if I am the only user in my cloud account?**

Yes. Even as a single user, you should follow best practices. Use an IAM user with only the permissions you need, and enable MFA. Avoid using the root account for daily tasks.

**Can I create a policy that only allows access during business hours?**

Yes, you can use a condition with an 'aws:CurrentTime' variable in AWS, or similar mechanisms in Azure and GCP, to restrict access to specific hours.

**What is the maximum size of an IAM policy in AWS?**

The maximum size of an IAM policy is 6144 characters in AWS. If you need more, you can use multiple policies or a managed policy.

## Summary

IAM policy is the foundational mechanism for controlling access to cloud resources. It is a JSON document that explicitly grants or denies specific actions on specific resources for a given principal. Understanding how IAM policies work, including the evaluation logic (default deny, explicit deny override), the difference between identity-based and resource-based policies, and the importance of least privilege, is essential for any cloud professional. 

 IAM policies matter because they directly impact security, compliance, and operational efficiency. A well-designed policy prevents unauthorized access, reduces the risk of data breaches, and helps organizations pass audits. In exams, IAM policy questions test your ability to read policies, identify misconfigurations, and apply the evaluation logic to solve permission errors. You need to know the specific syntax and features for each cloud provider you are studying. 

 The key takeaway for exams is to remember that deny always wins and default is deny. Focus on writing policies that grant only the minimum necessary permissions. Use conditions to add context. Practice with sample policies and simulator tools. IAM is not a topic you can skip; it is the bedrock of cloud security and appears in almost every cloud certification exam. Master it to be confident on exam day and in your real-world cloud career.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/iam-policy