Tüm alıştırma soruları

1542 soru

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

A developer is running a Python daemon application on an Amazon EC2 instance. The application processes tasks by retrieving messages from an Amazon SQS queue and making downstream API calls to an external gateway using the `requests` library. The AWS X-Ray daemon is running on the EC2 instance, and the EC2 instance profile has the `AWSXRayDaemonWriteAccess` policy attached. The application code imports `patch_all` from the AWS X-Ray SDK and calls it at startup. However, when the application runs, the external API calls do not appear in the X-Ray console, and the logs display `SegmentNotFoundException` errors.

What is the root cause of this issue?

The hosting environment on Amazon EC2 does not automatically initialize a trace segment. The developer must manually start and end a segment in the code using the X-Ray SDK.

The `patch_all()` function only instruments AWS SDK clients. The developer must manually extract the trace header from the SQS message and inject it into the HTTP headers of the `requests` library call.

The X-Ray SDK does not support the EC2 instance profile for authentication. The developer must explicitly initialize the X-Ray recorder with hardcoded AWS access keys.

The SQS visibility timeout is shorter than the time taken to call the external API, which causes the message to reappear on the queue and invalidates the active trace segment.

Cevabı ve açıklamayı göster

Cevap: The hosting environment on Amazon EC2 does not automatically initialize a trace segment. The developer must manually start and end a segment in the code using the X-Ray SDK.

Cevap

The hosting environment on Amazon EC2 does not automatically initialize a trace segment. The developer must manually start and end a segment in the code using the X-Ray SDK.

Unlike AWS Lambda, which automatically initializes a parent segment for every invocation, self-hosted environments such as Amazon EC2 do not automatically manage trace context. When a patched HTTP library like `requests` tries to trace an outbound call, it attempts to generate a subsegment. Because there is no active segment initialized in the thread context, the SDK throws a `SegmentNotFoundException`. To resolve this, the developer must explicitly start a segment (e.g., using `xray_recorder.begin_segment()`) and end it after processing is completed.

Adım Adım Çözüm

Analyze the error log containing `SegmentNotFoundException`.

Identify that the X-Ray SDK is attempting to create a subsegment for the downstream HTTP request but cannot find an active parent segment in the current execution context.

Patched libraries automatically attempt to create subsegments, which require a parent segment to exist.

Compare the runtime environment (Amazon EC2) behavior with AWS Lambda.

Acknowledge that AWS Lambda automatically manages the lifecycle of the trace segment (facade segment), whereas EC2 does not provide any automatic segment management for custom daemon applications.

This determines whether the framework/infrastructure or the code itself must manage the lifecycle of trace segments.

Determine the necessary code modification to establish the context.

Wrap the worker loop execution or downstream calls in a manually created segment using `xray_recorder.begin_segment('segment_name')` and `xray_recorder.end_segment()` or the corresponding context manager.

Explicitly declaring a segment provides the parent context required by the patched `requests` library.

Anahtar Kavram

X-Ray Segment Lifecycle Management on Non-Managed Environments

Tahmini Süre:2m 0s

Soru 1062Soru →

A developer is configuring an AWS Lambda function that needs to read objects from an Amazon S3 bucket. The developer creates an IAM role containing the following permission policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-app-data/*"
}
]
}

Which configuration must be applied to the trust policy of this IAM role so that the Lambda function can successfully assume it?

A trust policy that grants the ec2.amazonaws.com service principal permission to perform the sts:AssumeRole action

A trust policy that grants the lambda.amazonaws.com service principal permission to perform the sts:AssumeRole action

No trust policy is required; instead, the developer should initialize the AWS SDK client using static credentials of an IAM user hardcoded in the function code

A trust policy that grants the ecs-tasks.amazonaws.com service principal permission to perform the sts:AssumeRole action

Cevabı ve açıklamayı göster

Cevap: A trust policy that grants the lambda.amazonaws.com service principal permission to perform the sts:AssumeRole action

Cevap

A trust policy that grants the lambda.amazonaws.com service principal permission to perform the sts:AssumeRole action

For an AWS service like AWS Lambda to execute code and access other AWS resources, it must assume an IAM execution role. This requires a trust policy attached to the role that explicitly allows the 'lambda.amazonaws.com' service principal to call 'sts:AssumeRole'.

Adım Adım Çözüm

Identify the AWS service attempting to assume the IAM role.

The service is AWS Lambda.

The execution environment requires the Lambda service principal to acquire temporary credentials.

Verify the correct service principal name for AWS Lambda.

The principal is lambda.amazonaws.com.

Each AWS service has a specific principal identifier used in trust policies.

Determine the API action required for assuming a role.

The action is sts:AssumeRole.

The Security Token Service (STS) action sts:AssumeRole is required to delegate access to services or accounts.

Anahtar Kavram

IAM trust policies define which principals (users, accounts, or services) are allowed to assume an IAM role.

Soru 1063Soru →

A developer has enabled active tracing on an AWS Lambda function that is triggered by an Amazon SQS queue. The Lambda function processes the messages and writes the results to an Amazon DynamoDB table. While reviewing the trace map in the AWS X-Ray console, the developer observes that the Lambda function execution is traced, but the downstream calls to DynamoDB do not appear in the traces. Which of the following actions should the developer take to resolve this issue?

Instrument the AWS SDK client in the Lambda function code using the AWS X-Ray SDK.

Initialize the AWS SDK client by hardcoding the AWS access key and secret access key in the function code.

Increase the Lambda function execution timeout to match the visibility timeout of the Amazon SQS queue.

Change the API Gateway integration type to use Lambda Proxy integration.

Cevabı ve açıklamayı göster

Cevap: Instrument the AWS SDK client in the Lambda function code using the AWS X-Ray SDK.

Cevap

Instrument the AWS SDK client in the Lambda function code using the AWS X-Ray SDK.

The correct answer is to instrument the AWS SDK client using the AWS X-Ray SDK. Enabling active tracing on Lambda only configures the Lambda service to trace the function execution. To trace downstream HTTP/HTTPS calls to services like DynamoDB, the AWS SDK client within the function code must be wrapped or patched by the AWS X-Ray SDK.

Adım Adım Çözüm

Identify the cause of the missing downstream service call subsegments in the AWS X-Ray trace map.

The Lambda service itself generates the main segment, but downstream calls (like DynamoDB) require the AWS SDK to be instrumented to record subsegments.

By default, the standard AWS SDK does not automatically send trace data to X-Ray unless instrumented.

Use the AWS X-Ray SDK to wrap or patch the AWS SDK client inside the Lambda function code.

Downstream calls made via the instrumented SDK client will now generate and propagate trace context to DynamoDB.

This is necessary to capture trace subsegments for outbound calls.

Anahtar Kavram

AWS SDK Instrumentation for AWS X-Ray

Soru 1064Soru →

An analytics application utilizes an AWS Lambda function to generate daily reports. The function downloads several source files to the local ephemeral storage (`/tmp`), merges them, and uploads the final report to Amazon S3. The function is configured with $512\text{ MB}$ of ephemeral storage. While initial test runs succeed, the function intermittently fails during peak hours with a `No space left on device` error, even though the source files for any single invocation never exceed $100\text{ MB}$ in total. What is the root cause of this failure, and how should the developer resolve it?

The execution context is being reused across invocations, causing files from previous runs to persist in the `/tmp` directory. The developer should modify the code to delete temporary files from `/tmp` before the function execution completes.

The developer assumed that the ephemeral storage is automatically wiped by Lambda between warm starts. The developer should increase the Lambda function's execution timeout limit to allow the platform's automatic background garbage collector to clean up the directory.

The Lambda function is deployed in a private VPC subnet without a NAT Gateway or VPC endpoint to access the Amazon S3 service. The developer should configure a NAT Gateway in the public subnet and update the route tables to allow the function to upload the files and free up storage.

The Lambda function's execution role trust policy is missing the `lambda.amazonaws.com` service principal, preventing the function from writing log streams to CloudWatch and causing local write buffers to overflow. The developer should modify the trust policy to allow the service principal.

Cevabı ve açıklamayı göster

Cevap: The execution context is being reused across invocations, causing files from previous runs to persist in the `/tmp` directory. The developer should modify the code to delete temporary files from `/tmp` before the function execution completes.

Cevap

The correct answer is the option explaining that the execution context is reused across invocations, which preserves files in the `/tmp` directory. To resolve the issue, the developer must explicitly delete the files before the invocation ends. AWS Lambda reuses execution environments to avoid cold start overhead. When an environment is reused, the state of the `/tmp` directory is maintained. If a function writes files to `/tmp` and does not clean them up, subsequent invocations in the same environment will find those files still present, leading to cumulative disk usage and eventual disk exhaustion.

Adım Adım Çözüm

Analyze the error message and context.

The `No space left on device` error indicates that the local disk storage under `/tmp` is fully exhausted, despite the current invocation's files being well below the

512\text{ MB}

limit.

This discrepancy suggests that storage space is leaking across separate execution events, pointing to a persistent state issue in the Lambda runtime environment.

Evaluate the behavior of Lambda ephemeral storage during execution context reuse.

AWS Lambda reuses execution environments for subsequent invocations (warm starts) to improve response times. Files stored in `/tmp` are preserved during this reuse.

Since the function download logic writes files but does not delete them, these files accumulate over successive invocations in a reused execution context until the disk space is depleted.

Determine the appropriate correction method.

Implement cleanup logic in the Lambda handler code to delete the files from `/tmp` right before the handler returns or finishes processing.

Explicitly deleting files ensures that each invocation starts or ends with a clean `/tmp` directory, preventing cumulative disk usage across reused execution environments.

Anahtar Kavram

AWS Lambda reuses its execution context (including the `/tmp` directory) across sequential invocations (warm starts). Developers must explicitly clean up any ephemeral storage files to prevent disk exhaustion over time.

Soru 1065Soru →

A client-side single-page dashboard application hosted on `https://internal-app.net` sends a `DELETE` request to a backend API. The API is hosted on Amazon API Gateway and integrated with a backend AWS Lambda function using a Lambda proxy integration. During testing, the browser console shows that the `DELETE` request is blocked due to a missing CORS header during the preflight check. Furthermore, direct invocations of the endpoint using a command-line tool result in a `502 Bad Gateway` error with the message 'Malformatted Lambda proxy response' in the CloudWatch logs. Which two actions must the developer take to resolve both the CORS preflight block and the integration error?

Geçerli olan tümünü seçin

Enable CORS on the API Gateway resource to create an OPTIONS method that returns the required Access-Control-Allow-Methods and Access-Control-Allow-Origin headers.

Modify the backend Lambda function's return payload to be a JSON object containing the statusCode integer, a headers object with the Access-Control-Allow-Origin header, and a stringified body.

Add the Access-Control-Allow-Origin header to the CORS configuration of the Amazon S3 bucket where the frontend dashboard application is hosted.

Configure an Integration Response mapping template in API Gateway to transform the Lambda function's raw output string into a structured JSON response.

Configure a Lambda authorizer on the API Gateway method to validate the Origin header and return an IAM policy allowing the execute-api:Invoke action.

Cevabı ve açıklamayı göster

Cevap: Enable CORS on the API Gateway resource to create an OPTIONS method that returns the required Access-Control-Allow-Methods and Access-Control-Allow-Origin headers.; Modify the backend Lambda function's return payload to be a JSON object containing the statusCode integer, a headers object with the Access-Control-Allow-Origin header, and a stringified body.

Cevap

Enable CORS on the API Gateway resource to create an OPTIONS method that returns the required Access-Control-Allow-Methods and Access-Control-Allow-Origin headers, and modify the backend Lambda function's return payload to be a JSON object containing the statusCode integer, a headers object with the Access-Control-Allow-Origin header, and a stringified body.

The correct options resolve both issues: first, enabling CORS on the API Gateway resource creates the OPTIONS method to handle the browser's preflight request; second, formatting the Lambda response as a JSON object with statusCode, headers (including the CORS header), and body complies with Lambda proxy integration rules and resolves the 502 Bad Gateway error.

Adım Adım Çözüm

Configure preflight handling by enabling CORS on the API Gateway resource.

An OPTIONS method is created that returns the Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Origin headers, satisfying the browser's preflight check.

Before sending a non-simple request like DELETE, the browser initiates a preflight OPTIONS request to verify CORS permissions.

Ensure the Lambda function returns a valid proxy integration JSON payload.

The Lambda function returns a response object with statusCode, headers (including Access-Control-Allow-Origin), and body.

In a Lambda proxy integration, API Gateway expects a specific JSON format. Returning a raw string causes a 502 Bad Gateway error. Additionally, proxy integrations require the backend function to return the CORS headers for the actual request.

Anahtar Kavram

API Gateway Lambda proxy integrations require both a preflight OPTIONS method configured at the API Gateway level and a properly formatted JSON response containing the status code, headers (including CORS headers), and body returned directly from the Lambda function.

Tahmini Süre:2m 0s

Soru 1066Soru →

An order processing service runs on AWS Lambda. To comply with security guidelines, this function is attached to private subnets within a VPC to query an Amazon Aurora database. As part of its execution, the function must also call an external payment gateway API over the internet. Although the database queries succeed, all external API calls timeout. What configuration change is required to allow the function to connect to the external API?

Relocate the Lambda function configuration from the private subnets to the public subnets of the VPC to grant it a public IP address.

Create a NAT gateway in a public subnet of the VPC and configure a route for outbound internet traffic in the private subnet's route table.

Extend the execution timeout of the Lambda function to allow more time for the external API requests to complete.

Update the Lambda function's IAM execution role trust policy to allow the VPC endpoints to assume the role.

Cevabı ve açıklamayı göster

Cevap: Create a NAT gateway in a public subnet of the VPC and configure a route for outbound internet traffic in the private subnet's route table.

Cevap

Create a NAT gateway in a public subnet of the VPC and configure a route for outbound internet traffic in the private subnet's route table.

The correct action is to create a NAT gateway in a public subnet and configure a route in the private subnet's route table. When a Lambda function is configured to run inside a VPC, it does not have direct internet access. To access an external API, outbound internet traffic must be routed through a NAT gateway located in a public subnet.

Adım Adım Çözüm

Analyze the networking configuration of the Lambda function.

The Lambda function is running in private subnets of a VPC, allowing it to connect to the internal database but blocking direct internet access.

By default, a Lambda function inside a VPC has no internet access.

Identify the destination of the failed network request.

The function is attempting to reach an external payment gateway API over the public internet.

Knowing the target is internet-based determines whether we need internet routing (NAT gateway) or a VPC endpoint.

Select the correct AWS network component to bridge the private VPC subnets to the public internet.

A NAT gateway placed in a public subnet with appropriate route table entries allows the private subnets to reach the internet.

This establishes outbound-only internet connectivity for resources in private subnets.

Anahtar Kavram

VPC Networking for AWS Lambda

Soru 1067Soru →

A developer deployed an Amazon EC2 instance and an associated security group using an AWS CloudFormation stack. During a troubleshooting session, the developer manually added a new ingress rule to the security group using the AWS Management Console. The developer now wants to synchronize the CloudFormation stack with these changes to ensure future stack updates do not overwrite or fail due to this modification. Which action should the developer take to resolve this discrepancy?

Run drift detection on the stack to identify the modifications, update the CloudFormation template to include the new ingress rule, and then perform a stack update.

Perform a stack update using the original template, expecting AWS CloudFormation to automatically detect the manual configuration and merge it into the stack state.

Store the modified security group rules in AWS Systems Manager Parameter Store, and reference them via a dynamic reference in the template to bypass future drift detection.

Trigger a stack rollback operation to force the CloudFormation stack to import the manual out-of-band changes into its current state.

Cevabı ve açıklamayı göster

Cevap: Run drift detection on the stack to identify the modifications, update the CloudFormation template to include the new ingress rule, and then perform a stack update.

Cevap

Run drift detection on the stack to identify the modifications, update the CloudFormation template to include the new ingress rule, and then perform a stack update.

The correct action is to first identify the drift using the drift detection feature of CloudFormation. Once the drift details are known, the developer must update the template to include the manual modifications and run a stack update. This synchronizes the template definition with the actual resource state without interrupting the service or overwriting the rule.

Adım Adım Çözüm

Detect drift

Detailed drift status showing that the security group resource has drifted from its template definition due to the manually added ingress rule.

Before making changes, the exact differences between the template and the live resources must be identified.

Modify template

The CloudFormation template now contains the new ingress rule in the security group resource definition.

To resolve drift, the template must be updated to align with the desired live state of the resources.

Perform stack update

The stack state is updated, and the resource is marked as in-sync.

Running the stack update applying the updated template reconciles the template state with the physical resource state.

Anahtar Kavram

CloudFormation Drift Detection and Reconciliation

Tahmini Süre:1m 30s

Soru 1068Soru →

A developer has updated an API hosted on Amazon API Gateway. To minimize the risk of the new version affecting users, the developer wants to test the update by routing $5\%$ of the incoming API calls to the new version, while the remaining $95\%$ of the traffic goes to the current version. The developer wants to monitor the performance of the new version using CloudWatch and easily promote it to full production once verified. Which approach meets these requirements with the least operational complexity?

Configure a canary release on the existing API Gateway stage, set the canary traffic percentage to

5\%

, and promote the canary after verification.

Deploy the new API version to a new stage, and configure an AWS Lambda function with alias routing to split the traffic between the stages.

Deploy the new API version to a new stage, and configure Amazon Route 53 weighted routing to distribute the traffic between the two stage endpoints.

Create a second API Gateway API, deploy it, and place both APIs behind an Application Load Balancer with weighted target groups.

Cevabı ve açıklamayı göster

Cevap: Configure a canary release on the existing API Gateway stage, set the canary traffic percentage to $5\%$ , and promote the canary after verification.

Cevap

Configure a canary release on the existing API Gateway stage, set the canary traffic percentage to

5\%

, and promote the canary after verification.

The correct answer is to configure a canary release on the existing API Gateway stage. When a canary release is enabled, API Gateway automatically routes a specified percentage of API traffic (in this case,

5\%

) to the new deployment. The developer can monitor the performance of this canary using Amazon CloudWatch metrics and easily promote it to the production release once verified, which requires the least operational effort.

Adım Adım Çözüm

Identify the deployment target service and the primary goal.

The target is Amazon API Gateway, and the goal is to shift

5\%

of traffic to a new version of the API and monitor performance.

Understanding the service context helps isolate native features from external workarounds.

Evaluate the native deployment features of Amazon API Gateway.

Amazon API Gateway natively supports canary releases directly on an existing deployment stage.

This features allows splitting traffic at the HTTP request level and integrating directly with CloudWatch for testing.

Analyze and eliminate alternative architectures based on complexity.

Route 53 weighted routing requires custom domains; Lambda alias routing operates at the backend layer rather than the API stage layer; ALB target groups are structurally redundant and complex.

This confirms that API Gateway canary release is the path of least operational complexity.

Anahtar Kavram

API Gateway Canary Deployments

Tahmini Süre:1m 30s

Soru 1069Soru →

A developer is troubleshooting an AWS Lambda function written in Python that is triggered by an Amazon API Gateway REST API. When a client sends a request, the function queries Amazon DynamoDB and then queries an external PostgreSQL database. The developer has enabled active tracing on the Lambda function. Although the API Gateway and Lambda service execution segments appear in the AWS X-Ray service map, downstream calls to DynamoDB and the PostgreSQL database are completely missing. Which two actions must the developer take to capture these downstream calls in the X-Ray trace?

Geçerli olan tümünü seçin

Call patch_all() from the aws_xray_sdk.core module at application startup to automatically instrument downstream calls made via the boto3 library.

Wrap the PostgreSQL database connection library using the AWS X-Ray SDK's patch function or database wrappers to instrument SQL queries.

Initialize the AWS SDK clients by hardcoding an AWS IAM access key and secret access key that have the xray:PutTraceSegments permission.

Increase the execution timeout of the Lambda function to allow the X-Ray daemon helper thread to flush traces before the runtime container freezes.

Configure API Gateway to use a custom Lambda integration instead of a Lambda proxy integration to ensure that the trace header is parsed and passed in the JSON payload.

Cevabı ve açıklamayı göster

Cevap: Call patch_all() from the aws_xray_sdk.core module at application startup to automatically instrument downstream calls made via the boto3 library.; Wrap the PostgreSQL database connection library using the AWS X-Ray SDK's patch function or database wrappers to instrument SQL queries.

Cevap

To capture downstream AWS SDK and database calls in AWS X-Ray, the developer must call patch_all() to instrument boto3 and wrap the database connection library with the X-Ray SDK's database wrappers.

To trace downstream dependencies with AWS X-Ray in a Python Lambda function, active tracing must be paired with application-level SDK instrumentation. Calling the patch_all function from the X-Ray SDK dynamically patches boto3, enabling tracing for all AWS SDK calls (like DynamoDB). To trace external database queries, the database client library must also be wrapped or patched by the X-Ray SDK.

Adım Adım Çözüm

Patch the AWS SDK client.

The boto3 library is patched with the X-Ray SDK.

This allows X-Ray to intercept all downstream AWS service requests (such as DynamoDB calls) and create subsegments automatically.

Patch the third-party database library.

The SQL driver is wrapped with X-Ray instrumentation.

This captures SQL database queries as subsegments and visualizes them on the X-Ray service map.

Anahtar Kavram

AWS X-Ray SDK instrumentation for downstream dependencies

Soru 1070Soru →

A developer has a distributed application where a producer service running on Amazon ECS Fargate sends tasks to an Amazon SQS queue. A consumer service, also running on Amazon ECS Fargate, polls the queue and processes the tasks. Both services use the AWS SDK and are configured with the AWS X-Ray SDK, with active tracing enabled where applicable and the AWS SDK clients properly patched.

When viewing the traces in the AWS X-Ray console, the developer observes two disconnected traces: one for the producer service sending the message, and another separate trace for the consumer service processing the task. The end-to-end transaction is not correlated.

Which action should the developer take to resolve this issue and trace the request end-to-end?

Enable active tracing on the Amazon SQS queue configuration via the AWS Management Console to allow the queue to act as a segment coordinator.

Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.

Increase the visibility timeout of the Amazon SQS queue to ensure that the consumer service has enough time to write trace segments to the AWS X-Ray daemon before the message returns to the queue.

Configure the AWS X-Ray SDK on the consumer service using hardcoded AWS IAM credentials with xray:PutTraceSegments permissions in the application source code to authorize the segment creation.

Cevabı ve açıklamayı göster

Cevap: Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.

Cevap

Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.

The correct answer is to modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context. When using a self-managed worker (such as on ECS Fargate or EC2) to process SQS messages, the SDK does not automatically extract the tracing header. The developer must manually parse the AWSTraceHeader system attribute and initialize the segment context with it, which links the consumer's trace to the producer's trace.

Adım Adım Çözüm

Identify the boundary where tracing context is lost.

The boundary is the Amazon SQS queue, where the producer sends a message and the consumer on ECS Fargate retrieves it. The trace splits into two disconnected traces.

Since the consumer is running on ECS Fargate (rather than AWS Lambda, which automatically handles SQS trace context propagation), the X-Ray SDK on the consumer does not automatically know how to link the processing logic to the incoming message's trace context.

Locate where the tracing header is transmitted within Amazon SQS.

The AWS SDK automatically injects the AWSTraceHeader into the message's system attributes when the producer sends the message.

This header contains the trace ID, parent segment ID, and sampling decision.

Extract the trace header and initialize the segment in the consumer service code.

The consumer reads the AWSTraceHeader from the SQS message attributes and initializes a new segment (or subsegment) with this header as the parent context.

By explicitly setting the parent context using the extracted trace header, the X-Ray SDK links the consumer's execution to the producer's trace, restoring end-to-end correlation.

Anahtar Kavram

Manual trace context propagation across asynchronous boundaries with non-Lambda consumers

Soru 1071Soru →

A developer has built a serverless application where an AWS Lambda function, written in Python, processes payment reports. The Lambda function is configured to run inside a VPC, attached to two private subnets, to securely access a private Amazon RDS PostgreSQL database.

As part of the processing logic, the Lambda function must perform the following actions:
1. Connect to the RDS database to fetch payment transactions.
2. Query a public external credit rating API via HTTPS to validate client records.
3. Download a standard currency conversion schema from a public Amazon S3 bucket.

During testing, the Lambda function consistently runs for its maximum configured timeout of $3$ seconds and then terminates with a `Task timed out after 3.00 seconds` error. The Amazon CloudWatch logs indicate that the connection to the RDS database is established successfully, but the connections to both the external credit rating API and Amazon S3 fail to connect.

Which combination of actions should the developer take to resolve these connectivity and execution timeout issues? (Select TWO.)

Geçerli olan tümünü seçin

Deploy a NAT Gateway in a public subnet of the VPC, and update the private subnets' route tables to direct internet-bound traffic (

0.0.0.0/0

) to the NAT Gateway.

Increase the Lambda function's timeout configuration to a value greater than

3

seconds (such as

15

seconds) to accommodate network transit and API latency.

Relocate the Lambda function to the public subnets of the VPC and enable the auto-assign public IP option on those subnets to establish direct internet access.

Create an Internet Gateway and associate it directly with the private subnets' route tables to provide an outbound pathway for the Lambda function.

Configure the Lambda function to tear down and recreate the database connection pool at the end of each handler execution to clear the cached execution context.

Cevabı ve açıklamayı göster

Cevap: Deploy a NAT Gateway in a public subnet of the VPC, and update the private subnets' route tables to direct internet-bound traffic ( $0.0.0.0/0$ ) to the NAT Gateway.; Increase the Lambda function's timeout configuration to a value greater than $3$ seconds (such as $15$ seconds) to accommodate network transit and API latency.

Cevap

Deploy a NAT Gateway in a public subnet of the VPC and update the private subnets' route tables to route internet traffic to it, and increase the Lambda function's timeout configuration to a value greater than

3

seconds.

The correct answers describe deploying a NAT Gateway in a public subnet to allow the private-subnet Lambda function to reach the public internet (for S3 and the external API), and increasing the function's timeout configuration to accommodate the network transit time and database operations. These two adjustments work together to resolve both the networking bottleneck and the execution duration limitation.

Adım Adım Çözüm

Diagnose the routing issue by reviewing subnets and endpoints.

The Lambda function is running in private VPC subnets with no route to the internet, causing external HTTP/HTTPS calls to time out.

VPC-enabled Lambda functions require a NAT Gateway (or VPC Endpoints) to reach endpoints outside the VPC.

Establish outbound connectivity for public endpoints.

Deploy a NAT Gateway in a public subnet and route traffic destined for

0.0.0.0/0

from the private subnets to the NAT Gateway.

This configuration allows the Lambda function to securely reach both the external API and the public S3 bucket.

Adjust the execution configuration of the Lambda function.

Increase the timeout configuration from

3

seconds to a higher limit (e.g.,

15

seconds).

The execution environment needs sufficient time to establish connections, query the database, and receive external API responses without timing out prematurely.

Anahtar Kavram

VPC networking configurations and execution environment settings for AWS Lambda functions

Soru 1072Soru →

A developer is implementing client-side decryption in an application. The application receives a data package containing a $5\text{ MB}$ ciphertext payload and an encrypted data key that was originally generated using an AWS KMS customer managed key. The application has the necessary IAM permissions to access the customer managed key.

Which sequence of steps must the developer perform in the application code to decrypt the payload?

Call the KMS GenerateDataKey API using the customer managed key to obtain the plaintext data key, decrypt the payload locally using this key, and then discard the new encrypted data key.

Submit the entire ciphertext payload directly to the KMS Decrypt API, allowing AWS KMS to automatically locate the customer managed key, decrypt the payload, and return the plaintext data.

Send the encrypted data key to the KMS Decrypt API to retrieve the plaintext data key, decrypt the ciphertext payload locally using the plaintext data key, and then delete the plaintext data key from memory.

Retrieve the plaintext data key from Systems Manager Parameter Store using the GetParameter API with the customer managed key's ARN, decrypt the payload locally, and store the decrypted data back in Parameter Store as a SecureString.

Cevabı ve açıklamayı göster

Cevap: Send the encrypted data key to the KMS Decrypt API to retrieve the plaintext data key, decrypt the ciphertext payload locally using the plaintext data key, and then delete the plaintext data key from memory.

Cevap

The correct sequence is to send the encrypted data key to the KMS Decrypt API to retrieve the plaintext data key, decrypt the ciphertext payload locally using the plaintext data key, and then delete the plaintext data key from memory.

The correct sequence matches the standard client-side envelope decryption workflow. The application sends the encrypted data key (which is small enough to fit within KMS API limits) to the KMS Decrypt API. KMS uses the customer managed key to decrypt it and returns the plaintext data key. The application then performs local decryption on the

5\text{ MB}

payload and safely removes the plaintext key from memory.

Adım Adım Çözüm

Send the encrypted data key to the AWS KMS Decrypt API.

The API returns the plaintext data key.

To perform client-side decryption, the application first needs the raw plaintext data key.

Decrypt the ciphertext payload locally using the retrieved plaintext data key.

The

5\text{ MB}

payload is decrypted into its original plaintext format.

Because KMS has a

4\text{ KB}

API limit, decryption must be handled locally by the application using cryptographic libraries.

Delete the plaintext data key from the application memory.

The plaintext data key is removed from memory.

Leaving the plaintext key in memory exposes it to potential security risks.

Anahtar Kavram

AWS KMS Envelope Decryption

Soru 1073Soru →

A developer has deployed an AWS Lambda function named `DataProcessor` in Account A ( $111111111111$ ) and configured a Function URL with the authorization type set to `AWS_IAM`. An IAM role named `AppRole` in Account B ( $222222222222$ ) needs to invoke this function by sending HTTP requests directly to the Function URL. Which combination of configuration steps will successfully and securely grant `AppRole` the necessary permissions to invoke the Function URL?

Add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunction` permissions to `AppRole`, and attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunction` on the function ARN in Account A.

Attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunctionUrl` with the Resource element set to the function's HTTP URL, and add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunctionUrl` to Account B.

Add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunctionUrl` permissions to the Principal `arn:aws:iam::222222222222:role/AppRole`, and attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunctionUrl` on the function ARN in Account A.

Modify the trust policy of `AppRole` in Account B to trust the AWS Lambda service principal (`lambda.amazonaws.com`), and attach an identity-based policy to `AppRole` allowing `sts:AssumeRole` on the Lambda function ARN in Account A.

Cevabı ve açıklamayı göster

Cevap: Add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunctionUrl` permissions to the Principal `arn:aws:iam::222222222222:role/AppRole`, and attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunctionUrl` on the function ARN in Account A.

Cevap

The correct configuration uses the specific `lambda:InvokeFunctionUrl` action, which is required for Lambda Function URLs. Because the access is cross-account, both the resource-based policy in Account A (which must list the external role ARN as the principal) and the identity-based policy in Account B (which must allow the action on the function ARN) are required.

Adım Adım Çözüm

Identify the correct IAM action required for Function URL invocations.

The action is `lambda:InvokeFunctionUrl` rather than `lambda:InvokeFunction`.

AWS separates standard API-based invocations (`lambda:InvokeFunction`) from HTTP-based Function URL invocations (`lambda:InvokeFunctionUrl`).

Configure permissions for cross-account access.

Permissions must be configured on both the target resource (resource-based policy) and the calling identity (identity-based policy).

For cross-account access, trust must be established bidirectionally: the hosting account must allow the external entity, and the external entity must allow its identity to perform the action on the destination resource.

Verify resource identifier compliance in the policy syntax.

The Resource block must reference the Lambda function ARN, not the HTTP URL endpoint.

IAM Resource elements do not support HTTP URLs; they only accept valid AWS Amazon Resource Names (ARNs).

Anahtar Kavram

Cross-account IAM authorization for AWS Lambda Function URLs

Tahmini Süre:2m 0s

Soru 1074Soru →

An organization runs a containerized data processing application on an Amazon ECS cluster using the EC2 launch type. The application uses the AWS SDK to interact with an Amazon DynamoDB table. During a security audit, the security team notices that the application is accessing DynamoDB using the credentials of the container host's EC2 instance profile role, rather than the more restrictive IAM role designed specifically for the ECS task. Which configuration issue explains why the application is using the EC2 instance profile credentials?

The DynamoDB access permissions were attached to the ECS Task Execution Role instead of the ECS Task Role.

The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.

The AWS SDK inside the application code is configured to bypass the ECS task metadata endpoint and directly query the EC2 instance metadata service (IMDS) at 169.254.169.254.

The task definition container definition is missing a secrets parameter mapping the EC2 instance profile role to an environment variable in the container.

Cevabı ve açıklamayı göster

Cevap: The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.

Cevap

The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.

The correct answer is that the trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal. When a containerized application uses the AWS SDK, the default credential provider chain searches for task credentials injected by the ECS agent. If the task role's trust relationship is misconfigured to trust EC2 instead of ECS, the ECS agent cannot assume the role, leaving the container credential URI unconfigured. Consequently, the AWS SDK's default credential provider chain falls back to checking the host EC2 instance's metadata endpoint (IMDS) for credentials, which succeeds but uses the host's broader permissions instead of the task-specific permissions.

Adım Adım Çözüm

Determine how the AWS SDK resolves credentials inside an ECS container.

The SDK checks the AWS default credential chain, which queries the ECS task metadata endpoint (via the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable) before falling back to the EC2 Instance Metadata Service (IMDS).

Understanding the credential resolution hierarchy is key to diagnosing why the SDK defaulted to the host's EC2 instance profile credentials.

Analyze why the task-specific credentials were not provided to the container.

The ECS container agent could not retrieve temporary credentials for the task because the IAM role assigned to the task did not permit the ECS tasks service principal (ecs-tasks.amazonaws.com) to assume it.

This identifies why the container credentials relative URI remained empty or was not resolved, prompting the SDK fallback behavior.

Identify the misconfiguration in the trust policy.

The IAM role's trust policy allowed the EC2 service principal (ec2.amazonaws.com) instead of the ECS tasks service principal (ecs-tasks.amazonaws.com) to assume the role.

This is a common configuration error where developers confuse the hosting environment (EC2) with the service executing the tasks (ECS).

Anahtar Kavram

ECS Task IAM Roles and Service Trust Policies

Soru 1075Soru →

A developer is using AWS CloudFormation to deploy a web application. The template requires a database password that must be retrieved securely without being hardcoded or exposed in plaintext. During the deployment testing phase, the developer also needs to ensure that if any resource fails to create or update, the stack does not automatically revert its changes, allowing the developer to investigate the failed resource state.

Which two actions should the developer take to meet these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Reference the database password in the template using the dynamic reference pattern for AWS Secrets Manager.

Specify the --disable-rollback parameter when executing the create-stack or update-stack command via the AWS CLI.

Reference the database password in the template using the dynamic reference pattern for a Systems Manager Parameter Store parameter of type String.

Manually delete the failed resource via the AWS Management Console and run drift detection to trigger CloudFormation to automatically recreate the resource.

Store the database password in Systems Manager Parameter Store using a standard String parameter type to optimize cost, and import it as a template parameter.

Cevabı ve açıklamayı göster

Cevap: Reference the database password in the template using the dynamic reference pattern for AWS Secrets Manager.; Specify the --disable-rollback parameter when executing the create-stack or update-stack command via the AWS CLI.

Cevap

Reference the database password using the AWS Secrets Manager dynamic reference pattern, and specify the --disable-rollback parameter when executing the create-stack or update-stack command via the AWS CLI.

The correct options are referencing the database password using the dynamic reference pattern for AWS Secrets Manager and specifying the --disable-rollback parameter when executing the create-stack or update-stack command. AWS Secrets Manager dynamic references securely fetch credentials at deployment time without exposing them. The --disable-rollback parameter prevents the stack from automatically reverting on failure, preserving the resource state for troubleshooting.

Adım Adım Çözüm

Secure the database password by storing it in AWS Secrets Manager.

The password is encrypted and managed centrally, avoiding hardcoding.

AWS Secrets Manager is designed for storing sensitive secrets and credentials.

Update the CloudFormation template to reference the secret using the dynamic reference syntax: resolve:secretsmanager:secret-id.

CloudFormation retrieves the password dynamically at runtime during stack operations.

This prevents sensitive data from being recorded in the template or stack history.

Execute the stack creation or update command with the --disable-rollback CLI option.

If a deployment failure occurs, the stack remains in a failed state rather than rolling back.

This allows the developer to inspect the state and logs of the failed resources directly.

Anahtar Kavram

AWS CloudFormation secure parameter resolution and deployment troubleshooting

Soru 1076Soru →

A software developer is building a SaaS dashboard application that runs on an Amazon ECS cluster. The application displays financial exchange rates retrieved from a third-party API. The exchange rates are updated exactly once every hour. To minimize third-party API usage fees and improve application response times, the developer wants to implement a shared caching solution that automatically invalidates stale data after 1 hour. Which solution meets these requirements with the lowest latency?

Deploy an Amazon ElastiCache for Redis cluster. Implement a cache-aside (lazy-loading) pattern in the application code, and set a Time to Live (TTL) of 3600 seconds on the cached keys.

Store the exchange rates in AWS Systems Manager Parameter Store. Configure the application to retrieve the parameters on every request, relying on Parameter Store's API integration for high-throughput caching.

Save the exchange rates in an Amazon DynamoDB table. Configure the ECS tasks to run a Scan operation on the table for every user request, relying on DynamoDB's provisioned throughput to serve the cached data.

Write the rates to a local file on a shared Amazon EBS volume. Configure the ECS Task Execution Role to automatically synchronize the file contents across all running container tasks.

Cevabı ve açıklamayı göster

Cevap: Deploy an Amazon ElastiCache for Redis cluster. Implement a cache-aside (lazy-loading) pattern in the application code, and set a Time to Live (TTL) of 3600 seconds on the cached keys.

Cevap

Deploy an Amazon ElastiCache for Redis cluster. Implement a cache-aside (lazy-loading) pattern in the application code, and set a Time to Live (TTL) of 3600 seconds on the cached keys.

The correct solution uses Amazon ElastiCache for Redis to store the exchange rates. The cache-aside (lazy-loading) pattern checks the cache first, loads from the third-party API only on a cache miss, and writes the retrieved rate back to the cache. Setting a Time to Live (TTL) of 3600 seconds ensures that the cache automatically invalidates its data after one hour, prompting a refresh when the next request occurs. This approach ensures sub-millisecond response times and minimizes third-party API costs.

Adım Adım Çözüm

Identify the caching requirements: shared cache across multiple ECS container instances, automatic expiration after 1 hour (3600 seconds), and low-latency retrieval.

Requires a central, high-performance in-memory key-value store with TTL support.

Since the ECS tasks are distributed, local memory caches would become inconsistent, and direct third-party API calls must be minimized.

Evaluate Amazon ElastiCache for Redis as the central cache store with a cache-aside strategy.

ElastiCache provides sub-millisecond latency. A TTL of 3600 seconds ensures that keys automatically expire 1 hour after they are written, prompting the application to fetch fresh data on the next request.

This directly satisfies the invalidation requirement and ensures that the third-party API is only called once per hour per rate key.

Rule out alternative options that use improper AWS services or anti-patterns.

Parameter Store is for configuration/secrets; DynamoDB Scan is inefficient for high-read caching; ECS Task Execution Role cannot synchronize local EBS file storage.

These alternatives violate AWS best practices for application caching and performance optimization.

Anahtar Kavram

Using Amazon ElastiCache with a cache-aside pattern and TTL configuration is the standard architectural pattern for low-latency, shared application caching in AWS.

Tahmini Süre:1m 30s

Soru 1077Soru →

A developer is deploying a Node.js application to Amazon ECS on AWS Fargate. The developer wants to instrument the application to send distributed tracing data to AWS X-Ray. The developer includes the AWS X-Ray SDK in the application code and configures the SDK to instrument incoming HTTP requests. However, after deployment, no traces appear in the AWS X-Ray console, and the application logs show errors indicating that connection to the X-Ray daemon on port 2000 failed. Which of the following actions should the developer take to resolve this issue and enable successful tracing?

Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task role.

Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task execution role.

Initialize the AWS SDK clients within the Node.js application by passing hardcoded IAM credentials containing the AWSXRayDaemonWriteAccess policy directly into the constructors.

Set the AWS_XRAY_CONTEXT_MISSING environment variable to IGNORE_ERROR to allow the SDK to function without a running X-Ray daemon.

Cevabı ve açıklamayı göster

Cevap: Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task role.

Cevap

Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task role.

To instrument an application running on Amazon ECS with Fargate, the AWS X-Ray daemon must be run as a sidecar container in the same task definition. Because Fargate tasks use the awsvpc network mode, the application container can communicate with the daemon container over localhost (127.0.0.1) on UDP port 2000. Additionally, the ECS Task Role must have the necessary permissions (such as AWSXRayDaemonWriteAccess) to allow the daemon to upload segment data to the AWS X-Ray service. The Task Role defines permissions for the containers running inside the task.

Adım Adım Çözüm

Analyze application logs showing connection failure to the X-Ray daemon on port 2000.

Identify that the X-Ray daemon is either not running or is unreachable by the application container.

On ECS Fargate, applications communicate with the X-Ray daemon over UDP localhost (127.0.0.1:2000), which requires the daemon to be running inside the same task.

Configure the X-Ray daemon as a sidecar container in the ECS task definition.

The daemon starts inside the same network namespace, making port 2000 reachable by the application container over localhost.

This establishes local UDP network connectivity between the application's X-Ray SDK client and the X-Ray daemon.

Attach the AWSXRayDaemonWriteAccess managed policy to the ECS Task Role.

The X-Ray daemon has permissions to send trace segments to the AWS X-Ray service endpoint at runtime.

The Task Role provides credentials to the running containers, unlike the Task Execution Role, which is only used by the ECS agent for pulling images and publishing startup logs.

Anahtar Kavram

Instrumenting Distributed Tracing with AWS X-Ray on Amazon ECS

Soru 1078Soru →

A developer is maintaining an application stack deployed via AWS CloudFormation. A recent stack update failed because a Security Group managed by the stack was manually deleted via the Amazon EC2 console, causing the stack rollback to fail. The stack is currently stuck in the UPDATE_ROLLBACK_FAILED state. The developer needs to return the stack to a stable state so they can apply a new template. Which two actions must the developer perform to resolve this issue? (Select TWO.)

Geçerli olan tümünü seçin

Invoke the ContinueUpdateRollback operation from the AWS CloudFormation console or CLI.

Recreate the manually deleted Security Group with the exact same physical name, or specify the resource to be skipped in the ResourcesToSkip parameter during the rollback continuation.

Initiate a new stack update directly using the UpdateStack API with the --disable-rollback parameter enabled.

Run drift detection on the stack and select the 'Auto-Reconcile' option to let CloudFormation automatically recreate the missing Security Group.

Retrieve the Security Group's configuration parameters from AWS Systems Manager Parameter Store using a dynamic reference to force-refresh the template state.

Cevabı ve açıklamayı göster

Cevap: Invoke the ContinueUpdateRollback operation from the AWS CloudFormation console or CLI.; Recreate the manually deleted Security Group with the exact same physical name, or specify the resource to be skipped in the ResourcesToSkip parameter during the rollback continuation.

Cevap

To resolve the UPDATE_ROLLBACK_FAILED state, the developer must continue the rollback using the ContinueUpdateRollback operation and either recreate the manually deleted Security Group or specify it as a resource to skip during rollback.

To resolve the UPDATE_ROLLBACK_FAILED state, the developer must continue the rollback using the ContinueUpdateRollback operation. Because the failure was caused by a manually deleted resource (the Security Group), the rollback cannot proceed unless the developer either recreates the resource with the exact same physical ID/name so the rollback process can delete or modify it, or explicitly skips the resource using the ResourcesToSkip parameter.

Adım Adım Çözüm

Analyze the cause of the rollback failure

Identify that the rollback failed because a Security Group managed by the stack was deleted out-of-band.

CloudFormation attempts to clean up or modify the Security Group during rollback, but cannot find it, causing the rollback to fail.

Perform remedial action on the deleted resource

Either recreate the Security Group manually with the exact configuration and physical name, or prepare to skip it during rollback.

This satisfies CloudFormation's expectation of the resource's existence or instructs CloudFormation to ignore it, allowing the rollback to proceed.

Trigger ContinueUpdateRollback

Run the continue-update-rollback CLI command (or use the console) specifying the ResourcesToSkip if skipping.

This transitions the stack from UPDATE_ROLLBACK_FAILED back to a stable UPDATE_ROLLBACK_COMPLETE state, enabling future updates.

Anahtar Kavram

Resolving UPDATE_ROLLBACK_FAILED state in AWS CloudFormation

Soru 1079Soru →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline has a deploy stage that deploys a serverless API, followed by an integration test stage that runs an AWS Lambda function. The Lambda function must retrieve a database password that requires automatic rotation every 30 days. Additionally, the Lambda function needs permissions to execute and log to Amazon CloudWatch.

Which two configurations should the developer implement to satisfy these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Store the database password in AWS Secrets Manager and configure automatic rotation.

Store the database password in AWS Systems Manager Parameter Store as a SecureString parameter and enable automatic rotation.

Configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.

Configure the Lambda function's IAM execution role with a trust policy that allows the codepipeline.amazonaws.com service principal to assume the role.

Pass the database password to the Lambda function as a plaintext environment variable in the CodePipeline deploy action configuration.

Cevabı ve açıklamayı göster

Cevap: Store the database password in AWS Secrets Manager and configure automatic rotation.; Configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.

Cevap

Store the database password in AWS Secrets Manager and configure automatic rotation, and configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.

Storing the password in AWS Secrets Manager satisfies the requirement for automatic 30-day rotation, as Secrets Manager natively handles automatic rotation via integrated Lambda templates. Additionally, configuring the Lambda function's execution role with a trust policy that allows lambda.amazonaws.com ensures the Lambda service can assume the role at runtime to perform its actions and write logs to CloudWatch.

Adım Adım Çözüm

Determine the appropriate secret storage service.

AWS Secrets Manager is chosen over Systems Manager Parameter Store.

Only Secrets Manager provides native support for automatic rotation of secrets.

Determine the trust relationship for the Lambda execution role.

The trust policy must allow lambda.amazonaws.com to assume the role.

AWS Lambda needs to assume the execution role at runtime to execute the function and perform actions like logging to CloudWatch.

Anahtar Kavram

AWS CodePipeline integration with AWS Lambda and secure credential management using AWS Secrets Manager.

Soru 1080Soru →

A developer is building a web application that stores user-specific files in a private Amazon S3 bucket. The application uses an Amazon Cognito User Pool for user authentication. The developer wants to authorize users to access their department's files in S3 using temporary AWS credentials. The user's department is stored in a custom attribute named custom:department in the User Pool. The developer has created a separate IAM role for each department. Which approach should the developer use to assign the correct IAM role to each user with the least operational overhead?

Create an Amazon Cognito Identity Pool and add the User Pool as an identity provider. Configure rules-based role mapping on the identity provider to match the custom:department claim in the ID token to the corresponding IAM role.

Configure the Amazon Cognito User Pool to issue temporary AWS credentials directly by mapping the custom:department attribute to the AWS STS AssumeRole API parameters in the User Pool app client settings.

Create an Amazon Cognito Identity Pool with a single authenticated role. Use the IAM policy variable ${cognito-identity.amazonaws.com:custom:department} in the role's permission policy to dynamically grant access to the department's S3 folder.

Configure an API Gateway REST API with a custom Lambda authorizer that validates the User Pool ID token and calls the AWS STS AssumeRole API to generate and return temporary credentials to the client.

Cevabı ve açıklamayı göster

Cevap: Create an Amazon Cognito Identity Pool and add the User Pool as an identity provider. Configure rules-based role mapping on the identity provider to match the custom:department claim in the ID token to the corresponding IAM role.

Cevap

Create an Amazon Cognito Identity Pool, add the User Pool as an identity provider, and configure rules-based role mapping on the identity provider to match the custom:department claim in the ID token to the corresponding IAM role.

The correct solution uses an Amazon Cognito Identity Pool to exchange the ID token from the User Pool for temporary AWS credentials. By configuring rules-based role mapping on the User Pool identity provider within the Identity Pool, the developer can inspect the custom:department claim present in the authenticated user's ID token and dynamically assign the corresponding department-specific IAM role. This requires zero custom code and leverages native AWS features, minimizing operational overhead.

Adım Adım Çözüm

Identify the separation of concerns between Amazon Cognito User Pools and Identity Pools.

Confirm that User Pools handle authentication (user sign-in and profile attributes) while Identity Pools handle authorization (exchanging tokens for temporary AWS credentials).

Since the client needs direct access to S3, temporary AWS credentials must be vended via an Identity Pool.

Determine how to map the custom attribute from the User Pool to the required IAM role.

Leverage the rules-based role mapping feature of Cognito Identity Pools.

Rules-based mapping allows evaluating the custom:department claim from the ID token and dynamically assigning one of the pre-created department-specific IAM roles.

Eliminate options that introduce unnecessary custom code or rely on unsupported policy variables.

Reject solutions involving custom Lambda authorizers on API Gateway or unsupported Cognito Identity Pool policy variables.

These alternatives increase operational complexity and fail to utilize the built-in, native integrations of Amazon Cognito.

Anahtar Kavram

Role mapping in Amazon Cognito Identity Pools based on Cognito User Pool ID token claims

ÖncekiSayfa 54 / 78Sonraki

Tüm alıştırma soruları

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

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