IAM roles and policies

Can you explain what AWS IAM roles are and how they differ from IAM users?

IAM roles are a set of permissions that define what actions are allowed and denied by any entity, or AWS service, that assumes the role. Unlike IAM users, roles do not have standard long-term credentials (username and password or access keys) associated with them. Instead, when you assume a role, temporary security credentials are generated dynamically. This provides a secure way to delegate permissions that can be assumed by IAM users, AWS services, or users from third-party identity providers.

How would you grant cross-account access in AWS using IAM roles?

To grant cross-account access, you create an IAM role with the necessary permissions and define a trust policy that allows the other account to assume that role. The trust policy specifies the principal (typically an AWS account) allowed to assume the role. The external account’s users can then assume the role and access resources according to the permissions defined in the role’s permission policy.

What are IAM managed policies, and how do they compare to inline policies?

IAM managed policies are standalone policies that you can attach to multiple IAM users, groups, or roles. Managed policies can be AWS managed (created and managed by AWS) or customer managed (created and managed by the customer). Inline policies, on the other hand, are policies that are directly attached to a single IAM user, group, or role, and cannot be shared. Managed policies offer more flexibility and reusability compared to inline policies, which are intended for specific use cases where you want a strict one-to-one relationship between a policy and an IAM entity.

How can you ensure that IAM policies assigned to a user, group, or role adhere to the principle of least privilege?

To adhere to the principle of least privilege, you should grant only the permissions required to perform a task. Start with a minimum set of permissions and grant additional permissions as necessary. Use IAM policy conditions to restrict permissions and continuously review and audit permissions with tools like AWS Access Analyzer to identify and remove unnecessary permissions.

What is IAM policy simulation, and why is it important?

IAM policy simulation is a feature that allows you to test and validate the effects of IAM access control policies to ensure they grant the intended permissions for various actions. It’s important because it helps prevent errors in policy configurations that could either inadvertently grant excessive permissions or too restrictively limit access, thus improving security and simplifying troubleshooting.

How do you incorporate conditions in IAM policies, and can you provide an example?

IAM policies can include conditions using the “Condition” element to specify circumstances under which the policy grants or denies permissions. Conditions can be based on various factors, such as IP addresses, date/time, MFA authentication, SSL requests, etc. For example, a condition might require that MFA be present to allow access to a sensitive resource:


{"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}}


How does IAM role chaining work, and what are its limitations?

IAM role chaining occurs when a user or service assumes a role and then uses the credentials from that role to assume another role. This allows for a sequence of role assumptions. IAM role chaining has a limitation on the session duration — the total session duration cannot exceed the maximum of one hour when using role chaining.

What are policy evaluation logic in IAM, and how does AWS resolve conflicts between allow and deny statements?

IAM uses policy evaluation logic to determine whether a request is allowed or denied by evaluating all the policies attached to the IAM principal making the request. AWS resolves conflicts between an “allow” and a “deny” by giving “deny” statements precedence. If any “deny” statement applies to the request, it is denied, even if there are “allow” statements that would permit it.

How can you automatically rotate credentials for an IAM user, and why is it necessary?

To automatically rotate credentials for an IAM user, you can create an AWS Lambda function that uses AWS SDKs to generate a new access key, delete the old access key, and notify the user. Credential rotation is necessary to reduce the risk of old or potentially compromised credentials being used to gain unauthorized access to AWS resources.

What is the purpose of IAM session policies, and when would you use them?

IAM session policies are advanced policies that you pass as an argument when you programmatically create a temporary session for a role or federated user. They provide an additional layer of granularity to control what the temporary credentials can do during that session. You use session policies to further restrict permissions for a role or federated user without changing the IAM role’s attached policies.

Explain how to safely handle IAM access keys to avoid accidental exposure.

To handle IAM access keys safely, never embed them in code or share them publicly. Instead, use environment variables or encrypted credential storage like AWS Secrets Manager. Employ IAM roles for EC2 instances or other services to avoid the need for access keys. Enable CloudTrail to log API activity, and regularly audit and rotate access keys.

In the context of IAM, what are service control policies (SCPs), and how do they work?

Service control policies (SCPs) are a type of policy that you can use in AWS Organizations to manage permissions in your organization’s accounts. SCPs allow you to define the maximum permissions for members of an organization or organizational unit (OU), effectively establishing guardrails. SCPs do not grant permissions but instead allow or deny actions across all users and roles within the account, limiting what they can do even if the IAM policies attached to them grant broader permissions.