Episode 29: IAM Roles & Policies
IAM roles are one of the most important tools for secure access management in AWS. Unlike IAM users, which are long-term identities with static credentials, roles provide temporary, scoped permissions. They are assumed by people, services, or applications that need access, and they rely on AWS Security Token Service to issue short-lived credentials. This design reduces the risk of exposure from long-lived passwords or keys. For the AWS Certified Cloud Practitioner exam, it is critical to know that IAM roles enable flexible, temporary, and least-privilege access.
A role is made up of two key components: a trust policy and a permissions policy. The trust policy defines who or what can assume the role—for example, an EC2 instance, a Lambda function, or a user in another account. The permissions policy defines what actions the role can perform once assumed. Together, these policies form a clear boundary of trust and capability. On the exam, remember that roles have both trust and permissions elements, which work together to define their behavior.
AWS Security Token Service, or STS, underpins roles by issuing short-lived credentials. These credentials typically last from minutes to hours and expire automatically, reducing the risk of misuse if they are ever leaked. For example, when an application assumes a role, STS provides temporary credentials for it to access S3. For the exam, remember that STS is the engine that provides time-limited access through IAM roles.
AWS provides managed policies as a starting point for permissions. These are prebuilt, curated policies maintained by AWS and designed to cover common use cases like read-only access or full access to a service. Managed policies are broad and convenient but may grant more permissions than needed. For the exam, know that AWS managed policies are reusable and updated by AWS but often need refinement for strict least-privilege scenarios.
Customer managed policies provide a more tailored option. These are policies created and controlled by customers, allowing precise definitions of permissions. They can be versioned and reused across identities, making them both flexible and auditable. For example, a company may create a customer managed policy that allows only specific S3 actions in designated buckets. For exam purposes, remember that customer managed policies are preferred for long-term control when AWS managed policies are too broad.
Inline policies are another type, directly embedded into a single user, group, or role. They cannot be reused or versioned separately, making them harder to manage at scale. Inline policies are best for one-off permissions tightly coupled to a specific identity. For example, a role supporting a unique application might use an inline policy for custom access. On the exam, remember that inline policies are less flexible and harder to maintain compared to managed policies.
Resource policies differ from identity policies. Resource policies are attached directly to AWS resources, such as S3 bucket policies, KMS key policies, or SQS queue policies. They specify who can access the resource and under what conditions. Identity policies, by contrast, are attached to users, groups, or roles. Both work together to define access. On the exam, know that resource policies live with the resource itself, while identity policies follow the user or role.
Use cases for IAM roles include EC2 instance roles and Lambda execution roles. An EC2 instance role allows a virtual machine to access services like S3 without embedding credentials in the instance. A Lambda execution role allows the function to interact with services like DynamoDB or CloudWatch. These use cases highlight how roles replace static credentials with dynamic, secure access. On the exam, expect questions about which role type supports which workload.
Cross-account access is another powerful application of IAM roles. Rather than creating duplicate accounts in multiple AWS environments, administrators can allow users or services from one account to assume a role in another. For example, a central security team may assume roles in other accounts to audit logs. For the exam, know that cross-account access relies on IAM roles and trust policies, not duplicated IAM users.
Session duration and session policies add further refinement to roles. Administrators can define how long a role session lasts, balancing convenience with security. They can also attach session policies to limit the permissions granted during a specific session, even if the role’s full permissions are broader. For the exam, remember that roles can be scoped by session duration and policies to reduce exposure.
Policies are tracked using ARNs, or Amazon Resource Names. Each managed policy has a unique ARN and can be versioned. For example, a customer managed policy may have multiple versions stored, allowing rollback if needed. This provides auditability and control. On the exam, know that policies are identified by ARNs and that versioning helps manage changes over time.
Evaluation logic in IAM policies is simple but powerful. By default, all requests are denied. An explicit allow grants permission, but an explicit deny always overrides it. This means that deny statements take precedence over allow statements. On the exam, remember the order: default deny, explicit allow, and explicit deny overrides everything.
Least privilege requires iteration as workloads evolve. Permissions should start broad during testing and then be narrowed over time as usage patterns become clear. For example, a developer may initially have full access to a service but later be restricted to only the specific actions required. For the exam, remember that least privilege often involves tightening policies over time.
Validation tools like IAM Access Analyzer and the policy simulator help confirm policies behave as intended. Access Analyzer checks for overly broad permissions, such as resources shared publicly, while the simulator lets administrators test policies before deploying them. On the exam, know that these tools support safe implementation of IAM roles and policies.
For more cyber related content and books, please check out cyber author dot me. Also, there are other prepcasts on Cybersecurity and more at Bare Metal Cyber dot com.
A practical approach to IAM policy design is to begin with AWS managed policies and then refine with customer managed ones. Managed policies from AWS provide a strong starting point because they are maintained and updated by AWS itself. However, these policies often include broader permissions than necessary. By layering in custom policies, administrators can narrow the scope to match least-privilege requirements. For exam purposes, remember that managed policies are best for convenience and learning, while customer managed policies are best for long-term precision.
Boundary policies provide another tool for delegating administration while maintaining control. A permissions boundary is a policy attached to a role or user that defines the maximum permissions they can have, even if other policies try to grant more. For example, an administrator might give a developer the ability to create IAM roles, but a boundary prevents those roles from granting full account-level access. On the exam, know that permissions boundaries cap privileges and serve as safeguards in delegated environments.
Explicit deny guardrails are often used for destructive actions. Policies can include deny rules for tasks like deleting logs, disabling encryption, or terminating critical resources. For example, a deny guardrail could prevent any user from disabling CloudTrail, even if their policy otherwise grants broad permissions. On the exam, remember that explicit denies are powerful tools for enforcing critical security requirements.
Scoped-down policies using resource-level controls further enforce least privilege. Instead of allowing access to “all S3 buckets,” a policy might restrict permissions to a specific bucket or even a folder within a bucket. Similarly, access to DynamoDB can be scoped to one table. Narrowing scope ensures that even if credentials are misused, the impact is limited. On the exam, know that scoping by resource is a best practice.
Conditions in IAM policies allow fine-grained restrictions based on context. Policies can require that access comes from specific IP ranges, is performed only if MFA is enabled, or only during certain times of day. Conditions can even enforce that requests must come through VPC endpoints for private networking. For example, an organization might restrict administrative actions to be executed only from the corporate network. On the exam, remember that conditions add context to enforce tighter security.
Service-linked roles provide minimal, AWS-managed access for services to perform specific functions. These roles are created automatically and contain only the permissions required for that service. For example, Amazon RDS creates service-linked roles to manage backups and monitoring. Customers don’t have to write these roles manually. On the exam, remember that service-linked roles are predefined by AWS to support its own services securely.
Organizations often create a library of standard role patterns. Common examples include a read-only role for auditors, a deployer role for CI/CD pipelines, or a database manager role. These patterns provide consistency, making it easier to grant the right permissions quickly. For exam preparation, know that building role libraries supports standardization and avoids reinventing permissions every time.
One of the strongest benefits of roles is that they eliminate the need for key rotation in applications. Instead of embedding IAM user keys, workloads assume roles that automatically generate temporary credentials. For example, an EC2 instance role retrieves temporary access keys from the metadata service, rotating them automatically. On the exam, remember that roles remove the need for long-lived credentials in applications.
Monitoring role usage is a best practice for ongoing security. AWS provides last-used data for IAM policies, showing when a role or permission was actually invoked. Reviewing this data allows administrators to remove unnecessary permissions and clean up unused roles. For example, if a Lambda execution role hasn’t accessed a service in months, it may not need that permission anymore. On the exam, remember that monitoring usage supports continuous least-privilege refinement.
Break-glass roles are highly privileged roles reserved for emergencies. These roles are isolated, monitored, and tightly controlled. For example, if an outage requires direct administrative intervention, a break-glass role provides the needed access but alerts the security team when it is assumed. This ensures accountability while reducing the chance of abuse. For exam purposes, know that break-glass roles exist for emergencies and should trigger alerts when used.
A multi-account role strategy is essential for organizations using AWS Organizations. Roles can be designed for cross-account access, allowing administrators or security teams to operate centrally without duplicating users. For example, a centralized operations account may assume roles into all member accounts to enforce governance. On the exam, remember that multi-account setups rely on cross-account IAM roles, not duplicated IAM users.
On the exam, you will often be asked to choose the correct type of policy. The right answer usually depends on the use case. For example, AWS managed policies are best for general access, customer managed policies for tailored long-term control, inline policies for tightly bound one-offs, and resource policies when attaching rules directly to resources. Recognizing which type fits the scenario is key to exam success.
Documentation and drift detection are critical in managing IAM roles and policies. Drift occurs when a policy changes over time in ways that deviate from the intended baseline. By documenting standard patterns and monitoring for drift, organizations maintain consistency and compliance. For example, CloudFormation can detect if a deployed role no longer matches the template definition. On the exam, know that documenting IAM and detecting drift are part of good governance.
As we close this episode, remember that IAM roles and well-scoped policies deliver secure, flexible access across AWS. Managed policies provide convenience, while customer managed ones provide control. Inline and resource policies add specificity. Tools like boundaries, denies, and conditions enforce least privilege, while monitoring ensures continuous improvement. For the exam, focus on recognizing role use cases and policy types. In practice, applying these best practices reduces risk, increases efficiency, and supports secure cloud operations at scale.
