AWS Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) controls authentication and authorization for AWS resources through identities, roles, policies, and permissions. For a Java backend engineer, the key skill is understanding how an application or developer obtains AWS credentials and how IAM policies determine what those credentials can do.

IAM separates identity from permission. An identity can authenticate to AWS, while authorization determines whether that identity is allowed to perform a particular action on a particular resource. IAM policies are JSON documents that describe permissions, commonly using `Effect`, `Action`, `Resource`, and optional `Condition` elements.

IAM users represent individual identities, but applications running on AWS commonly use IAM roles instead of long-lived access keys. A role is assumed to obtain temporary credentials, which reduces the need to store permanent credentials inside application code or configuration.

An IAM role has a trust policy describing who or what may assume the role, and permission policies describing what the role can do after it is assumed. These are different concerns: the trust relationship controls assumption, while permissions control subsequent AWS API operations.

AWS evaluates applicable policies when an authenticated principal requests an operation. An explicit `Deny` takes precedence over an `Allow`; otherwise, a request must have an applicable permission allowing the action. Policies should follow least privilege by granting only the actions and resources required by the workload.

Key points

• IAM handles authentication and authorization for AWS resources.
• IAM roles provide temporary credentials and are commonly preferred for workloads over long-lived access keys.
• A role's trust policy controls who can assume it; permission policies control what the assumed role can do.
• IAM policies commonly specify `Effect`, `Action`, and `Resource`, with `Condition` available for additional restrictions.
• Explicit `Deny` overrides an applicable `Allow`.
• Least privilege means granting only the permissions required for a task.

Interview questions

How does IAM handle conflicting Allow and Deny statements?

AWS evaluates the applicable policies for the request. An applicable explicit `Deny` takes precedence over an `Allow`. If there is no applicable deny, the request needs an applicable permission that allows the requested operation. This means adding an Allow does not overcome an explicit Deny elsewhere in the applicable policy evaluation.

Why would a Java application running on AWS use an IAM role instead of access keys?

An IAM role lets the application obtain temporary credentials without embedding a long-lived access key in the application. AWS compute environments can make role credentials available to the workload through the platform's credential mechanism. The AWS SDK for Java can discover these credentials through its credential-provider chain. This reduces credential-management and accidental-secret-exposure risks.

What is AWS IAM, and what problem does it solve?

IAM is AWS's system for controlling access to AWS resources. It defines identities such as users and roles and associates permissions with them through policies. When a request reaches an AWS service, IAM authorization determines whether the caller may perform the requested action. This lets teams control access without putting authorization logic into every application.

What is the difference between a role's trust policy and its permissions policy?

The trust policy defines which principals are allowed to assume the role. The permissions policies define what actions the role can perform after it has been assumed. Therefore, a principal can be trusted to assume a role but still have limited access to AWS resources through the role's permissions. Keeping these concerns separate is important when diagnosing access failures.

How would you apply least privilege to an AWS-backed Java service?

I would identify the AWS API operations the service actually needs and grant only those actions. I would also scope resources as narrowly as practical and use policy conditions when additional constraints are appropriate. The service would use an IAM role and temporary credentials rather than embedded long-lived keys. I would periodically review and reduce permissions as the application's behavior changes.