Tüm alıştırma soruları

782 soru

Tüm türler1,542 Çoktan seçmeli782 Çoklu seçim746 Sıralama14

A healthcare startup collects continuous heart rate data from thousands of wearable medical patches. The patches stream telemetry data to an Amazon Kinesis Data Stream that has $12$ shards. The stream is experiencing periodic `ProvisionedThroughputExceededException` errors during peak hours, and analysis reveals that a single shard is receiving over $80\%$ of the traffic because the developer chose `device_manufacturer` as the partition key. Which of the following changes to the partition key should the developer implement to resolve the throttling and distribute the load evenly across all shards?

Change the partition key to a high-entropy value such as a combination of device_id and the telemetry timestamp.

Change the partition key to a static string value like heart_rate_telemetry to group all incoming records.

Replace the Kinesis stream with an Amazon SQS queue and reduce the message visibility timeout below the average message processing time.

Move the processing Lambda function to a private VPC subnet without configuring a NAT Gateway or VPC endpoint.

Cevabı ve açıklamayı göster

Cevap: Change the partition key to a high-entropy value such as a combination of device_id and the telemetry timestamp.

Cevap

Change the partition key to a high-entropy value such as a combination of device_id and the telemetry timestamp.

The correct answer resolves partition hotness by switching to a key with high entropy. By combining the unique device identifier with the event timestamp, the developer ensures a uniform distribution of hashed keys across the

12

shards, mitigating ProvisionedThroughputExceededException errors.

Adım Adım Çözüm

Analyze the distribution of records across the Kinesis shards.

Identify that the current key (device_manufacturer) has low entropy, resulting in a hot shard receiving

80\%

of the data stream traffic.

Uneven write distribution is the primary cause of ProvisionedThroughputExceededException errors when overall capacity is sufficient but partition key cardinality is low.

Select a partition key strategy with high cardinality.

Choose a key combining device_id and the telemetry timestamp, which provides high entropy.

A high-entropy partition key ensures that the MD5 hashing algorithm evenly hashes payloads across the

12

available shards, maximizing write throughput.

Anahtar Kavram

Selecting high-entropy partition keys to prevent hot shards in Kinesis Data Streams.

Alternatif Yöntem

Using an explicit hash key (ExplicitHashKey) in the PutRecord/PutRecords API calls to directly assign records to specific shards.

Tahmini Süre:1m 30s

Soru 2Soru →

A developer is deploying a Java application to an Amazon ECS cluster running on AWS Fargate. The application uses the AWS SDK for Java to write logs to an Amazon CloudWatch Logs group. The ECS task is configured with an IAM task role that has the necessary permissions to write to CloudWatch. However, the container definition also contains the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, which contain temporary credentials used during a previous CI/CD test run. When the application runs, it fails to write logs and throws an ExpiredTokenException. Which action should the developer take to resolve this issue?

Modify the application code to initialize the CloudWatch Logs client using a StaticCredentialsProvider with access keys passed as constructor arguments.

Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition.

Update the ECS task role's trust policy to include a Statement block that grants the logs:PutLogEvents action to the task execution role.

Store a new set of active access keys in AWS Systems Manager Parameter Store as a SecureString, and update the application code to retrieve them using the Parameter Store API on startup.

Cevabı ve açıklamayı göster

Cevap: Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition.

Cevap

Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition.

The correct answer is to remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition. In the AWS SDK default credential provider chain, environment variables have higher precedence than ECS container credentials. If these environment variables are set (even with expired credentials), the SDK will attempt to use them, resulting in an ExpiredTokenException. Removing them allows the SDK chain to fall back to the ECS container credentials provider, which retrieves the credentials associated with the ECS task role.

Adım Adım Çözüm

Analyze the AWS SDK default credential provider chain precedence.

The SDK checks environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before it checks the container credentials provider.

Understanding the order of precedence in the SDK is necessary to identify why the expired credentials in the environment variables are being selected over the valid task role.

Identify the root cause of the ExpiredTokenException.

The environment variables contain expired temporary credentials, which block the SDK from reaching the container credentials provider.

Since the environment variables are set, the SDK uses them and fails immediately rather than falling back to the task role credentials.

Determine the resolution method.

Remove the expired credential environment variables from the container configuration.

By removing these environment variables, the default credential provider chain will successfully fall back to the ECS task role credentials retrieved from the container metadata URI.

Anahtar Kavram

AWS SDK Default Credential Provider Chain Precedence

Soru 3Soru →

A developer is migrating a backend AWS Lambda function from a Lambda custom (non-proxy) integration to a Lambda proxy integration on an Amazon API Gateway REST API. Under the custom integration, the Lambda function received a pre-mapped JSON payload containing query parameters and headers, and it returned a simple JSON object:

`{ "status": "success", "data": { "userId": 101 } }`

After configuring the API Gateway to use Lambda Proxy Integration, clients receive a 502 Bad Gateway error on all API requests. Additionally, the Lambda function execution logs show errors indicating that the incoming event format is unexpected.

Which of the following modifications must the developer make to resolve these errors?

Modify the Lambda function to parse the incoming request body from the event.body property, and update the function's return statement to return a JSON object with statusCode and a stringified JSON body.

Define an Integration Request mapping template in API Gateway to map the client request to the Lambda input event, and define an Integration Response to map the Lambda return payload to a Method Response.

Configure a Lambda authorizer for the API Gateway method to authenticate the client request and inject the required request context before invoking the backend Lambda function.

Add Access-Control-Allow-Origin headers to the API Gateway Method Response configuration and configure API Gateway to automatically convert the Lambda output string into a 502 status code.

Cevabı ve açıklamayı göster

Cevap: Modify the Lambda function to parse the incoming request body from the event.body property, and update the function's return statement to return a JSON object with statusCode and a stringified JSON body.

Cevap

The correct option is to modify the Lambda function to parse the incoming request body from the event.body property and return a JSON object with statusCode and a stringified JSON body. This is because Lambda proxy integration passes the entire HTTP request wrapper where the request body is stringified, and requires the response to conform strictly to a response format containing statusCode and body fields.

Adım Adım Çözüm

Understand the difference between Lambda custom integration and Lambda proxy integration input events.

In custom integrations, API Gateway maps parameters and payload before invoking Lambda. In proxy integrations, API Gateway passes the raw request inside an event object, where the body is a stringified JSON in the event.body property.

This explains why the Lambda function logged unexpected event format errors after the integration type was changed to proxy.

Understand the difference in response expectations for Lambda proxy integration.

Lambda proxy integration requires the backend function to return a specific JSON response containing at least statusCode (an integer) and body (a string representing the response payload).

If the backend returns a custom JSON object or a raw string instead of this expected format, API Gateway cannot parse it and yields a 502 Bad Gateway error.

Implement code changes in the Lambda function to parse the input and format the output correctly.

The function parses event.body for incoming parameters and returns an object such as { statusCode: 200, body: JSON.stringify({ status: 'success', data: { userId: 101 } }) }.

This matches the input and output requirements for Lambda proxy integration and resolves both the execution logs error and the 502 Bad Gateway response.

Anahtar Kavram

The primary difference in payload structure and response contract between API Gateway Lambda Proxy and Lambda Custom (non-proxy) integrations.

Tahmini Süre:2m 0s

Soru 4Soru →

A developer is building a document processing application that must secure sensitive PDF documents before uploading them to a third-party storage service. The average size of each document is $15\text{ MB}$ . To meet security requirements, the developer must encrypt the documents client-side using an AWS KMS Customer Managed Key (CMK) while minimizing latency and network overhead. Which approach should the developer implement to encrypt these documents securely and efficiently?

Call the KMS Encrypt API directly, passing the raw document binary as the plaintext parameter along with the CMK ARN, and store the returned ciphertext.

Call the KMS GenerateDataKey API with the CMK to obtain a plaintext data key and an encrypted data key. Encrypt the document locally using the plaintext data key, delete the plaintext key from memory, and store the encrypted data key alongside the encrypted document.

Call the KMS GenerateDataKeyWithoutPlaintext API to retrieve an encrypted data key. Send the encrypted data key to the KMS Decrypt API to get the plaintext key, encrypt the document locally, and store the encrypted data key with the document.

Retrieve a pre-generated symmetric key stored in AWS Systems Manager Parameter Store as a SecureString parameter using the GetParameter API. Encrypt the document locally with this key and discard the retrieved parameter value.

Cevabı ve açıklamayı göster

Cevap: Call the KMS GenerateDataKey API with the CMK to obtain a plaintext data key and an encrypted data key. Encrypt the document locally using the plaintext data key, delete the plaintext key from memory, and store the encrypted data key alongside the encrypted document.

Cevap

The correct approach is to call the KMS GenerateDataKey API to obtain both a plaintext data key and an encrypted data key. The plaintext key is used to encrypt the document locally, and is then discarded from memory. The encrypted data key is stored alongside the encrypted document so that it can be decrypted later using the Decrypt API. This utilizes envelope encryption, which is necessary because the documents exceed the size limit of the direct KMS Encrypt API.

Adım Adım Çözüm

Evaluate the file size (

15\text{ MB}

) against AWS KMS direct encryption payload limits.

Since the direct KMS Encrypt API has a strict limit of

4\text{ KB}

, direct encryption is not possible. Envelope encryption must be used.

To select the appropriate KMS workflow based on payload size constraints.

Determine the most efficient API call for obtaining data keys for client-side envelope encryption.

GenerateDataKey returns both the plaintext key (for local encryption) and the encrypted key (for storage) in a single network request.

To minimize latency and network calls during document upload processing.

Validate security best practices for handling the generated plaintext data key.

Once the document is encrypted locally with the plaintext key, the plaintext key is deleted from application memory, and the encrypted key is packaged with the ciphertext.

To ensure the plaintext key is not exposed or leaked.

Anahtar Kavram

Client-side envelope encryption workflow using AWS KMS GenerateDataKey API

Tahmini Süre:2m 0s

Soru 5Soru →

A company is developing a desktop-based administration client that must allow authenticated internal users to upload system logs directly to a secure Amazon S3 bucket. The developer wants to manage user registration, sign-in, and password recovery natively within the client, while ensuring that the desktop application receives temporary, limited-privilege AWS credentials to perform the S3 uploads without embedding long-term AWS access keys.

Which architecture should the developer implement to meet these requirements?

Use an Amazon Cognito User Pool to manage user authentication, and use an Amazon Cognito Identity Pool to exchange the User Pool identity tokens for temporary AWS IAM credentials that authorize writing to the Amazon S3 bucket.

Use an Amazon Cognito Identity Pool to manage user registration and directory management, and configure an AWS Lambda post-confirmation trigger to return temporary AWS credentials directly to the client.

Use an Amazon Cognito User Pool to authenticate users, and configure an Amazon API Gateway REST API with a Cognito Authorizer to generate and return temporary AWS credentials to the desktop client.

Use an Amazon Cognito User Pool to authenticate users, and configure an IAM User with a resource-based trust policy that allows the desktop application to assume the user identity based on client IP addresses.

Cevabı ve açıklamayı göster

Cevap: Use an Amazon Cognito User Pool to manage user authentication, and use an Amazon Cognito Identity Pool to exchange the User Pool identity tokens for temporary AWS IAM credentials that authorize writing to the Amazon S3 bucket.

Cevap

The correct architecture uses a Cognito User Pool to authenticate the desktop client users (handling registration, login, etc.) and generate JWT identity tokens. The client then passes this token to a Cognito Identity Pool, which validates it and returns temporary, restricted AWS IAM credentials. The desktop client can then use these credentials to upload files directly to S3.

Adım Adım Çözüm

Configure an Amazon Cognito User Pool.

Creates a user directory that handles user sign-up, sign-in, password reset, and produces JWT tokens (ID, Access, and Refresh tokens) upon successful authentication.

Required to handle native user authentication and directory management.

Configure an Amazon Cognito Identity Pool (Federated Identities) and associate it with the User Pool as an identity provider.

Allows the application to exchange the ID token issued by the User Pool for temporary AWS credentials.

Provides the mechanism to federate Cognito User Pool users into AWS IAM roles.

Define an IAM Role for authenticated users with a trust policy for Cognito Identity Pools and a permissions policy allowing S3 put-object actions.

Ensures that users mapped by the Identity Pool receive credentials scoped strictly to write to the designated S3 bucket.

Enforces least-privilege access for the S3 bucket operations.

Anahtar Kavram

Amazon Cognito User Pools vs Identity Pools

Soru 6Soru →

A developer is deploying a containerized application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. The application needs to retrieve data from an Amazon DynamoDB table. The developer creates an IAM role named AppDynamoDBRole with a permissions policy that allows dynamodb:GetItem and dynamodb:Query operations, and configures the task definition's taskRoleArn parameter to point to this role. The trust policy for AppDynamoDBRole is configured as follows:

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

When the containerized application runs, it fails to authenticate with DynamoDB, and the container logs show an authorization error when attempting to assume the task role. Which of the following modifications to the configuration will resolve this issue?

Change the Service value under the Principal block in the trust policy from ecs.amazonaws.com to ecs-tasks.amazonaws.com.

Change the taskRoleArn configuration in the task definition to executionRoleArn, and attach the DynamoDB permissions to the task execution role.

Change the Action in the trust policy from sts:AssumeRole to sts:AssumeRoleWithWebIdentity.

Add the ecs:StartTask permission to the executionRoleArn to authorize the containers to initiate the assume role action.

Cevabı ve açıklamayı göster

Cevap: Change the Service value under the Principal block in the trust policy from ecs.amazonaws.com to ecs-tasks.amazonaws.com.

Cevap

Change the Service value under the Principal block in the trust policy from ecs.amazonaws.com to ecs-tasks.amazonaws.com.

The correct option is changing the Service principal to ecs-tasks.amazonaws.com. When configuring an ECS task definition, the taskRoleArn parameter allows containerized applications to make authorized AWS API calls. To enable this, the ECS agent must assume the designated IAM role. The trust relationship policy of the IAM role must explicitly allow the ECS tasks service principal (ecs-tasks.amazonaws.com) to perform the sts:AssumeRole action.

Adım Adım Çözüm

Examine the trust policy of the IAM role to determine who is permitted to assume it.

The current trust policy permits the ecs.amazonaws.com service principal to assume the role.

This determines if the correct AWS service or identity has been granted trust.

Identify the service principal responsible for launching and executing ECS tasks.

ECS tasks run under the ecs-tasks.amazonaws.com service principal, whereas service-level control plane operations run under ecs.amazonaws.com.

The correct service principal must match the specific entity requesting the sts:AssumeRole action.

Update the trust policy to authorize the ecs-tasks.amazonaws.com service principal.

The ECS agent can now successfully assume the AppDynamoDBRole on behalf of the containerized application.

This establishes a valid trust relationship, resolving the authorization error.

Anahtar Kavram

IAM trust policies for Amazon ECS tasks must trust the ecs-tasks.amazonaws.com service principal to allow the ECS agent to assume the task role on behalf of containers.

Tahmini Süre:2m 0s

Soru 7Soru →

A developer is testing a Go microservice locally. The microservice uses the AWS SDK for Go v2 to retrieve parameter configurations from Amazon Systems Manager (SSM) Parameter Store using the following initialization code:

go
// WARNING: Do not hardcode credentials in production.
// This code relies on the default credential provider chain.
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
log.Fatalf("unable to load SDK config, %v", err)
}
client := ssm.NewFromConfig(cfg)

The application runs inside a local Docker container as a non-root user `appuser` (home directory `/home/appuser`). To supply AWS credentials to the container, the developer ran the container with the environment variable `AWS_PROFILE=dev-profile` and mounted the host's `~/.aws/credentials` file to `/home/appuser/.aws/credentials`.

On the host machine, the AWS CLI configurations are:

`~/.aws/config`:
ini
[profile dev-profile]
role_arn = arn:aws:iam::123456789012:role/DevDeveloperRole
source_profile = base-profile

`~/.aws/credentials` (using placeholder credentials for security):
ini
[base-profile]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

When the application runs in the container, it fails with the error `operation error SSM: GetParameter, failed to resolve credentials`. However, running `aws ssm get-parameter --name /app/config --profile dev-profile` directly on the host machine succeeds.

Which of the following is the root cause of this credential resolution failure?

The AWS SDK for Go v2 default credential chain does not support containerized environments, requiring the developer to pass the raw credentials directly into the `config.LoadDefaultConfig` function parameters in the application code.

The IAM role trust policy for `DevDeveloperRole` does not authorize the service principal `ecs-tasks.amazonaws.com` to assume the role, causing the STS assume-role operation to fail when initiated from the container environment.

The `dev-profile` profile relies on a role assumption chain defined in the host's `~/.aws/config` file, which was not mounted into the container, preventing the SDK from locating the profile configuration.

The Go SDK requires the application to retrieve credentials from AWS Systems Manager Parameter Store or AWS Secrets Manager rather than reading profile configurations from the local filesystem.

Cevabı ve açıklamayı göster

Cevap: The `dev-profile` profile relies on a role assumption chain defined in the host's `~/.aws/config` file, which was not mounted into the container, preventing the SDK from locating the profile configuration.

Cevap

The credential resolution failure is caused by the missing configuration file inside the container. The profile `dev-profile` is defined in the host's `~/.aws/config` file (which references `role_arn` and `source_profile`). Because only the `~/.aws/credentials` file was mounted to the container, the AWS SDK inside the container could not locate the definition for `dev-profile` and therefore could not resolve the credentials.

The correct answer points out that the profile configuration (`dev-profile`) specifying role-chaining parameters (`role_arn` and `source_profile`) resides in the host's `~/.aws/config` file. If only the `~/.aws/credentials` file is mounted to the container, the SDK cannot resolve the `dev-profile` name to its role assumption configuration, causing credential resolution to fail.

Adım Adım Çözüm

Analyze how the AWS SDK for Go v2 resolves credentials.

The SDK looks at environment variables like `AWS_PROFILE` and then checks the shared configuration file (`~/.aws/config`) and credentials file (`~/.aws/credentials`) in the user's home directory.

Understanding the credential resolution chain helps pinpoint where the lookup breaks.

Examine the volume mounts defined for the Docker container.

Only `~/.aws/credentials` is mounted to `/home/appuser/.aws/credentials`. The `~/.aws/config` file is not mounted.

This shows that the containerized SDK only has access to the credentials file and not the configuration file.

Evaluate the profile configuration structure.

The target profile `dev-profile` is configured in `~/.aws/config` using `role_arn` and `source_profile`. The credentials for `base-profile` are in `~/.aws/credentials`.

Because the SDK in the container lacks the config file, it cannot read the definition for `dev-profile`, preventing it from understanding that it must assume a role using the `base-profile` credentials.

Anahtar Kavram

Credential File vs Configuration File in AWS SDK Profile Resolution

Alternatif Yöntem

Instead of mounting individual files, the developer can mount the entire `~/.aws` directory to `/home/appuser/.aws` in the container. This ensures both `config` and `credentials` files are accessible, permitting the SDK to chain profiles successfully.

Tahmini Süre:2m 30s

Soru 8Soru →

A developer is managing an AWS CloudFormation stack for a production application. After a failed update to an Amazon RDS database instance, the stack is stuck in the UPDATE_ROLLBACK_FAILED state. The developer discovers that another team member had previously made manual, out-of-band configuration changes to the database instance directly in the AWS Console. How should the developer resolve this situation and successfully perform the stack update?

Manually delete the database instance via the Amazon RDS console, manually recreate a new database instance with the target configuration, and then run drift detection to automatically reconcile the stack.

Directly run the update-stack CLI command with the updated template and a --force-update flag to override the failed rollback state and apply the new configuration.

Identify the manual changes, use the CloudFormation console or CLI to run the ContinueUpdateRollback action to return the stack to a stable state, update the template to reflect the actual resource configuration, and then perform the update.

Create a new Systems Manager Parameter Store parameter of type String to store the database password, and update the template to reference it using the {{resolve:ssm:parameter_name}} dynamic reference.

Cevabı ve açıklamayı göster

Cevap: Identify the manual changes, use the CloudFormation console or CLI to run the ContinueUpdateRollback action to return the stack to a stable state, update the template to reflect the actual resource configuration, and then perform the update.

Cevap

To resolve an UPDATE_ROLLBACK_FAILED state caused by out-of-band changes, the developer must run the ContinueUpdateRollback action to stabilize the stack, align the template with the actual resource state, and then perform the update.

Executing the ContinueUpdateRollback action is the standard AWS procedure to recover a stack from the UPDATE_ROLLBACK_FAILED state. Once the stack is stabilized to UPDATE_ROLLBACK_COMPLETE, the developer can align the template with the actual drifted state of the database and safely run the update.

Adım Adım Çözüm

Identify manual configuration changes that caused the rollback failure.

Find the drift or discrepancy between the template and the actual resource state.

Manual out-of-band changes prevent CloudFormation from rolling back resources to their expected state.

Execute the ContinueUpdateRollback operation via the CLI or AWS Console.

The stack transitions from UPDATE_ROLLBACK_FAILED to UPDATE_ROLLBACK_COMPLETE.

This action bypasses or retries the failed rollback step, bringing the stack back to a stable state where updates are permitted.

Align the template with the actual configuration of the resources and redeploy.

The stack is successfully updated with no configuration drift.

Ensuring the template matches the real-world state prevents future update or rollback failures.

Anahtar Kavram

Resolving CloudFormation stack update rollback failures caused by resource drift

Tahmini Süre:1m 30s

Soru 9Soru →

A developer is troubleshooting an authorization issue with a REST API in Amazon API Gateway. The API uses a custom Lambda authorizer with caching enabled, and the cache key is set to the Authorization header. When a client sends a request to GET /orders/101 with a valid token, the request succeeds. However, when the same client immediately sends a request to GET /orders/202 using the same token, the client receives a 403 Forbidden error with the message 'User is not authorized to access this resource'. The developer verifies that the client has valid permissions for both order resources. What is the root cause of this authorization failure, and how should it be resolved?

The Lambda authorizer returned a resource ARN specific to the first request's path, which was cached. Subsequent requests for different paths with the same token reuse the cached policy and are denied. To resolve this, configure the Lambda authorizer to return a wildcard resource ARN covering all paths, or disable caching.

The Lambda authorizer's IAM execution role lacks permissions to assume the client's IAM role for the second request. To resolve this, modify the trust policy of the client's IAM role to allow the sts:AssumeRole action for the Lambda authorizer's execution role.

The API Gateway service principal lacks permissions to invoke the Lambda authorizer for the second path resource. To resolve this, add a resource-based policy to the Lambda authorizer function to grant lambda:InvokeFunction permission to apigateway.amazonaws.com.

The API Gateway API must use a Cognito User Pools authorizer instead of a custom Lambda authorizer to validate identity tokens. To resolve this, configure Cognito User Pools and associate it with a Cognito Identity Pool to map groups to IAM roles for dynamic path authorization.

Cevabı ve açıklamayı göster

Cevap: The Lambda authorizer returned a resource ARN specific to the first request's path, which was cached. Subsequent requests for different paths with the same token reuse the cached policy and are denied. To resolve this, configure the Lambda authorizer to return a wildcard resource ARN covering all paths, or disable caching.

Cevap

When caching is enabled, API Gateway caches the policy returned by the Lambda authorizer using the cache key (the token). If the policy specifies a resource-specific ARN (like the path of the first request), any subsequent requests to a different path with the same token will use the cached policy and fail with a 403 Forbidden error because that path is not allowed in the policy. Returning a wildcard ARN or disabling caching resolves this issue.

Adım Adım Çözüm

Analyze the symptoms of the authorization failure where the first request succeeds but the subsequent request with the same token to a different path fails with a 403 Forbidden error.

Identify that the Lambda authorizer has caching enabled with the Authorization header as the cache key.

This helps narrow down the problem to how API Gateway caches and evaluates the IAM policy returned by the Lambda authorizer.

Examine how API Gateway caches policies based on the custom Lambda authorizer configuration.

The authorizer returns a policy containing the resource ARN for the specific path of the first request (/orders/101), which is then cached by API Gateway for that authorization token.

API Gateway uses the cached policy for all subsequent requests containing the same token during the TTL period, without invoking the Lambda function again.

Determine how the cached policy affects the second request (GET /orders/202).

Because the cached policy only allows access to the resource ARN for /orders/101, API Gateway denies access to /orders/202 and returns a 403 Forbidden error.

This confirms that the narrow resource scope in the cached policy is the root cause of the authorization failure.

Formulate the resolution to fix the authorization issue.

Modify the Lambda authorizer code to return a wildcard resource ARN (e.g., /orders/*) so that the cached policy permits access to all relevant paths, or disable caching if granular per-path verification is required on every request.

This ensures that either the cached policy is broad enough to cover all client requests or that the authorizer runs on every request to generate a precise policy.

Anahtar Kavram

API Gateway custom Lambda authorizer policy caching and resource ARN validation.

Soru 10Soru →

A developer is troubleshooting an application named PixelStream that uploads high-resolution images. The application stores metadata in an Amazon DynamoDB table where the partition key is set to the upload date (formatted as YYYY-MM-DD). During peak hours, the application frequently encounters ProvisionedThroughputExceededException errors even though the table's overall consumed throughput is well below the provisioned write capacity limit. What is the most effective way to resolve this throughput issue?

Redesign the partition key schema to use a more granular attribute, such as a unique Image ID, to distribute write requests evenly across partitions.

Increase the Amazon SQS visibility timeout of the incoming queue to allow the consumers more time to write records to the table.

Modify the application configuration to hardcode the AWS access keys and force the SDK client to throttle its own requests.

Modify the application queries to perform table Scan operations instead of Query operations to read data from all partitions.

Cevabı ve açıklamayı göster

Cevap: Redesign the partition key schema to use a more granular attribute, such as a unique Image ID, to distribute write requests evenly across partitions.

Cevap

Redesign the partition key schema to use a more granular attribute, such as a unique Image ID, to distribute write requests evenly across partitions.

Redesigning the partition key schema to use a high-cardinality attribute, such as a unique Image ID, spreads write operations across multiple physical partitions, preventing any single partition from exceeding its individual throughput limits.

Adım Adım Çözüm

Analyze the table schema and error behavior.

Identify that the partition key is the upload date, which has very low cardinality and results in all writes for a given day hitting the same partition.

This confirms that the ProvisionedThroughputExceededException is caused by a hot partition key rather than exceeding the table's total capacity.

Determine the solution for even data distribution.

Select a partition key with high cardinality, such as a unique Image ID.

High-cardinality keys distribute write requests evenly across physical partitions, resolving partition-level write limits.

Anahtar Kavram

Selecting a partition key with high cardinality to distribute write requests evenly and avoid hot partition bottlenecks.

Tahmini Süre:1m 0s

Soru 11Soru →

A developer is troubleshooting a CI/CD pipeline in AWS CodePipeline that deploys infrastructure using AWS CloudFormation. During the initial deployment of a new stack, the deployment stage failed due to an invalid parameter value, leaving the CloudFormation stack in the ROLLBACK_COMPLETE state. After correcting the parameter value in the template and pushing the fix to the source repository, the pipeline runs again but the CloudFormation deploy stage fails immediately, indicating that the stack cannot be updated. Which action must the developer perform to successfully deploy the stack through the pipeline?

Delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again.

Execute the aws cloudformation continue-update-rollback CLI command to force the stack back to an active state, then trigger the pipeline.

Modify the trust policy of the CloudFormation execution role to allow the cloudformation.amazonaws.com service principal to assume the role, and then release the change.

Run drift detection on the stack to identify manually modified resources, resolve the drift, and trigger the pipeline.

Cevabı ve açıklamayı göster

Cevap: Delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again.

Cevap

Delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again.

The correct answer is to delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again. When a CloudFormation stack fails during its initial creation, it goes into the ROLLBACK_COMPLETE state. CloudFormation does not allow updates to a stack that has never been successfully created. Therefore, to proceed, the developer must delete the failed stack, which removes it, allowing the pipeline's subsequent run to perform a successful create operation.

Adım Adım Çözüm

Identify the current status of the CloudFormation stack from the AWS CloudFormation console or CLI.

The stack is found to be in the ROLLBACK_COMPLETE state due to a failed initial creation.

Understanding the exact failure state is necessary because different rollback states (e.g., ROLLBACK_COMPLETE vs UPDATE_ROLLBACK_COMPLETE) have different recovery paths.

Determine the supported actions for a stack in the ROLLBACK_COMPLETE state.

A stack in ROLLBACK_COMPLETE cannot be updated; it can only be deleted.

This determines that attempting to push template updates through the pipeline directly will continue to fail, as the pipeline will attempt to perform a stack update action.

Delete the failed stack and re-run the pipeline.

The pipeline runs successfully and creates the stack from scratch with the corrected template.

Deleting the stack removes the blocked state, allowing the pipeline's CloudFormation action to execute a clean stack creation.

Anahtar Kavram

Handling CloudFormation initial creation failures and the ROLLBACK_COMPLETE state in CI/CD pipelines.

Soru 12Soru →

An application running inside an Amazon ECS task on AWS Fargate in Account A ( $111111111111$ ) needs to write objects to an Amazon S3 bucket located in Account B ( $222222222222$ ). The developer wants the application to temporarily assume an IAM role named CrossAccountS3Writer in Account B. The ECS task definition is configured with an ECS Task Role named ECSTaskRole.

The trust policy of the CrossAccountS3Writer role in Account B contains the following statement:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/ECSTaskRole"
},
"Action": "sts:AssumeRole"
}
]
}

When the application execution code attempts to call the sts:AssumeRole API, it fails with an AccessDenied error. How should the developer resolve this authorization failure?

Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

Attach an identity-based policy to the ECS Task Execution Role in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

Modify the trust policy of the CrossAccountS3Writer role in Account B to specify the ECS service principal ecs-tasks.amazonaws.com as the principal instead of the ECSTaskRole ARN.

Generate long-term IAM access keys for a user in Account B, hardcode them into the application's client initialization code, and initialize the S3 client directly using those credentials.

Cevabı ve açıklamayı göster

Cevap: Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

Cevap

Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

For cross-account role assumption, AWS IAM requires a bilateral handshake: the trusting role (in Account B) must specify the external principal in its trust policy, and the trusted principal (in Account A) must have an identity-based policy that grants permission to call 'sts:AssumeRole' on the target role's ARN. Since the trust policy in Account B is already correctly configured, adding the 'sts:AssumeRole' permission to the ECSTaskRole in Account A completes this handshake and resolves the AccessDenied error.

Adım Adım Çözüm

Analyze the error context and the resource policy configuration.

The application inside the ECS task is trying to assume the CrossAccountS3Writer role in Account B, but the AssumeRole request is denied.

Establishing cross-account delegation requires explicit authorization in both accounts: a trust relationship in the receiving account (Account B) and an identity-based grant in the initiating account (Account A).

Examine the trust policy of the target role (CrossAccountS3Writer) in Account B.

The trust policy correctly allows the identity 'arn:aws:iam::111111111111:role/ECSTaskRole' to call 'sts:AssumeRole'.

This confirms that Account B is configured properly to trust the ECS Task Role from Account A.

Determine the missing permission in the initiating account (Account A).

The ECS Task Role (ECSTaskRole) itself does not have a policy permitting it to invoke 'sts:AssumeRole' on the destination role.

IAM identities require explicit permission to call 'sts:AssumeRole' on a resource in another account, even if that resource trusts them.

Select the correct action to resolve the authorization failure.

Add an identity-based policy to 'ECSTaskRole' with an 'Allow' effect on the 'sts:AssumeRole' action, specifying the ARN of the target role in Account B as the resource.

This satisfies the cross-account delegation requirements by authorizing the ECS Task Role to perform the assume-role request.

Anahtar Kavram

Cross-Account IAM Delegation and ECS Task Roles

Soru 13Soru →

A developer has configured an AWS Lambda function written in Python to process events from an Amazon SQS queue and write the results to an Amazon DynamoDB table. Active tracing is enabled on both the SQS queue and the Lambda function. When reviewing the AWS X-Ray console, the developer observes that the service map shows the SQS queue and the Lambda function, but the downstream calls to DynamoDB are missing from the trace. Which action should the developer take to trace the downstream DynamoDB calls in AWS X-Ray?

Manually extract the _X_AMZN_TRACE_ID tracing header from the SQS event object and pass it as a custom parameter in the DynamoDB API request payload.

Initialize the Boto3 DynamoDB client with hardcoded AWS access keys and secret keys that have X-Ray write permissions.

Import the AWS X-Ray SDK in the Lambda function code and invoke the patch_all() function before initializing the Boto3 client.

Increase the SQS visibility timeout of the source queue to allow the Boto3 SDK sufficient time to complete and flush the DynamoDB trace segments.

Cevabı ve açıklamayı göster

Cevap: Import the AWS X-Ray SDK in the Lambda function code and invoke the patch_all() function before initializing the Boto3 client.

Cevap

Import the AWS X-Ray SDK in the Lambda function code and invoke the patch_all() function before initializing the Boto3 client.

The correct answer is to import the AWS X-Ray SDK and run the patch_all() function. When running a Python Lambda function with active tracing enabled, downstream SDK calls are not traced by default unless the Boto3 library is instrumented. Patching the library automatically wraps Boto3 clients so that downstream calls (like DynamoDB operations) are recorded as subsegments in the X-Ray trace.

Adım Adım Çözüm

Identify that the Lambda function has active tracing enabled but downstream calls to DynamoDB are not being recorded.

The Lambda function segment is present, but DynamoDB subsegments are missing.

Active tracing on Lambda only traces the Lambda execution itself, not downstream SDK calls by default.

Instrument the Boto3 library using the AWS X-Ray SDK for Python.

The Boto3 clients will automatically generate and propagate subsegment details for downstream API calls.

Patching is the standard method in the Python AWS X-Ray SDK to instrument supported libraries like Boto3 without modifying client invocation syntax.

Anahtar Kavram

AWS SDK client instrumentation using the X-Ray SDK to trace downstream AWS service calls.

Soru 14Soru →

A developer is troubleshooting an AWS Lambda function with a configured timeout of 10 seconds. The function is occasionally failing to process incoming payloads. The developer wants to configure an Amazon CloudWatch Logs metric filter to count how many times the function executions are terminated due to timeouts, and to trigger an alarm. The application code is designed to log custom execution details in JSON format, including `{ "execution_time_ms": 10500, "status": "success" }`, at the end of the handler execution. Which configuration should the developer implement to reliably monitor these execution timeouts?

Create a metric filter on the log group with the pattern `{ $.execution_time_ms > 10000 }` and create a CloudWatch alarm based on this metric.

Create a metric filter on the log group with the pattern `{ $.status = "timeout" }` and create a CloudWatch alarm based on this metric.

Create a metric filter on the log group with the pattern "Task timed out" and create a CloudWatch alarm based on this metric.

Create a metric filter on the log group with the pattern `[timestamp, request_id, status = "timeout"]` and create a CloudWatch alarm based on this metric.

Cevabı ve açıklamayı göster

Cevap: Create a metric filter on the log group with the pattern "Task timed out" and create a CloudWatch alarm based on this metric.

Cevap

Create a metric filter on the log group with the pattern "Task timed out" and create a CloudWatch alarm based on this metric.

When a Lambda function times out, the Lambda service halts execution immediately. This prevents the custom application code from completing and writing any custom JSON log events. Instead, the service writes a message containing 'Task timed out' to the log stream. Therefore, a metric filter targeting this literal string is the only reliable way to count timeouts.

Adım Adım Çözüm

Analyze Lambda execution behavior during a timeout

When a Lambda function reaches its configured timeout limit (10 seconds in this scenario), the AWS Lambda service terminates the execution container immediately.

This shows that any application-level code designed to run at the end of the handler (such as writing a custom JSON log with execution metrics) is never executed.

Identify the log event recorded during a timeout

The AWS Lambda service runtime writes a platform-generated log line to the log stream, containing the phrase: 'Task timed out after 10.00 seconds'.

To reliably track timeouts, the metric filter must search for this platform-generated text rather than custom JSON properties that are only written upon successful handler execution.

Select the correct CloudWatch Logs Metric Filter syntax

The literal pattern "Task timed out" is used to match the platform log event. An alarm is then associated with this metric to trigger notifications or scaling actions.

This correctly targets the service-level error message and tracks execution failures accurately.

Anahtar Kavram

AWS Lambda platform logging on execution timeouts vs application-level logs, and correct CloudWatch metric filter string matching.

Tahmini Süre:1m 30s

Soru 15Soru →

A developer is designing a web application dashboard for a smart home IoT system. The application needs to allow users to sign in using their email and password or their social identity provider. Once authenticated, the web application must securely download and upload user-specific configuration files directly from an Amazon S3 bucket. Additionally, the application must invoke backend REST API endpoints hosted on Amazon API Gateway, which should only be accessible to authenticated users.

Which Cognito configuration should the developer choose to satisfy these requirements with the least operational overhead?

Configure a Cognito Identity Pool to manage user registration, local password policies, and social provider integration. Secure the API Gateway REST API using an API Gateway Cognito Authorizer with the Identity Pool token, and access the S3 bucket using the same token.

Configure a Cognito User Pool for user authentication and federation. Configure an API Gateway Custom Lambda Authorizer that calls the Cognito Identity Pool credentials exchange API for every request, and use the returned IAM credentials to authorize the user.

Configure a Cognito User Pool to handle registration, login, and social identity provider federation. Secure the API Gateway REST API with a Cognito Authorizer using the User Pool ID token. Configure a Cognito Identity Pool with the User Pool as an identity provider to obtain temporary AWS credentials for S3 access.

Configure a Cognito User Pool to authenticate users. Store static IAM access keys and secret keys in the User Pool's custom user attributes, retrieve these attributes upon login, and use them to sign requests to API Gateway and S3.

Cevabı ve açıklamayı göster

Cevap: Configure a Cognito User Pool to handle registration, login, and social identity provider federation. Secure the API Gateway REST API with a Cognito Authorizer using the User Pool ID token. Configure a Cognito Identity Pool with the User Pool as an identity provider to obtain temporary AWS credentials for S3 access.

Cevap

The correct approach uses an Amazon Cognito User Pool to manage authentication (handling registration, local credentials, and social provider federation) and uses the resulting JSON Web Token (JWT) ID token to authorize API requests via the built-in API Gateway Cognito Authorizer. To access AWS resources like Amazon S3, a Cognito Identity Pool is required to exchange the User Pool tokens for temporary AWS IAM credentials.

Adım Adım Çözüm

Select Cognito User Pools for user sign-in and management.

Users can register, sign in, and federate through social identity providers to receive JWT tokens.

Cognito User Pools serve as the user directory and handle the authentication flow.

Integrate API Gateway with the Cognito User Pool.

API Gateway uses a native Cognito Authorizer to validate incoming ID tokens directly.

This secures the REST API without requiring custom Lambda code or credentials exchange for API calls.

Configure a Cognito Identity Pool with the User Pool as a provider.

The client application exchanges the User Pool token for temporary AWS IAM credentials.

These temporary credentials allow the client application to directly and securely upload files to Amazon S3.

Anahtar Kavram

Distinction between Cognito User Pools (authentication and user directory) and Cognito Identity Pools (authorization and temporary AWS credentials exchange), as well as integrating User Pools with API Gateway Cognito Authorizers.

Tahmini Süre:1m 30s

Soru 16Soru →

A developer is deploying an application on an Amazon EC2 instance. The application is configured to read configuration templates from an Amazon S3 bucket. The developer creates an IAM role named `AppConfigReadRole` with an attached policy that allows `s3:GetObject` on the target bucket. However, the application fails to retrieve the templates and receives an 'Access Denied' error. The developer inspects the trust policy of `AppConfigReadRole` and finds the following document:

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

Which of the following modifications to the trust policy will resolve the Access Denied error and allow the EC2 instance to assume the role?

Modify the trust policy statement to allow the `s3:GetObject` action instead of `sts:AssumeRole`.

Embed the AWS Access Key ID and Secret Access Key of a security administrator directly in the application code.

Change the principal service in the trust policy from `lambda.amazonaws.com` to `ec2.amazonaws.com`.

Change the principal service in the trust policy to `ecs-tasks.amazonaws.com` and attach it to the EC2 host's task execution role.

Cevabı ve açıklamayı göster

Cevap: Change the principal service in the trust policy from `lambda.amazonaws.com` to `ec2.amazonaws.com`.

Cevap

Changing the service principal in the trust policy from `lambda.amazonaws.com` to `ec2.amazonaws.com`.

The trust policy of an IAM role determines which principals are allowed to assume it. For an application running on an Amazon EC2 instance to assume a role via an instance profile, the role's trust policy must specify the EC2 service principal (`ec2.amazonaws.com`) under the `Principal.Service` key, along with the `sts:AssumeRole` action. The original policy mistakenly trusted the Lambda service principal (`lambda.amazonaws.com`), which prevented the EC2 instance from assuming the role.

Adım Adım Çözüm

Identify the compute environment where the application is running.

The application is running on an Amazon EC2 instance.

Understanding the host environment determines which AWS service principal needs permission to assume the IAM role.

Examine the trust policy of the `AppConfigReadRole` IAM role.

The principal is currently set to `lambda.amazonaws.com`.

An incorrect principal in a trust policy prevents the target service (EC2) from obtaining temporary credentials to assume the role.

Update the trust policy principal to match the hosting service.

Replace `lambda.amazonaws.com` with `ec2.amazonaws.com` in the trust policy.

This configures the role to trust the EC2 service, allowing the EC2 instance profile to successfully assume the role and access the S3 bucket.

Anahtar Kavram

IAM Role Trust Policies vs Permission Policies for EC2 Instances

Soru 17Soru →

A logistics tracking application named LogiRoute writes real-time status updates for packages to an Amazon DynamoDB table. During peak delivery hours, the application occasionally encounters ProvisionedThroughputExceededException errors when writing updates, causing the tracking requests to fail immediately. Monitoring metrics show that the table's total consumed write capacity remains well below its provisioned write capacity limit. Investigations reveal that the application's HTTP library is configured to disable automatic retries for all backend calls. How should the developer resolve these transient errors while minimizing cost?

Configure the AWS SDK client to use exponential backoff and jitter for handling transient write errors.

Increase the table's provisioned Write Capacity Units (WCUs) to accommodate the peak traffic spikes.

Perform a table Scan operation to verify the partition state before executing the write requests.

Queue the write requests in an Amazon SQS queue and set the visibility timeout to be shorter than the message processing time.

Cevabı ve açıklamayı göster

Cevap: Configure the AWS SDK client to use exponential backoff and jitter for handling transient write errors.

Cevap

Configure the AWS SDK client to use exponential backoff and jitter for handling transient write errors.

Configuring the AWS SDK client to use exponential backoff and jitter is the standard best practice for resolving transient ProvisionedThroughputExceededException errors when the overall capacity is sufficient. This allows the application to retry requests after a progressively longer, randomized delay, smoothing out traffic spikes and avoiding errors for the end user without increasing provisioned throughput costs.

Adım Adım Çözüm

Analyze the error message and CloudWatch metrics.

Identify that the ProvisionedThroughputExceededException errors are transient and occurring even though the total consumed capacity is below provisioned limits.

This indicates that overall capacity is sufficient, but temporary bursts or micro-bursts are causing brief throttling.

Identify the application-side behavior.

Determine that automatic retries are disabled, causing the application to fail immediately upon receiving the exception.

AWS SDKs by default implement retry logic, but disabling or misconfiguring it causes immediate failures on transient errors.

Implement retry logic with backoff and jitter.

Configure the AWS SDK client to retry throttled requests using exponential backoff and randomized jitter delays.

This spreads out the retry attempts, preventing them from hitting the database simultaneously and successfully completing the writes once the transient spike subsides.

Anahtar Kavram

Handling DynamoDB transient throttling errors using SDK retries with exponential backoff and jitter.

Tahmini Süre:1m 30s

Soru 18Soru →

A developer is deploying a critical update to a serverless API backend running on AWS Lambda. The application handles high-velocity flash sales where traffic spikes instantly. To eliminate cold start latencies, the developer configures Provisioned Concurrency for the Lambda function. The API backend is integrated with an Amazon API Gateway HTTP API.

During deployment, the developer uploads the new function code, publishes Version $2$ of the function, and associates Provisioned Concurrency with Version $2$ . However, when testing the API Gateway endpoint that routes traffic to the function using the $\text{LATEST}$ identifier, clients still experience significant cold start latencies, and CloudWatch metrics show that the provisioned concurrency is not being utilized.

What should the developer do to ensure that the API Gateway endpoint utilizes the provisioned concurrency?

Update the API Gateway integration to target a specific Lambda alias or a published function version that has Provisioned Concurrency configured, rather than targeting the

\text{LATEST}

identifier.

Increase the execution timeout of the Lambda function and modify the function code to execute a dummy helper request before handling the main request to pre-warm the execution environments.

Add the `lambda:InvokeFunction` permission for the Provisioned Concurrency execution role inside the function's IAM trust policy to allow execution environments to be pre-created.

Deploy the Lambda function in multiple private subnets across different Availability Zones and attach a NAT Gateway to ensure the provisioned environments can communicate with API Gateway.

Cevabı ve açıklamayı göster

Cevap: Update the API Gateway integration to target a specific Lambda alias or a published function version that has Provisioned Concurrency configured, rather than targeting the $\text{LATEST}$ identifier.

Cevap

Update the API Gateway integration to target a specific Lambda alias or a published function version that has Provisioned Concurrency configured, rather than targeting the

\text{LATEST}

identifier.

Provisioned Concurrency initializes a specified number of execution environments so that they are prepared to respond immediately to your function's invocations. However, AWS Lambda does not allow you to configure Provisioned Concurrency on the

\text{LATEST}

version of a function, and any invocations that target the

\text{LATEST}

identifier directly or through an alias pointing to

\text{LATEST}

will not utilize provisioned concurrency. Therefore, the API Gateway integration must be updated to target a published version or an alias pointing to a published version (such as Version

2

) that has Provisioned Concurrency configured.

Adım Adım Çözüm

Analyze the invocation path of the AWS Lambda function from API Gateway.

Identify that the API Gateway endpoint targets the

\text{LATEST}

identifier of the Lambda function.

To determine why the configured Provisioned Concurrency is not being utilized during invocation.

Review the AWS Lambda Provisioned Concurrency specifications and restrictions.

Understand that Provisioned Concurrency cannot be associated with or invoked through the

\text{LATEST}

identifier; it must be mapped to a specific published version or alias.

To identify the root cause of the cold start latency despite configuration.

Modify the routing configuration of the API Gateway and the Lambda function targeting.

Update the API Gateway integration target to point to a Lambda alias (e.g., pointing to Version

2

) or directly to Version

2

, which has Provisioned Concurrency active.

To route incoming API Gateway traffic to the pre-warmed execution environments.

Anahtar Kavram

AWS Lambda Provisioned Concurrency Routing and Versioning Rules

Tahmini Süre:2m 0s

Soru 19Soru →

A team of developers is deploying a backend processing application. An AWS Lambda function is configured to run inside a private VPC subnet to securely query an Amazon RDS PostgreSQL database located in another private subnet. The function must also download configuration files from Amazon S3 and make HTTP POST requests to an external, third-party payment processing API on the public internet. Which network configuration should the developer implement to enable these connections while minimizing data transfer costs and maintaining a secure architecture?

Deploy the Lambda function in the private subnets. Create a Gateway VPC Endpoint for Amazon S3, and configure a NAT Gateway in a public subnet to route outbound traffic to the public internet.

Deploy the Lambda function in the private subnets. Create an Internet Gateway in the VPC and associate a public IP address with the Lambda function to allow direct access to the public API.

Deploy the Lambda function in a public subnet and enable public IP assignment. Configure an Interface VPC Endpoint for Amazon S3 to handle object retrieval.

Deploy the Lambda function in the private subnets. Configure an Interface VPC Endpoint for Amazon S3, and create a VPC peering connection to route external API traffic through an on-premises network.

Cevabı ve açıklamayı göster

Cevap: Deploy the Lambda function in the private subnets. Create a Gateway VPC Endpoint for Amazon S3, and configure a NAT Gateway in a public subnet to route outbound traffic to the public internet.

Cevap

Deploy the Lambda function in the private subnets, configure a Gateway VPC Endpoint for Amazon S3, and deploy a NAT Gateway in a public subnet to route outbound public internet traffic.

Deploying the Lambda function in private subnets allows it to access the private RDS database securely. Using a Gateway VPC Endpoint for S3 is a cost-effective choice since Gateway Endpoints do not incur hourly or data processing charges, unlike Interface Endpoints. A NAT Gateway deployed in a public subnet is required to route outbound public internet traffic for the Lambda function in the private subnet.

Adım Adım Çözüm

Analyze the destination targets and security requirements.

The RDS database is private (requires private subnet association), S3 is an AWS service (can use a VPC endpoint), and the payment API is on the public internet (requires a NAT Gateway or NAT instance for private resources).

To determine the networking components needed for the VPC.

Determine the most cost-effective and secure way to access Amazon S3.

A Gateway VPC Endpoint is free and routes traffic directly to S3 without going through the NAT Gateway, saving data processing fees.

To minimize data transfer costs as requested.

Configure the route table for the private subnets where the Lambda function resides.

Add a route directing

0.0.0.0/0

traffic to the NAT Gateway in the public subnet.

To enable outbound internet access to the payment gateway API.

Anahtar Kavram

VPC networking for AWS Lambda, including NAT Gateway and VPC Endpoints.

Tahmini Süre:1m 30s

Soru 20Soru →

A developer is designing a real-time inventory management microservice that uses an Amazon DynamoDB table. The application needs to support the following operations during peak traffic:

* $10$ `TransactWriteItems` operations per second. Each transaction contains two write actions: one writes a new item of $3.5\text{ KB}$ , and another updates an existing item resulting in a final size of $1.5\text{ KB}$ .
* $15$ standard `PutItem` operations per second, with an average item size of $4.5\text{ KB}$ .
* $40$ `TransactGetItems` operations per second. Each transaction reads a single item of $6\text{ KB}$ .

To ensure optimal performance, scalability, and security under the AWS shared responsibility model, which capacity provisioning and development strategy should the developer implement?

Provision

195

Write Capacity Units (WCUs) and

160

Read Capacity Units (RCUs). Configure the application to use the default credential provider chain and retrieve items using Query or TransactGetItems operations instead of Scan.

Provision

135

Write Capacity Units (WCUs) and

80

Read Capacity Units (RCUs). Retrieve items using TransactGetItems operations, and initialize the DynamoDB client by passing hardcoded IAM access keys directly into the SDK constructor.

Provision

195

Write Capacity Units (WCUs) and

480

Read Capacity Units (RCUs). To prevent partition hotness and optimize downstream processing, replace single-item query operations with parallel Scan operations that periodically read the entire table.

Provision

168

Write Capacity Units (WCUs) and

160

Read Capacity Units (RCUs). If the application encounters a ProvisionedThroughputExceededException, immediately configure DynamoDB Auto Scaling to scale up provisioned capacity to resolve the error.

Cevabı ve açıklamayı göster

Cevap: Provision $195$ Write Capacity Units (WCUs) and $160$ Read Capacity Units (RCUs). Configure the application to use the default credential provider chain and retrieve items using Query or TransactGetItems operations instead of Scan.

Cevap

Provision

195

Write Capacity Units (WCUs) and

160

Read Capacity Units (RCUs). Configure the application to use the default credential provider chain and retrieve items using Query or TransactGetItems operations instead of Scan.

The correct strategy provisions

195

WCUs and

160

RCUs, uses the default credential provider chain for secure authentication, and retrieves specific items efficiently via Query or TransactGetItems instead of Scan. The Write Capacity Unit (WCU) calculation is as follows: The TransactWriteItems workload consists of

10

operations/second. Each operation has two write actions: a new item of

3.5\text{ KB}

(rounded up to

4\text{ KB}

, costing

4\text{ WCUs} \times 2

for transactional writes =

8\text{ WCUs}

) and an update resulting in a

1.5\text{ KB}

item (rounded up to

2\text{ KB}

, costing

2\text{ WCUs} \times 2

for transactional writes =

4\text{ WCUs}

). This totals

12\text{ WCUs}

per transaction, or

120\text{ WCUs}

for

10

transactions/second. The standard PutItem workload consists of

15

operations/second of

4.5\text{ KB}

(rounded up to

5\text{ KB}

, costing

5\text{ WCUs}

). This consumes

75\text{ WCUs}

. Summing these values gives

195\text{ WCUs}

. The Read Capacity Unit (RCU) calculation is as follows: The TransactGetItems workload consists of

40

operations/second. Each transaction reads one

6\text{ KB}

item (rounded up to the nearest

4\text{ KB}

boundary, which is

8\text{ KB}

, consuming

2\text{ RCUs}

). Since transactional reads consume double the RCUs of strongly consistent reads, each transaction costs

4\text{ RCUs}

, totaling

160\text{ RCUs}

for

40

operations/second.

Adım Adım Çözüm

Calculate the Write Capacity Units (WCUs) required for the

10

TransactWriteItems operations per second.

120

WCUs

Each transaction contains two write actions. Action 1 (

3.5\text{ KB}

) is rounded up to

4\text{ KB}

and multiplied by

2

for transaction writes, yielding

8\text{ WCUs}

. Action 2 (

1.5\text{ KB}

) is rounded up to

2\text{ KB}

and multiplied by

2

, yielding

4\text{ WCUs}

. Total per transaction is

12\text{ WCUs}

. For

10\text{ operations/sec}

, this consumes

10 \times 12 = 120\text{ WCUs}

Calculate the WCUs required for the

15

standard PutItem operations per second.

75

WCUs

Each standard write of

4.5\text{ KB}

is rounded up to

5\text{ KB}

and consumes

5\text{ WCUs}

. For

15\text{ operations/sec}

, this consumes

15 \times 5 = 75\text{ WCUs}

Sum the WCU requirements to find the total provisioned WCU.

195

WCUs

Combining the transactional writes (

120\text{ WCUs}

) and standard writes (

75\text{ WCUs}

) yields a total required write capacity of

195\text{ WCUs}

Calculate the Read Capacity Units (RCUs) required for the

40

TransactGetItems operations per second.

160

RCUs

Transactional reads are strongly consistent and consume double the capacity of standard strongly consistent reads. Reading a

6\text{ KB}

item requires rounding up to the nearest

4\text{ KB}

boundary (

8\text{ KB}

), consuming

2\text{ RCUs}

for a standard strongly consistent read. Doubling this for the transaction results in

4\text{ RCUs}

per operation. For

40\text{ operations/sec}

, this consumes

40 \times 4 = 160\text{ RCUs}

Evaluate the architectural and security configurations.

Use the default credential provider chain and query/retrieve items directly rather than scanning.

Hardcoding credentials violates security best practices, and using Scan operations instead of Query or specific read APIs is highly inefficient and consumes excess RCUs.

Anahtar Kavram

DynamoDB capacity calculation for transactional and standard operations combined with security and query optimization

Tahmini Süre:3m 0s

Sayfa 1 / 40Sonraki

Tüm alıştırma soruları

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Alternatif Yöntem

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Alternatif Yöntem

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap