Examkin

Question

Difficulty: Very hardTroubleshooting Local Development and AWS Credentials

A developer is containerizing a Python microservice that uses the AWS SDK (Boto3) to retrieve objects from an Amazon S3 bucket. During local development on a macOS host, the developer runs the application in a Docker container using Docker Desktop. The container fails to authenticate with AWS and throws a `NoCredentialsError`. The host machine's AWS CLI is configured with a default profile and a named profile `local-dev` that contains active credentials.

Which TWO actions should the developer perform to resolve this authentication failure and allow the containerized application to use the `local-dev` credentials? (Choose two.)

  1. Mount the host machine's ~/.aws directory to the home directory of the user running inside the container (e.g., /root/.aws) and set the AWS_PROFILE environment variable to local-dev in the container runtime environment.Answer
  2. Pass the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables from the host's active shell session directly into the container using container runtime environment flags.Answer
  3. C
    Hardcode the AWS Access Key ID and Secret Access Key from the local-dev profile directly into the initialization code of the S3 client using Boto3 parameters.
  4. D
    Modify the trust policy of the S3 bucket's IAM Role to explicitly trust the local Docker Desktop daemon IP address and allow access from external hosts.
  5. E
    Configure the S3 client to call AWS Secrets Manager inside the container to fetch the credentials dynamically without passing bootstrap keys.

Answer

Mount the host machine's credentials directory while setting the profile environment variable, or pass the active shell credential environment variables to the container at runtime.
The correct options provide valid, secure mechanisms to supply credentials to a local container without exposing secrets. Mounting the host's credential directory (~/.aws) into the container's user directory combined with the profile variable allows the SDK to resolve credentials from the configuration file. Alternatively, injecting active environment variables into the container environment allows the SDK's credential provider chain to resolve credentials from environment variables directly.

Step-by-Step Solution

1
Analyze the environment boundary.
The containerized application is isolated from the host's files and environment variables, resulting in the Boto3 SDK being unable to find any credentials in its default search path.
By default, Docker containers do not share the host's home directory or environment variables where AWS credentials are configured.
2
Evaluate configuration mounting options.
Mounting the host's ~/.aws folder to the container's user home directory makes the configuration and credentials files visible to Boto3.
Setting the AWS_PROFILE environment variable inside the container to 'local-dev' instructs Boto3 to read from the mounted named profile rather than falling back to the default profile.
3
Evaluate environment variables injection options.
Passing AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables into the container environment allows Boto3 to load credentials directly.
Environment variables are evaluated first in the AWS SDK default credentials provider chain, overriding other local file configuration paths.

Key Concept

AWS SDK Default Credentials Provider Chain in Container Environments
Rate this question

Topics

Troubleshooting Local Development and AWS Credentials

More questions from this topic