Examkin

Question

Difficulty: MediumAWS SDKs and Credential Management

A developer is building a Go application that will run in local Docker containers during development and will eventually be deployed to Amazon ECS on AWS Fargate. The application needs to retrieve objects from an Amazon S3 bucket. The developer wants to ensure that the application uses a specific local AWS CLI profile named 'dev-profile' when running locally, but seamlessly falls back to the container's task role when deployed to AWS Fargate, without requiring any code changes.

Which two actions must the developer take to achieve this configuration? (Select TWO.)

  1. Initialize the AWS SDK client using config.LoadDefaultConfig without specifying any static credentials in the source code.Answer
  2. Set the AWS_PROFILE environment variable to dev-profile in the local container's environment.Answer
  3. C
    Embed the AWS access key and secret access key for dev-profile directly within the SDK client initialization code.
  4. D
    Update the IAM trust policy of the ECS task role to allow it to be assumed by the local IAM user's credentials.
  5. E
    Configure the SDK to read temporary credentials from AWS Systems Manager (SSM) Parameter Store during the local initialization phase.

Answer

Initialize the AWS SDK client using config.LoadDefaultConfig without specifying any static credentials in the source code, and set the AWS_PROFILE environment variable to dev-profile in the local container's environment.
The correct options represent the standard AWS best practice for local development and containerized deployment. By loading the configuration via the SDK's default configuration loader without hardcoding any credentials, the application is set up to automatically look at the default credential provider chain. On a local development machine, setting the AWS_PROFILE environment variable to the desired local profile name instructs the SDK to fetch the credentials from the shared AWS config or credentials file (~/.aws/config or ~/.aws/credentials). When the same code is compiled and deployed to Amazon ECS, the AWS_PROFILE variable is not set, which allows the default chain to continue looking down the precedence list until it finds the ECS container credentials provider, thus utilizing the assigned ECS Task Role seamlessly and without any code modifications.

Step-by-Step Solution

1
Use the SDK's default configuration loading mechanism (such as config.LoadDefaultConfig in the Go SDK v2) during client initialization.
The application is configured to search the default AWS credential provider chain automatically.
This avoids hardcoding static credentials in the source code, making the application portable across environments.
2
Set the AWS_PROFILE environment variable to dev-profile in the local container environment.
The SDK client automatically reads the credentials associated with the specified profile from the shared AWS configuration/credentials files during local execution.
This allows the application to authenticate using the developer's local profile credentials without modifications to the code.
3
Deploy the application container to ECS on AWS Fargate without setting the AWS_PROFILE environment variable.
The SDK's default credential provider chain falls back to using ECS container credentials provided by the Task Role.
This ensures the application securely assumes the Task Role permissions when running on AWS.

Key Concept

The AWS SDK default credential provider chain automatically searches several sources in order, including environment variables, shared configuration files, and ECS container task roles, enabling seamless environment transitions when credentials are not hardcoded.
Estimated Time:2m 0s
Rate this question

Topics

AWS SDKs and Credential Management

More questions from this topic