Examkin

Question

Difficulty: MediumTroubleshooting Local Development and AWS Credentials

A developer is testing a Java application locally on their workstation. The application publishes messages to an Amazon SNS topic using the AWS SDK for Java v2. The SDK client is initialized as follows:

java
SnsClient snsClient = SnsClient.builder()
.region(Region.US_EAST_1)
.build();

The developer's workstation has a shared AWS credentials file (`~/.aws/credentials`) containing a `[default]` profile with expired credentials and a `[dev]` profile with valid credentials. In the local IDE run configuration, the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are set to temporary credentials from an older session that has since expired. When the application runs, it fails with an expired token error.

Which of the following configuration steps must the developer perform to ensure the application successfully authenticates using the valid credentials from the `[dev]` profile? (Select TWO.)

  1. Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the IDE run configuration.Answer
  2. Set the AWS_PROFILE environment variable to dev in the IDE run configuration.Answer
  3. C
    Modify the Java code to pass the access key and secret key from the dev profile directly to the SnsClient.builder() initialization.
  4. D
    Update the IAM trust policy of the IAM user or role associated with the dev profile to trust the local IDE process.
  5. E
    Store the credentials as plaintext parameters in AWS Systems Manager Parameter Store and retrieve them using an unauthenticated SDK call at application startup.

Answer

Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the IDE run configuration, and set the AWS_PROFILE environment variable to dev in the IDE run configuration.
The default credential provider chain in the AWS SDK for Java v2 evaluates credentials sources in a specific order: Java system properties, Environment variables, then the Shared credentials file. Because environment variables have higher precedence, the SDK uses the expired environment variables and throws an error instead of using the shared credentials file. Removing these environment variables allows the SDK to check the shared credentials file. Specifying the profile environment variable directs the SDK to load the valid credentials from the 'dev' profile instead of falling back to the expired 'default' profile.

Step-by-Step Solution

1
Analyze the credentials lookup precedence of the default credential provider chain.
The SDK checks environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before checking the shared credentials file (~/.aws/credentials).
Since the expired credentials are set in the environment variables, the SDK uses them and fails, never reaching the profiles in the shared credentials file.
2
Unset/remove the expired credential environment variables from the IDE run configuration.
The SDK credentials provider chain falls back to checking the shared credentials file.
This allows the SDK to read profiles defined in ~/.aws/credentials.
3
Configure the SDK to use the non-default 'dev' profile.
The AWS_PROFILE environment variable is set to dev, guiding the SDK to load credentials from the [dev] profile.
Without setting AWS_PROFILE, the SDK default credentials provider will attempt to use the [default] profile, which contains expired credentials.

Key Concept

AWS SDK Credential Provider Chain Precedence and Profiles
Rate this question

Topics

Troubleshooting Local Development and AWS Credentials

More questions from this topic