Examkin

All practice questions

1542 questions

All types1,542Multiple choice782Multiple select746Ordering14
Question 181Question →

A developer is configuring a local development workstation to run a Python script that uses the AWS SDK (Boto3) to upload files to Amazon S3. To adhere to security best practices, the developer must avoid hardcoding AWS credentials directly within the script. Which two methods should the developer use to securely provide the required credentials to the AWS SDK? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Define the credentials as system environment variables named AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.; Store the credentials under a profile in the shared AWS credentials file located at ~/.aws/credentials.

Answer

Setting the credentials as environment variables or storing them in the shared AWS credentials file are the recommended secure methods.
The correct options are using system environment variables and using the shared AWS credentials file. The AWS SDK default credential provider chain automatically searches for environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) first, and then looks in the shared credentials file (located at ~/.aws/credentials). Both methods allow the code to run securely without hardcoding sensitive access keys.

Step-by-Step Solution

1
Identify the standard mechanism by which the AWS SDK retrieves credentials without code modification.
The AWS SDK implements the Default Credential Provider Chain, which looks for credentials in environment variables and local shared credential files.
Understanding the SDK's credential search sequence is essential for secure local configuration.
2
Select options that conform to the default credential chain without exposing secrets in code.
Defining environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) and using the local shared credentials file (~/.aws/credentials) both satisfy this requirement.
These mechanisms keep sensitive keys outside the application files.

Key Concept

AWS SDK Default Credential Provider Chain for Local Development
Estimated Time:1m 0s
Question 182Question →

A developer is implementing an AWS Lambda function in AWS Account 111111111111111111111111 (Account A) that must write messages to an Amazon SQS queue in AWS Account 222222222222222222222222 (Account B). The security team requires using temporary security credentials via IAM role assumption for cross-account access. The Lambda function is configured with an execution role named `LambdaExecutionRole` in Account A.

The developer attempts to set up an IAM role in Account B named `QueueWriterRole` with the following trust policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which of the following actions are required to successfully and securely establish this cross-account access? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the trust policy of `QueueWriterRole` in Account B to replace `lambda.amazonaws.com` with `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"` in the `Principal` element.; Attach an identity-based policy to `LambdaExecutionRole` in Account A that allows the `sts:AssumeRole` action on the Amazon Resource Name (ARN) of `QueueWriterRole` in Account B.

Answer

To establish cross-account access securely, the trust policy of the IAM role in the destination account must be updated to trust the source role's ARN, and the execution role in the source account must have an identity-based policy allowing it to perform the assume role action on the destination role.
Cross-account delegation requires configuration on both sides. First, the destination role's trust policy in Account B must define who is trusted to assume it. This is done by modifying the principal element to target the specific execution role ARN of the Lambda function. Second, the execution role in Account A must be granted permission to perform the `sts:AssumeRole` action on the destination role's ARN.

Step-by-Step Solution

1
Inspect the initial trust policy on the role in the destination account (Account B) and identify the principal misconfiguration.
The current trust policy uses the service principal `lambda.amazonaws.com`. This configuration only allows the AWS Lambda service within the same account to assume the role directly, not a specific role from a different AWS account.
Correcting the trust relationship is necessary because cross-account trust requires specifying the specific AWS account or IAM principal in the trust policy.
2
Modify the trust policy of the target role in Account B to trust the specific IAM role in Account A.
The `Principal` element is changed to `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"`.
This establishes that the role in Account B trusts the execution role of the Lambda function in Account A.
3
Grant the execution role in Account A the permission to perform `sts:AssumeRole` on the target role in Account B.
An identity-based policy with the `sts:AssumeRole` action and the target role's ARN as the resource is attached to `LambdaExecutionRole` in Account A.
Even if the target role trusts the source role, the source role must explicitly be granted permission to perform the assume-role operation.

Key Concept

Cross-account IAM role delegation requires two-way permission configuration: a trust policy on the target role trusting the source principal, and an identity-based permission policy on the source principal allowing the assume-role action.
Question 183Question →

A developer is writing a local script using the AWS SDK to read messages from an Amazon SQS queue. The script needs to run locally on the developer's workstation for testing. According to the AWS SDK default credential provider chain, which of the following is the recommended and most secure way to supply the AWS credentials during local testing?

Show answer & explanation

Answer: Store the credentials in the local AWS credentials file by running the `aws configure` command.

Answer

Storing the credentials in the local AWS credentials file by running the `aws configure` command.
Storing credentials in the local credentials file (typically at `~/.aws/credentials`) using the `aws configure` command is the recommended method for local development. The AWS SDK default credential provider chain automatically looks for these credentials, avoiding the risk of exposing secrets in the application source code.

Step-by-Step Solution

1
Identify the execution environment of the application.
The application is running locally on the developer's workstation.
Different execution environments dictate different credential management best practices.
2
Evaluate the AWS SDK credential lookup hierarchy.
The default credential provider chain checks environment variables, then the local credentials file, and then instance/task metadata.
Understanding the lookup order ensures the SDK can find the credentials without hardcoding.
3
Choose the option that secures credentials without exposing them in code or configuration files that might be committed.
The local credentials file configured via the AWS CLI is the standard and secure choice for local workstations.
This keeps credentials local to the developer's machine and prevents accidental commits of secrets to code repositories.

Key Concept

AWS SDK Default Credential Provider Chain and local credential configuration.
Estimated Time:1m 0s
Question 184Question →

An application deployed on an Amazon EC2 instance uses the AWS SDK to retrieve secrets from AWS Secrets Manager. The EC2 instance has an IAM instance profile attached with the required permissions. However, when the application runs, it fails to authenticate and throws an AccessDenied exception, attempting to use credentials belonging to a different IAM user. Which of the following is the most likely cause of this credential conflict based on the AWS SDK default credential provider chain order of precedence?

Show answer & explanation

Answer: Active environment variables for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are present on the EC2 instance, overriding the EC2 instance profile credentials.

Answer

Active environment variables for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are present on the EC2 instance, overriding the EC2 instance profile credentials.
The default credential provider chain evaluates environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before checking the EC2 Instance Metadata Service (IMDS). If environment variables from another user are active on the instance, the SDK will use those credentials, ignoring the instance profile.

Step-by-Step Solution

1
Review the AWS SDK default credential provider chain order of precedence.
The chain resolves credentials in the following order: 1. Environment variables, 2. Shared credentials file, 3. Web Identity Token, 4. ECS container credentials, 5. EC2 Instance Metadata Service (IMDS).
This helps identify which source takes priority when multiple credential sources are configured.
2
Compare the precedence of the attached IAM instance profile against other possible sources.
The instance profile credentials are retrieved via IMDS (step 5). Environment variables (step 1) have higher precedence.
Since the SDK is attempting to use credentials of a specific IAM user instead of the instance profile, a higher-precedence source must be supplying those credentials.
3
Identify the configuration that matches the observed failure.
The presence of AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables overrides the instance profile.
Environment variables are evaluated first, meaning any values set there will be preferred over the instance profile credentials.

Key Concept

AWS SDK Default Credential Provider Chain Resolution Order
Question 185Question →

A developer is deploying a containerized application to AWS and wants to use the AWS SDK to interact with Amazon S3. To ensure security and flexibility across environments, the developer decides to use the Default Credential Provider Chain to locate AWS credentials.

Which two of the following locations or sources are checked by the Default Credential Provider Chain to obtain these credentials?

Select all that apply

Show answer & explanation

Answer: Environment variables such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY; IAM role credentials retrieved from the Amazon EC2 instance metadata service (IMDS)

Answer

The correct options are the environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) and the IAM role credentials retrieved from the Amazon EC2 instance metadata service (IMDS).
The default credential provider chain automatically searches several locations in a specific order to resolve credentials. Among these, it checks environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) first, and if no credentials are found in earlier locations, it queries the instance metadata service (IMDS) for credentials associated with an IAM role.

Step-by-Step Solution

1
Analyze the request for AWS SDK credential resolution.
The developer is using the Default Credential Provider Chain to automatically locate credentials.
Understanding the default credential lookup order is essential to determine where the SDK looks automatically.
2
Evaluate the standard search order of the Default Credential Provider Chain.
The search order starts with environment variables, then checks system properties, then the local credentials file, then container credentials (if applicable), and finally instance metadata (IMDS).
This identifies environment variables and instance metadata as valid sources within the default chain.
3
Identify correct and incorrect choices based on standard SDK behavior.
Environment variables and IMDS are part of the default chain, while hardcoding, S3 storage, and Systems Manager Parameter Store require explicit configuration or custom code and are not part of the default chain.
This isolates the correct options and rejects the incorrect distractors.

Key Concept

AWS SDK Default Credential Provider Chain Search Order
Question 186Question →

A developer is building a mobile application that allows users to upload high-resolution photos directly to a private Amazon S3 bucket. The application must authenticate users using an enterprise OpenID Connect (OIDC) identity provider. The developer wants to use Amazon Cognito to facilitate authorization, ensuring that users can only upload files to their own prefix (folder) within the S3 bucket using temporary, least-privilege credentials, without exposing any long-lived credentials. Which TWO configuration steps should the developer perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool and add the OIDC identity provider as an authentication provider in the Identity Pool settings.; Create an IAM role for authenticated users with a trust policy for cognito-identity.amazonaws.com and a permissions policy that utilizes the cognito-identity.amazonaws.com:sub policy variable to grant s3:PutObject access to user-specific prefixes.

Answer

To meet the requirements, the developer must configure an Amazon Cognito Identity Pool with the OIDC provider as an authentication provider, and associate an authenticated IAM role that utilizes the cognito-identity.amazonaws.com:sub policy variable to restrict S3 bucket upload access to the user's specific prefix.
To upload files directly to Amazon S3, a client requires temporary AWS credentials. Amazon Cognito Identity Pools (federated identities) enable this by allowing users to federate with external identity providers (such as an OIDC provider) and obtain temporary AWS credentials. Access to S3 can be scoped to user-specific folders by using the authenticated IAM role associated with the Identity Pool. By incorporating the cognito-identity.amazonaws.com:sub policy variable into the resource block of the IAM role's permission policy, the policy dynamically evaluates to the authenticated user's unique identity ID, thereby enforcing that users can only upload objects to their own folder prefix.

Step-by-Step Solution

1
Set up federation between the OIDC provider and AWS.
Configure an Amazon Cognito Identity Pool and register the OIDC provider within its settings.
This allows users authenticated via the enterprise OIDC provider to exchange their OIDC token for temporary AWS credentials using Cognito.
2
Define authorization permissions using an IAM role.
Create an authenticated IAM role with a trust relationship pointing to cognito-identity.amazonaws.com.
Cognito Identity Pools require an IAM role that defines the permissions granted to authenticated users. The trust policy permits Cognito to assume this role on behalf of the federated user.
3
Implement prefix-level isolation in the IAM permissions policy.
Reference the cognito-identity.amazonaws.com:sub policy variable in the S3 bucket resource ARN (e.g., arn:aws:s3:::my-bucket/${cognito-identity.amazonaws.com:sub}/*).
This dynamically limits each user's S3 put operations to their unique Cognito identity ID, ensuring proper isolation and data security.

Key Concept

Federation using Cognito Identity Pools and access control using Cognito policy variables
Question 187Question →

A developer is deploying a Go application to run in an Amazon ECS task using the AWS Fargate launch type. The application uses the AWS SDK to retrieve configuration data from Amazon Systems Manager Parameter Store. The developer wants to ensure that the application can authenticate with AWS services securely during local development and in the production ECS environment without code modifications. Which two actions should the developer take to configure the credential retrieval process correctly? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Initialize the AWS SDK client using the default credential provider chain configuration without passing any static credentials.; Associate an IAM role containing the required permissions with the ECS task definition using the taskRoleArn parameter.

Answer

Initialize the AWS SDK client using the default credential provider chain configuration without passing any static credentials, and associate an IAM role containing the required permissions with the ECS task definition using the taskRoleArn parameter.
To authenticate securely without code changes across environments, the developer should initialize the AWS SDK client using the default credential provider chain. The chain automatically searches for credentials in the environment, local configuration files (during local development), and container credentials (ECS Task Roles) when deployed on AWS. The IAM role containing the permissions must be associated with the ECS task definition using the taskRoleArn parameter, allowing the application within the container to retrieve temporary security credentials.

Step-by-Step Solution

1
Configure the AWS SDK client to use the default credential provider chain.
The SDK automatically checks multiple locations for credentials in a specific order: environment variables, shared credentials file, and then the ECS task role credentials.
This allows the same codebase to run locally (using local profiles) and in production (using task roles) without changes.
2
Assign the S3/Parameter Store IAM role to the Task Role parameter (taskRoleArn) in the ECS task definition.
The containerized application is granted permission to call AWS services, and the AWS SDK inside the container can automatically fetch temporary credentials from the ECS container agent.
Permissions required by the application code must be defined in the Task Role, not the Task Execution Role (which is for the ECS agent itself).

Key Concept

AWS SDK Default Credential Provider Chain and ECS Task Roles
Estimated Time:1m 30s
Question 188Question →

A developer is writing an AWS Lambda function that needs to write data to an Amazon DynamoDB table using the AWS SDK. How should the developer configure the AWS SDK client in the function code to authenticate securely with the database?

Show answer & explanation

Answer: Initialize the SDK client with default settings, allowing the default credential provider chain to automatically retrieve temporary credentials from the Lambda execution role.

Answer

Initialize the SDK client with default settings, allowing the default credential provider chain to automatically retrieve temporary credentials from the Lambda execution role.
The correct option is correct because when running code inside AWS Lambda, the service automatically injects temporary credentials from the function's execution role into the environment. The AWS SDK, when initialized without custom configuration, uses the default credential provider chain to automatically find and use these environment variables.

Step-by-Step Solution

1
Identify the environment context in which the AWS SDK is running.
The SDK is running within an AWS Lambda function execution environment.
Understanding where the SDK runs determines how the credential provider chain resolves security credentials.
2
Determine how AWS Lambda manages permissions and credentials for execution.
Lambda uses an IAM execution role and automatically injects temporary credentials into the environment variables.
These environment variables are standard inputs for the AWS SDK credential resolution.
3
Evaluate the initialization method of the AWS SDK client.
Initializing the client with default parameters automatically triggers the default credential provider chain, which checks environment variables first.
This is the most secure and simplest approach, as it uses short-term credentials and requires zero manual configuration or hardcoding.

Key Concept

AWS SDK default credential provider chain and Lambda execution roles
Estimated Time:45s
Question 189Question →

A developer is writing a Node.js application on a local development workstation that uses the AWS SDK for JavaScript (v3) to access resources in a development AWS account. To comply with security best practices, the developer must run the application locally by assuming a specific IAM role (arn:aws:iam::123456789012:role/DevDeveloperRolearn:aws:iam::123456789012:role/DevDeveloperRole) using the temporary credentials of a local IAM user profile named `dev-user`.

Which combination of configuration steps will allow the AWS SDK to automatically assume the target IAM role and retrieve temporary credentials without modifying the application code? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Define a profile in the local `~/.aws/config` file that specifies the target role's ARN in the `role_arn` parameter and references `dev-user` in the `source_profile` parameter.; Set the `AWS_PROFILE` environment variable in the local development environment to the name of the newly defined profile before running the application.

Answer

To configure automatic role assumption without code changes, the developer must define a profile in the local configuration file (`~/.aws/config`) that references the target role ARN and the source profile, and then set the `AWS_PROFILE` environment variable to use this profile.
To assume an IAM role automatically via the AWS SDK without code changes, the developer must utilize profile-based configurations. Specifying the `role_arn` and `source_profile` within the configuration file (`~/.aws/config`) defines how the role is assumed. Setting the `AWS_PROFILE` environment variable directs the SDK to use this profile. When the application initializes the SDK client, the Default Credential Provider Chain reads this environment variable, references the configuration file, and automatically obtains temporary credentials from AWS STS using the source user's credentials.

Step-by-Step Solution

1
Configure the profile in the `~/.aws/config` file.
A profile is created that specifies the target role ARN and links it to the local IAM user profile using the `source_profile` parameter.
This tells the AWS SDK which IAM role to assume and which credentials to use to call the AWS STS `AssumeRole` API.
2
Set the `AWS_PROFILE` environment variable to the name of the newly configured profile.
The local execution environment is configured to point the AWS SDK to the role-assuming profile.
This instructs the Default Credential Provider Chain of the AWS SDK to resolve credentials using the configured role-assumption profile rather than default credentials.

Key Concept

AWS SDK Default Credential Provider Chain and Profile-Based IAM Role Assumption
Question 190Question →

A developer is running a containerized Java application inside an Amazon Elastic Container Service (Amazon ECS) task on an Amazon EC2 host. The ECS task is assigned an IAM Task Role (`ECS-Task-Role`) that has permission to write to an Amazon DynamoDB table. The hosting EC2 instance profile has an IAM role (`EC2-Host-Role`) that does not have DynamoDB permissions.

During execution, the application fails to write to DynamoDB and logs an `AccessDeniedException`. Further inspection of the log output shows that the AWS SDK is resolving credentials associated with `EC2-Host-Role` rather than `ECS-Task-Role`.

Which of the following is the most likely root cause of this credential resolution behavior?

Show answer & explanation

Answer: The environment variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` was not injected into the container, causing the AWS SDK to bypass the ECS task credentials step in the provider chain and fall back to the host instance profile credentials.

Answer

The correct answer states that the environment variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` was not injected into the container, causing the AWS SDK to bypass the ECS task credentials step in the provider chain and fall back to the host instance profile credentials.
The correct answer is correct because the AWS SDK's Default Credential Provider Chain relies on the environment variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` to discover and fetch temporary credentials for the ECS Task Role from the ECS agent. If this environment variable is missing, the SDK assumes it is not running in an ECS task context that supports container credentials and proceeds down the chain, eventually resolving the host EC2 instance's credentials via the Instance Metadata Service (IMDS). Since the host EC2 instance profile has `EC2-Host-Role` attached, which lacks DynamoDB permissions, the application receives an `AccessDeniedException` when trying to write to DynamoDB.

Step-by-Step Solution

1
Identify the credential provider chain precedence for AWS SDK applications running inside an ECS environment.
The AWS SDK checks for ECS container credentials (using the presence of `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` or `AWS_CONTAINER_CREDENTIALS_FULL_URI`) before it checks the EC2 Instance Metadata Service (IMDS).
This ensures containerized tasks use their own specific roles rather than the host's IAM role.
2
Analyze why the SDK bypassed the ECS task credentials and resolved the host instance's credentials.
Since the SDK resolved the `EC2-Host-Role` (retrieved via IMDS), the ECS container credentials step must have been bypassed because the required environment variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` was missing or not populated.
Without this environment variable, the SDK assumes it is not running in an ECS task context that supports container credentials and falls back to IMDS.
3
Differentiate between task role configuration errors and SDK fallbacks.
Misconfiguring IAM trust policies or task execution roles would not prevent the container agent from injecting the environment variable. Only the absence of the environment variable triggers the SDK to fall back directly to IMDS.
To resolve this, the network configuration or the ECS agent configuration on the host must be corrected to ensure the environment variables are successfully injected.

Key Concept

AWS SDK Default Credential Provider Chain Precedence in Containerized Environments
Estimated Time:2m 0s
Question 191Question →

A developer is configuring a local workstation to run a script that uses the AWS SDK to retrieve files from Amazon S3. To adhere to security best practices and avoid hardcoding credentials within the application, which two locations can the developer use to store the credentials so they are automatically detected by the default credential provider chain? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY); The shared credentials file (typically located at ~/.aws/credentials on Linux/macOS)

Answer

The developer should store the credentials in environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) or in the shared credentials file (~/.aws/credentials).
The correct options are environment variables and the shared credentials file because both are standard, secure ways to supply credentials that the AWS SDK's default credential provider chain automatically evaluates during initialization.

Step-by-Step Solution

1
Analyze how the AWS SDK's default credential provider chain searches for credentials on a local system.
The chain looks at environment variables first, then at system properties (for Java), and then at the shared credentials file (~/.aws/credentials).
Understanding the order of precedence in the credential chain helps identify where credentials can be placed for automatic detection.
2
Evaluate the option of using environment variables.
Defining AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY enables the SDK to load credentials automatically.
Environment variables are the first place the default chain looks, making it a valid and common local configuration method.
3
Evaluate the option of using the shared credentials file.
Storing credentials under the default profile in ~/.aws/credentials allows the SDK to load them without code modification.
The shared credentials file is specifically designed for local development credentials and is checked by the default chain.

Key Concept

The default credential provider chain automatically searches standard locations (like environment variables and the shared credentials file) in a specific order to obtain AWS credentials, eliminating the need to hardcode sensitive keys.
Estimated Time:1m 0s
Question 192Question →

A developer is deploying a Go-based daemon to an on-premises server. The daemon must interact with Amazon DynamoDB and AWS Secrets Manager. To comply with strict security policies, no long-term AWS credentials can be stored on the server's local disk. The enterprise has an existing internal authentication service running at `http://internal-auth.local` that generates temporary AWS credentials upon successful authentication. Which two actions should the developer take to configure the AWS SDK in the Go application to automatically retrieve and use these credentials?

Select all that apply

Show answer & explanation

Answer: Configure a profile in the shared AWS config file on the server, specifying the credential_process parameter pointing to a script that queries the internal service and outputs the credentials in the required JSON format.; Set the AWS_PROFILE environment variable on the server to the name of the profile containing the credential_process configuration.

Answer

Configure a profile in the shared AWS config file on the server, specifying the credential_process parameter pointing to a script that queries the internal service and outputs the credentials in the required JSON format, and set the AWS_PROFILE environment variable on the server to the name of the profile containing the credential_process configuration.
The correct combination of steps involves configuring the credential_process parameter in the shared AWS config file and setting the AWS_PROFILE environment variable. The credential_process config option allows the AWS SDK to execute an external tool or script, retrieve temporary AWS credentials in a standard JSON format, and automatically handle credential caching and expiration. Setting the AWS_PROFILE environment variable points the SDK to the custom profile that specifies the external process configuration.

Step-by-Step Solution

1
Identify the constraints and requirements for the on-premises credentials flow.
Static keys cannot be saved to the local disk, meaning temporary credentials must be retrieved dynamically from the internal service.
Security compliance forbids long-term keys on local storage.
2
Implement the credential_process configuration.
A profile is defined in the shared AWS config file (~/.aws/config) specifying the credential_process configuration pointing to a wrapper script that performs authentication against the internal API and prints the standard credential JSON.
The AWS SDK automatically executes this process to retrieve, parse, and refresh temporary access credentials.
3
Configure the environment variables to activate the custom profile.
The AWS_PROFILE environment variable is set to the name of the newly configured profile.
This directs the AWS SDK default credential provider chain to prioritize that specific profile configuration.

Key Concept

AWS SDK Credential Resolution via External Process
Question 193Question →

A developer is packaging a Node.js application to run in an Amazon ECS container on AWS Fargate. During local testing on developer workstations, the application accesses AWS resources using credentials retrieved from the AWS IAM Identity Center (via the AWS CLI `aws sso login` command). In the production Fargate environment, the application must access an Amazon DynamoDB table. The developer wants the application to automatically resolve the correct credentials in both environments using the AWS SDK's default credential provider chain without any code changes or hardcoded credentials.

Which two configuration actions must the developer take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Assign the IAM role that has DynamoDB read/write permissions to the ECS Task Role (taskRoleArn) in the ECS task definition.; Set the AWS_PROFILE environment variable on local developer workstations to match the name of the IAM Identity Center profile configured in the shared AWS config file.

Answer

Assigning the IAM role with DynamoDB access to the Task Role (taskRoleArn) in the task definition, and setting the AWS_PROFILE environment variable on local developer workstations to match the name of the IAM Identity Center profile in the shared AWS configuration file.
The correct configurations involve using the ECS Task Role (taskRoleArn) to delegate application permissions in Fargate, and setting the AWS_PROFILE environment variable locally to direct the SDK's default credential provider chain to the correct SSO profile in the shared AWS configuration file. This allows the application code to remain environment-agnostic, resolving credentials automatically using the default provider chain.

Step-by-Step Solution

1
Identify the credential source for the application running in the production ECS Fargate environment.
The application should use the ECS Task Role, which exposes temporary credentials to the container environment.
The SDK's default credential provider chain automatically queries container credentials when running inside an ECS task, provided a Task Role is defined via taskRoleArn.
2
Identify the local credential source generated by AWS IAM Identity Center.
The AWS CLI stores IAM Identity Center login credentials in a local profile within the shared AWS config file.
Setting the AWS_PROFILE environment variable instructs the default credential provider chain to use the specified profile configuration instead of default environment keys.
3
Exclude incorrect role assignments and trust policies.
The Task Execution Role cannot be used for application-level DynamoDB access, and the trust policy must trust ecs-tasks.amazonaws.com rather than ec2.amazonaws.com.
Task Execution Roles only support container-agent operations, and Fargate tasks run on managed container hosts, requiring the ECS-specific trust relationship.

Key Concept

AWS SDK Default Credential Provider Chain and Container Credential Resolution
Question 194Question →

A developer is writing a Node.js application that will run on an Amazon EC2 instance. The application needs to retrieve objects from an Amazon S3 bucket using the AWS SDK. To follow security best practices, the developer wants to avoid managing long-term AWS credentials on the instance.

Which configuration should the developer use to allow the AWS SDK to access the S3 bucket securely?

Show answer & explanation

Answer: Attach an IAM role with S3 read permissions to the EC2 instance, and initialize the AWS SDK client without passing any credentials.

Answer

Attach an IAM role with S3 read permissions to the EC2 instance, and initialize the AWS SDK client without passing any credentials.
Attaching an IAM role to the EC2 instance allows the AWS SDK to retrieve temporary security credentials from the EC2 Instance Metadata Service (IMDS). Because the default credential provider chain automatically queries IMDS when no other credentials are found, initializing the client without arguments is the most secure and native approach.

Step-by-Step Solution

1
Attach the IAM role to the EC2 instance.
The EC2 instance is associated with an instance profile containing the IAM role.
This allows the EC2 Instance Metadata Service (IMDS) to distribute temporary credentials to applications running on the instance.
2
Initialize the AWS SDK S3 client without passing credentials.
The SDK client is created using the default constructor.
When no credentials are explicitly provided, the default credential provider chain automatically searches for credentials, eventually falling back to the EC2 instance metadata.

Key Concept

AWS SDK Default Credential Provider Chain and IAM Roles for EC2
Estimated Time:1m 0s
Question 195Question →

An application deployed on an Amazon EC2 instance uses the AWS SDK to perform read and write operations on an Amazon DynamoDB table. An IAM instance profile named `DynamoDB-Write-Role` is attached to the EC2 instance. However, the developer has also configured a shared credentials file under `/home/ec2-user/.aws/credentials` that contains a default profile with static credentials that only allow read-only access to DynamoDB. The environment variable `AWS_PROFILE` is not set. During application execution, all write operations to DynamoDB fail with an `AccessDeniedException`. Which of the following describes the root cause of this failure and the correct resolution?

Show answer & explanation

Answer: The SDK resolves credentials from the shared credentials file first because it precedes the EC2 instance profile in the default credential provider chain. The developer must remove the static credentials from the shared credentials file to allow the chain to fall back to the instance profile.

Answer

The SDK resolves credentials from the shared credentials file first because it precedes the EC2 instance profile in the default credential provider chain. The developer must remove the static credentials from the shared credentials file to allow the chain to fall back to the instance profile.
The default credential provider chain evaluates the shared credentials file (`~/.aws/credentials`) before checking for EC2 instance profile credentials. Because a default profile exists in the shared credentials file, the chain successfully resolves credentials from that source and stops its search. It does not fall back to subsequent credentials in the chain when an authorization failure (such as `AccessDeniedException`) occurs. Removing the static credentials from the shared credentials file allows the provider chain to reach the EC2 instance profile evaluation step.

Step-by-Step Solution

1
Analyze the location of the credentials configured in the environment.
The environment has an IAM instance profile attached and a default profile in the shared credentials file at `/home/ec2-user/.aws/credentials`.
To determine which credential sources are available to the application.
2
Evaluate the order of precedence in the AWS SDK default credential provider chain.
The shared credentials file is checked and resolved before the EC2 instance profile (IMDS).
To identify which credential source the SDK will select to sign the requests.
3
Determine the behavior of the SDK when the resolved credentials lack required permissions.
The SDK attempts the API call using the resolved read-only credentials, which fails with an `AccessDeniedException`. The SDK does not fall back to the next provider in the chain.
To explain why the write operation failed despite the instance profile having the correct permissions.
4
Identify the resolution to allow the application to use the instance profile.
Remove the static credentials from the shared credentials file, allowing the default chain to fall back to the EC2 instance profile.
To enable the SDK to successfully resolve the credentials from the EC2 instance profile.

Key Concept

AWS SDK Default Credential Provider Chain Order of Precedence
Estimated Time:3m 0s
Question 196Question →

A developer has configured a Lambda proxy integration in Amazon API Gateway. When testing the API, they receive a 502 (Bad Gateway) error. The Lambda function execution logs in Amazon CloudWatch show that the function ran successfully and returned the intended result. Which of the following is the most likely cause of this error?

Show answer & explanation

Answer: The Lambda function is returning a raw string or a custom JSON object instead of a JSON response containing the required "statusCode" and "body" keys.

Answer

The Lambda function is returning a raw string or a custom JSON object instead of a JSON response containing the required "statusCode" and "body" keys.
In a Lambda proxy integration, API Gateway expects the backend Lambda function to return a response structured as a specific JSON object. This object must contain the 'statusCode' (as an integer or string) and the 'body' (as a stringified JSON payload). Since the Lambda function executed successfully but API Gateway returned a 502 Bad Gateway error, the most likely cause is that the function did not format its response payload to include these required keys, causing API Gateway to fail parsing the response.

Step-by-Step Solution

1
Analyze the error code (502 Bad Gateway) and CloudWatch execution logs.
The Lambda function executed successfully without error, but API Gateway returned a 502 error to the client.
This indicates that the communication between API Gateway and Lambda succeeded, but API Gateway failed to parse the output format returned by the Lambda function.
2
Verify the integration type configured in API Gateway.
The integration is configured as a Lambda proxy integration.
Lambda proxy integration imposes strict requirements on the structure of the JSON returned by the backend Lambda function.
3
Verify the response structure of the Lambda function.
The function must return a JSON response containing 'statusCode' and 'body'.
API Gateway requires these fields to construct the HTTP response. A mismatch or missing fields will result in a 502 Bad Gateway error.

Key Concept

Understanding the response format requirements for API Gateway Lambda Proxy integrations.
Estimated Time:1m 0s
Question 197Question →

A developer is deploying a containerized Python application to Amazon ECS on AWS Fargate. The application needs to access an Amazon S3 bucket. During local development, the developer configured the AWS SDK (Boto3) by setting the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables in the local shell. In the ECS task definition, the developer assigned an IAM role with the correct permissions to the `taskRoleArn` parameter. However, when the container runs in Fargate, the application receives authorization errors because it tries to use the developer's local credentials, which have expired.

Which of the following actions should the developer take to resolve this issue and ensure the application securely accesses Amazon S3? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Remove the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables from the task definition's container environment configuration.; Configure the IAM role's trust policy to allow the `ecs-tasks.amazonaws.com` service principal to perform the `sts:AssumeRole` action.

Answer

To resolve the credential resolution issue, the developer must remove the static environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) from the task definition's container environment configuration, and configure the IAM role's trust policy to allow the ecs-tasks.amazonaws.com service principal to assume the role.
Removing the environment variables from the task definition is correct because the AWS SDK Default Credential Provider Chain checks environment variables first. Removing them allows the chain to evaluate downstream providers, specifically the container credentials provider. Configuring the trust policy for ecs-tasks.amazonaws.com is correct because it authorizes the ECS service to assume the Task Role and provide temporary credentials to the application.

Step-by-Step Solution

1
Analyze the credential lookup hierarchy of the AWS SDK.
The AWS SDK credential provider chain checks environment variables before container credentials. The presence of expired environment variables prevents the SDK from falling back to the task role credentials.
To resolve the order of precedence issue, the incorrect environment variables must be removed.
2
Configure trust relationship for ECS IAM roles.
The IAM role assigned to the task must trust the ECS tasks service principal.
This permits AWS ECS to call STS AssumeRole to assume the IAM role and supply credentials to the container.

Key Concept

Understanding the AWS SDK Default Credential Provider Chain precedence and ECS Task Role requirements.
Question 198Question →

A developer is deploying a Go-based microservice to AWS Lambda. The microservice uses the AWS SDK for Go to retrieve items from an Amazon DynamoDB table.

Which of the following is the most secure and standard way to configure the AWS SDK client to authenticate requests?

Show answer & explanation

Answer: Initialize the SDK client using the default configuration settings so it automatically inherits permissions from the Lambda function's execution role.

Answer

Initialize the SDK client using the default configuration settings so it automatically inherits permissions from the Lambda function's execution role.
The correct option is to initialize the SDK client using default configuration settings. When running inside AWS Lambda, the AWS SDK automatically utilizes the Default Credential Provider Chain to retrieve the temporary credentials associated with the function's execution role from the environment. This is the most secure approach because it avoids hardcoding secrets and relies on temporary, automatically rotated credentials.

Step-by-Step Solution

1
Examine the deployment environment of the application, which is AWS Lambda.
Identify that AWS Lambda automatically provides temporary security credentials to the execution environment via environment variables.
Understanding the execution environment helps determine if temporary credentials are automatically available.
2
Analyze how the AWS SDK retrieves credentials when initialized with default settings.
The AWS SDK's Default Credential Provider Chain automatically checks for credentials in environment variables, which is where Lambda places the execution role's temporary credentials.
This allows the developer to write code that does not reference any specific credentials directly.
3
Select the option that initializes the client using default configurations without hardcoding or manually fetching long-lived secrets.
Initializing the client with default configuration is the most secure and standard approach.
This aligns with AWS security best practices by utilizing short-lived IAM credentials automatically managed by AWS.

Key Concept

AWS SDK Default Credential Provider Chain and Lambda Execution Roles
Question 199Question →

A developer is configuring a REST API in Amazon API Gateway that integrates with a backend AWS Lambda function. The developer needs the Lambda function to directly control the HTTP status code and headers returned to the API client. Which two configurations must be implemented to achieve this?

Select all that apply

Show answer & explanation

Answer: Enable Lambda Proxy Integration on the API Gateway method integration.; Ensure the Lambda function returns a JSON response containing the keys 'statusCode', 'headers', and 'body'.

Answer

To allow the Lambda function to control the HTTP status code and response headers, the developer must enable Lambda Proxy Integration on the API Gateway method integration, and the Lambda function must return a JSON response object containing the keys 'statusCode', 'headers', and 'body'.
To allow the Lambda function to control the response status codes and headers, the API Gateway integration must be configured for Lambda Proxy Integration. In this mode, API Gateway forwards the backend response directly to the client. The backend Lambda function must return the response in a standardized JSON payload format containing 'statusCode', 'headers', and 'body' so that API Gateway can correctly build the HTTP response.

Step-by-Step Solution

1
Determine the integration type that delegates response control to the backend.
Lambda Proxy Integration is chosen.
Unlike Custom integration, Lambda Proxy Integration hands over control of the HTTP status codes, headers, and body formatting directly to the backend Lambda function.
2
Determine the output structure required from the Lambda function.
The Lambda function returns a JSON object with 'statusCode', 'headers', and 'body' properties.
API Gateway requires this specific JSON schema in Lambda Proxy mode so that it can parse the output and construct the final HTTP response for the API client.

Key Concept

API Gateway Lambda Proxy Integration response mapping and JSON output schema requirements
Question 200Question →

A developer is designing a serverless ordering system where an AWS Lambda function processes message batches from an Amazon SQS queue. The function is configured with a timeout of 2 minutes and is placed inside private subnets of a custom VPC to write data to an Amazon Aurora DB cluster. The function also needs to call a public endpoint of an external payment gateway. During initial testing under load, the developer observes that the Lambda function fails to reach the external payment gateway, resulting in connection timeouts. Furthermore, the Aurora database cluster runs out of available database connections very quickly, and SQS messages are being received and processed multiple times by different Lambda invocations, even though the executions complete successfully in 90 seconds. Which combination of steps should the developer take to resolve these issues?

Show answer & explanation

Answer: Initialize the database connection pool outside the Lambda handler function. Deploy a NAT Gateway in a public subnet, and configure the route table of the Lambda private subnets to route outbound traffic through the NAT Gateway. Increase the SQS visibility timeout to at least 12 minutes.

Answer

Initialize the database connection pool outside the Lambda handler function, route outbound private subnet traffic through a NAT Gateway in a public subnet, and increase the SQS visibility timeout to at least 12 minutes.
The correct solution addresses all three problems by: 1) Utilizing global scope variables to reuse the database connection pool across invocations, which mitigates connection exhaustion. 2) Routing Lambda outbound traffic through a NAT Gateway in a public subnet to allow communication with the external payment gateway. 3) Aligning the SQS visibility timeout to at least 6 times the Lambda function's timeout (12 minutes12\text{ minutes} for a 2-minute2\text{-minute} timeout) to prevent duplicate delivery of active messages.

Step-by-Step Solution

1
Solve the internet connectivity issue for the VPC Lambda function.
Place the Lambda function in private subnets, deploy a NAT Gateway in a public subnet, and add a route in the private subnet's route table pointing 0.0.0.0/00.0.0.0/0 traffic to the NAT Gateway.
Lambda functions in a VPC do not receive public IP addresses. To access the public internet, they must route traffic through a NAT Gateway located in a public subnet that has a route to an Internet Gateway.
2
Resolve the Aurora database connection exhaustion issue.
Move the database connection pool initialization code out of the handler method and into the global initialization scope.
This allows the Lambda execution context to reuse the connection pool across warm invocations rather than establishing a new connection on every single invocation.
3
Resolve the duplicate SQS message processing issue.
Increase the SQS visibility timeout to at least 12 minutes, which is 6 times the Lambda function's timeout.
AWS recommends setting the SQS visibility timeout to at least 6 times the Lambda function timeout (6×2 minutes=12 minutes6 \times 2\text{ minutes} = 12\text{ minutes}). This ensures that the message remains invisible to other consumers until the Lambda function finishes processing or times out.

Key Concept

AWS Lambda VPC networking, execution context reuse, and SQS integration timeout alignment.
Estimated Time:3m 0s
PreviousPage 10 / 78Next
All practice questions — AWS Certified Developer - Associate | Examkin