The key security requirement is to limit both scope and duration of credentials used by an external application (running outside AWS). The most secure AWS-native way to do this is to use temporary security credentials issued by AWS Security Token Service (STS), rather than long-term IAM user access keys. Temporary credentials have a short, configurable lifetime and are tied to permissions defined by an IAM role and (optionally) session policies, which enforces least privilege.

With STS AssumeRole , the application requests temporary credentials for a specific IAM role . The role’s permission policy strictly defines what AWS actions and resources the session can access. The resulting credentials automatically expire, reducing the blast radius if the credentials are exposed. This approach also supports best practices such as rotating session credentials frequently and using external IDs and condition keys (where applicable) to reduce confused-deputy risks.

Options A and B rely on long-term IAM user credentials . Even if stored in environment variables or AWS Secrets Manager, these are still persistent credentials that do not inherently meet the “limit duration” requirement and are higher risk if leaked. Secrets Manager improves storage and rotation workflows, but it does not change the fact that IAM user access keys are long-lived by default.

Option C (GetFederationToken) is not the best fit here. Federation tokens are typically used to obtain temporary credentials for a federated user session and are commonly associated with IAM users (or scenarios like providing temporary access to third parties) rather than the standard, role-based pattern for an application assuming permissions. The most direct and widely recommended method for applications needing scoped, time-bound AWS access is AssumeRole .

Therefore, D is the most secure solution: create an IAM role with least-privilege permissions and have the application call STS AssumeRole to obtain short-lived credentials for AWS API calls.