Troubleshooting and Optimization

271 soru

Tüm türler271 Çoktan seçmeli138 Çoklu seçim133

An order processing workflow runs on AWS Lambda and needs to interact with an Amazon RDS PostgreSQL database located inside a private subnet of a VPC. Additionally, the function must publish event messages to an external third-party shipping API. The Lambda function is configured with access to the same private subnets as the database. While database operations succeed, the outbound HTTP requests to the shipping API fail with connection timeout errors.

Which TWO network configuration steps will resolve the outbound connectivity issue to the shipping API?

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

Configure a NAT Gateway within a public subnet of the VPC.

Update the route table of the private subnets to route traffic destined for 0.0.0.0/0 to the NAT Gateway.

Attach an Internet Gateway directly to the private subnets and add a default route pointing to it.

Configure the Lambda function to use public subnets and enable public IP address allocation.

Increase the execution timeout and allocated memory of the Lambda function to prevent the shipping API connection from timing out.

Cevabı ve açıklamayı göster

Cevap: Configure a NAT Gateway within a public subnet of the VPC.; Update the route table of the private subnets to route traffic destined for 0.0.0.0/0 to the NAT Gateway.

Cevap

The correct actions are to configure a NAT Gateway within a public subnet of the VPC, and to update the route table of the private subnets to route traffic destined for 0.0.0.0/0 to that NAT Gateway.

When an AWS Lambda function is configured to run inside a VPC, it utilizes Hyperplane ENIs to connect to the designated subnets. If it is attached to private subnets to communicate with internal resources like databases, it does not have access to the public internet by default. To resolve this, a NAT Gateway must be provisioned in a public subnet (which has a route to an Internet Gateway), and the route table associated with the Lambda function's private subnets must direct all outbound traffic (0.0.0.0/0) to the NAT Gateway.

Adım Adım Çözüm

Analyze the network path for the Lambda function.

The Lambda function is running in private subnets to reach the database, meaning it lacks direct internet routing.

By default, Lambda functions associated with private subnets have no route to public endpoints unless configured with a gateway or translation instance.

Select the correct translation mechanism.

Deploying a NAT Gateway in a public subnet provides the necessary Network Address Translation for private resources.

A NAT Gateway maps private IP addresses to a public IP to facilitate outbound connections while shielding internal resources from unsolicited inbound traffic.

Configure the routing paths for outbound traffic.

Modify the route table associated with the private subnets where the Lambda function runs to forward 0.0.0.0/0 traffic to the NAT Gateway.

Resources in private subnets require an explicit route table entry pointing to the NAT Gateway to exit the VPC.

Anahtar Kavram

Lambda VPC Networking and Internet Access

Soru 162Soru →

A developer is migrating a backend REST API from a Lambda Custom Integration to a Lambda Proxy Integration in Amazon API Gateway. The client application is an iOS mobile app that sends a POST request to create user profiles. Previously, when the Lambda function encountered a validation error (such as a missing email address), it would throw an exception, and the developer mapped this exception to a 400 Bad Request HTTP status code using API Gateway Integration Responses. After switching the API method to use the Lambda Proxy Integration, the client application receives a 502 Bad Gateway error instead of the 400 Bad Request validation error, even though the Lambda function execution succeeds with the expected validation error logged. Which of the following modifications should the developer make to the Lambda function's code to resolve this issue and return the expected 400 Bad Request status code?

Configure an Integration Response in the API Gateway method execution console with a regular expression mapping to capture the thrown exception and map it to a 400 HTTP status code.

Modify the Lambda function to catch the validation error and return a JSON object containing a statusCode key set to 400 and a body key containing a serialized JSON string of the error details.

Add an Access-Control-Allow-Origin header to the API Gateway OPTIONS method configuration and configure the static web host's S3 bucket policy to allow external CORS requests.

Implement a custom Lambda Authorizer to validate the request payload and return an IAM policy with a context block containing the statusCode mapping of 400.

Cevabı ve açıklamayı göster

Cevap: Modify the Lambda function to catch the validation error and return a JSON object containing a statusCode key set to 400 and a body key containing a serialized JSON string of the error details.

Cevap

Modify the Lambda function to catch the validation error and return a JSON object containing a statusCode key set to 400 and a body key containing a serialized JSON string of the error details.

In a Lambda Proxy Integration, Amazon API Gateway expects the backend Lambda function to return a response in a specific JSON format containing statusCode (as an integer) and body (as a stringified JSON). If the Lambda function throws an unhandled exception or returns a structure that does not conform to this contract, API Gateway cannot parse the output and returns a 502 Bad Gateway error to the client. To properly return a client-side error like 400 Bad Request in a proxy integration, the function must catch the exception and return the correct JSON format directly.

Adım Adım Çözüm

Analyze the API Gateway integration type and the error returned.

The integration is Lambda Proxy Integration, and the client receives a 502 Bad Gateway error instead of the expected 400 Bad Request.

502 Bad Gateway errors in Lambda Proxy Integrations typically occur when the Lambda function's output does not conform to the expected format required by API Gateway.

Review the differences in error handling between Lambda Custom and Lambda Proxy integrations.

In Custom Integrations, API Gateway maps errors using Integration Responses. In Proxy Integrations, API Gateway relies entirely on the Lambda function returning a structured JSON response containing the status code and body.

To resolve the 502 error and return a 400 status code, the responsibility of mapping the error shifts from API Gateway configuration to the Lambda function code.

Formulate the correct Lambda function response payload.

The Lambda function must catch the validation exception and return an object with a statusCode of 400 and a serialized string body detailing the validation failure.

This satisfies the Lambda Proxy Integration response contract, allowing API Gateway to parse the payload and pass the 400 status code to the client.

Anahtar Kavram

API Gateway Lambda Proxy Integration Response Formatting Requirements

Soru 163Soru →

A developer is troubleshooting an application running on Amazon ECS (using AWS Fargate) in AWS Account A. The application needs to retrieve objects from an Amazon S3 bucket in AWS Account B. The S3 objects are encrypted using a Customer Managed Key (CMK) in AWS Key Management Service (AWS KMS) located in Account B. The ECS Task Role in Account A has been configured with an identity-based policy that allows both s3:GetObject on the bucket and kms:Decrypt on the KMS CMK. However, when the containerized application runs, it receives an Access Denied error. Which two configuration changes must the developer make in Account B to resolve this authorization failure?

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

Update the S3 bucket policy in Account B to grant s3:GetObject permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.

Update the KMS key policy in Account B to grant kms:Decrypt permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.

Update the S3 bucket policy and KMS key policy in Account B to grant permissions to the Amazon Resource Name (ARN) of the ECS Task Execution Role from Account A.

Modify the ECS Task Role's trust policy in Account A to trust the S3 service principal (s3.amazonaws.com) and the KMS service principal (kms.amazonaws.com).

Update the application code to initialize the AWS SDK client using static credentials of a newly created IAM User in Account B that has full access to S3 and KMS.

Cevabı ve açıklamayı göster

Cevap: Update the S3 bucket policy in Account B to grant s3:GetObject permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.; Update the KMS key policy in Account B to grant kms:Decrypt permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.

Cevap

To resolve the authorization failure, the developer must update the S3 bucket policy in Account B to grant s3:GetObject permissions to the ECS Task Role ARN from Account A, and update the KMS key policy in Account B to grant kms:Decrypt permissions to the ECS Task Role ARN from Account A.

For cross-account access to resource-based services that support encryption (like S3 and KMS), permissions must be configured in both the identity-based policy (the ECS Task Role in Account A) and the resource-based policies (the S3 bucket policy and the KMS key policy in Account B). Since the identity-based policies are already in place, the developer must update both resource policies in Account B to trust the ECS Task Role.

Adım Adım Çözüm

Configure cross-account S3 access in Account B.

The S3 bucket policy in Account B is updated to allow the principal ARN matching the ECS Task Role in Account A.

For cross-account access, permissions must be granted on both the identity (ECS Task Role) and the resource (S3 bucket policy).

Configure cross-account KMS key access in Account B.

The KMS key policy in Account B is updated to allow the ECS Task Role from Account A to perform the kms:Decrypt operation.

AWS KMS requires that the key policy itself explicitly trust the external IAM identity; identity-based policies in the external account are insufficient by themselves.

Anahtar Kavram

Cross-account authorization requires explicit permissions on both the identity-based policy in the source account and the resource-based policies (bucket policy and KMS key policy) in the destination account.

Tahmini Süre:2m 0s

Soru 164Soru →

An order processing system publishes JSON-formatted logs to Amazon CloudWatch Logs. The logs contain a top-level key named `status`. A representative log event is:

{
"orderId": "1001",
"status": "Failed",
"code": 500
}

Which filter pattern should be applied to the log group to capture these specific events?

{ $.status = "Failed" }

$.status = "Failed"

[status = "Failed"]

{ status == "Failed" }

Cevabı ve açıklamayı göster

Cevap: { $.status = "Failed" }

Cevap

The correct filter pattern is `{ $.status = "Failed" }`.

The correct pattern is `{

.status = "Failed" }` because structured JSON logs in CloudWatch Logs must be queried with patterns enclosed in curly braces. Within the braces, the root object is represented by `

`, followed by the key name (e.g., `$.status`), and a single equals sign `=` is used for string or numeric value comparison.

Adım Adım Çözüm

Identify the log format

The log event is structured in JSON format.

JSON logs require different metric filter syntax rules compared to space-delimited text logs.

Determine the root selector and curly braces rule

CloudWatch JSON log filters must be enclosed in curly braces `{}` and refer to the root document using `$`.

Without braces and the root selector, CloudWatch cannot parse the JSON path correctly.

Determine the comparison operator

A single equals sign `=` is used for equality comparison.

CloudWatch Metric Filter syntax specifies `=` as the equality operator for string or numeric matching.

Anahtar Kavram

CloudWatch Logs Metric Filter JSON Syntax

Soru 165Soru →

A developer has deployed a React-based inventory management portal hosted on a static website on AWS Amplify. The portal needs to send `PATCH` requests to an Amazon API Gateway REST API that integrates with a backend AWS Lambda function using a Lambda Proxy integration.

When the portal attempts to invoke the endpoint, the browser console displays a CORS preflight block error. Additionally, when testing the API directly using a CLI tool, the response returns a `502 Bad Gateway` error. The Lambda function execution logs show that the function completes successfully, but it returns a serialized JSON string containing only the inventory data.

Which two actions should the developer take to resolve these issues? (Select two.)

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

Configure the OPTIONS method in API Gateway to return the appropriate CORS headers for the preflight request.

Modify the backend Lambda function to return a structured JSON object containing 'statusCode', 'body', and 'headers', ensuring 'Access-Control-Allow-Origin' is included in the headers.

Add the 'Access-Control-Allow-Origin' header to the response headers of the static website hosting configuration in AWS Amplify.

Change the integration type to Lambda Custom integration and format the Lambda function's return payload as a raw plain-text string.

Implement a Lambda Authorizer that inspects the 'Origin' header and returns an IAM policy allowing the 'execute-api:Invoke' action for the domain.

Cevabı ve açıklamayı göster

Cevap: Configure the OPTIONS method in API Gateway to return the appropriate CORS headers for the preflight request.; Modify the backend Lambda function to return a structured JSON object containing 'statusCode', 'body', and 'headers', ensuring 'Access-Control-Allow-Origin' is included in the headers.

Cevap

To resolve these errors, the developer must configure the OPTIONS method in API Gateway to handle the preflight request and modify the backend Lambda function to return a structured JSON object containing 'statusCode', 'body', and 'headers' (including the 'Access-Control-Allow-Origin' header).

For CORS to work with a Lambda Proxy integration, the browser must receive the appropriate CORS headers for both the preflight OPTIONS request and the actual request. Configuring the OPTIONS method in API Gateway ensures that preflight requests are answered with the correct CORS headers. For the actual request, because a Lambda Proxy integration is used, the backend Lambda function is responsible for returning the response payload in a structured JSON format containing 'statusCode', 'body', and 'headers', with the 'Access-Control-Allow-Origin' header explicitly set inside the headers map. This resolves both the preflight CORS block and the 502 Bad Gateway integration error.

Adım Adım Çözüm

Configure the OPTIONS method in API Gateway.

The browser successfully receives CORS headers during the preflight OPTIONS request, allowing it to proceed with the actual cross-origin request.

Before sending non-simple HTTP requests (such as PATCH), browsers send a preflight OPTIONS request to verify CORS permissions.

Modify the Lambda function response format.

The Lambda function returns a valid JSON object matching the proxy integration structure, containing 'statusCode', 'body', and 'headers'.

Lambda Proxy integrations require a strict response payload format; failing to provide this schema causes API Gateway to return a 502 Bad Gateway error.

Include the Access-Control-Allow-Origin header in the Lambda function's response headers.

The browser receives the Access-Control-Allow-Origin header with the actual PATCH response, satisfying the CORS policy constraint.

Under Lambda Proxy integrations, API Gateway does not automatically inject CORS headers into integration responses, meaning the backend code must supply them.

Anahtar Kavram

Handling CORS preflight configurations and Lambda Proxy response integration requirements in Amazon API Gateway.

Tahmini Süre:2m 30s

Soru 166Soru →

A developer is troubleshooting a serverless application where an Amazon SQS queue triggers an AWS Lambda function to process batch invoice reports. Under normal load, the invoices are processed successfully. However, during peak hours when processing times increase, the developer notices that some invoices are generated multiple times. CloudWatch logs show that the Lambda function occasionally runs for up to $45$ seconds before completion, which is close to its configured timeout. The SQS queue's visibility timeout is currently set to $30$ seconds. Which configuration change will resolve this duplicate processing issue?

Increase the SQS queue's visibility timeout to at least

270

seconds.

Reduce the Lambda function's execution timeout to

25

seconds.

Configure a Dead-Letter Queue (DLQ) on the SQS queue with a maxReceiveCount of

1

Increase the SQS queue's visibility timeout to

50

seconds.

Cevabı ve açıklamayı göster

Cevap: Increase the SQS queue's visibility timeout to at least $270$ seconds.

Cevap

Increase the SQS queue's visibility timeout to at least

270

seconds.

The correct option addresses the timeout mismatch by setting the SQS visibility timeout to

270

seconds, which satisfies the AWS best practice of maintaining the queue's visibility timeout at least

6

times the Lambda function's timeout. This prevents SQS from delivering the same message to another Lambda execution thread while the active thread is still processing the invoice.

Adım Adım Çözüm

Identify the relationship between the Lambda function's timeout and the SQS queue's visibility timeout.

The Lambda function timeout is

45

seconds, but the SQS visibility timeout is only

30

seconds.

When the visibility timeout is shorter than the Lambda execution time, SQS makes the message visible to other consumers while the current Lambda execution is still running, causing duplicate processing.

Apply the AWS recommended formula for SQS-to-Lambda integration timeouts.

Visibility Timeout

\geq 6 \times

Lambda Timeout.

The safety margin of

6

times the function timeout allows Lambda to retry the function if it is throttled or returns an error while processing a previous batch.

Calculate the minimum visibility timeout required.

6 \times 45\text{ seconds} = 270\text{ seconds}

This is the minimum duration the visibility timeout should be set to prevent duplicate processing during peak hours.

Anahtar Kavram

SQS visibility timeout configuration when integrated with Lambda

Soru 167Soru →

An AWS Lambda function written in Node.js queries an Amazon DynamoDB table using the AWS SDK for JavaScript (v3). The function's configuration has active tracing enabled. However, when viewing traces in the AWS X-Ray console, only the Lambda service and function segments are displayed, while the downstream queries to DynamoDB are completely missing. What action must be taken to ensure that these DynamoDB queries are recorded as part of the traces?

Rely on the active tracing setting of the Lambda function to automatically intercept and trace all downstream AWS SDK calls without changing the application code

Wrap the DynamoDB client instance in the Lambda function code using the captureAWSv3Client function from the AWS X-Ray SDK

Initialize the DynamoDB client by passing hardcoded IAM credentials into the client constructor to authorize tracing requests to the X-Ray daemon

Increase the Lambda function's timeout configuration to allow the execution context to remain active longer, giving the background processes more time to flush traces

Cevabı ve açıklamayı göster

Cevap: Wrap the DynamoDB client instance in the Lambda function code using the captureAWSv3Client function from the AWS X-Ray SDK

Cevap

Wrap the DynamoDB client instance in the Lambda function code using the captureAWSv3Client function from the AWS X-Ray SDK.

The correct action is to wrap the DynamoDB client using captureAWSv3Client from the AWS X-Ray SDK. Active tracing on AWS Lambda provides tracing for the environment and runtime execution but does not automatically capture downstream requests made by client libraries. To record queries made with the AWS SDK for JavaScript (v3), the client instance must be wrapped explicitly.

Adım Adım Çözüm

Identify the cause of the missing downstream DynamoDB traces.

The AWS SDK client is not instrumented to forward context to AWS X-Ray.

Although active tracing is enabled on the Lambda function itself, this only covers the environment and the function execution. It does not automatically hook into internal SDK clients.

Select the correct SDK instrumentation method for AWS SDK for JavaScript (v3).

Use the captureAWSv3Client utility from the AWS X-Ray SDK.

In SDK v3, tracing requires wrapping the specific client instances (like the DynamoDB client) with the X-Ray library to construct downstream subsegments.

Anahtar Kavram

Instrumenting AWS SDK clients with AWS X-Ray SDK in AWS Lambda

Soru 168Soru →

A developer has installed and configured the Unified CloudWatch Agent on a fleet of Amazon EC2 instances to stream application logs to Amazon CloudWatch Logs. However, after starting the agent, the developer notices that no log groups or log streams are being created in the CloudWatch console.

Which TWO actions should the developer take to troubleshoot and resolve this issue?

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

Verify that the IAM role attached to the EC2 instances contains the permissions from the CloudWatchAgentServerPolicy AWS-managed policy.

Check the CloudWatch agent log file on the EC2 instances for configuration errors or AWS API credential issues.

Verify that the Metric Filter patterns associated with the target log group match the format of the incoming logs.

Ensure that the application Nginx service execution timeout is configured to match the CloudWatch log streaming visibility window.

Modify the IAM trust policy of the EC2 instance role to allow the logs.amazonaws.com service principal to assume the role.

Cevabı ve açıklamayı göster

Cevap: Verify that the IAM role attached to the EC2 instances contains the permissions from the CloudWatchAgentServerPolicy AWS-managed policy.; Check the CloudWatch agent log file on the EC2 instances for configuration errors or AWS API credential issues.

Cevap

Verify that the IAM role attached to the EC2 instances contains the permissions from the CloudWatchAgentServerPolicy AWS-managed policy, and check the CloudWatch agent log file on the EC2 instances for configuration errors or AWS API credential issues.

The correct steps to troubleshoot missing logs in CloudWatch when using the Unified CloudWatch Agent are verifying the IAM permissions of the EC2 instance (which must include permissions to publish logs) and checking the agent's local log file for errors. The CloudWatchAgentServerPolicy contains the required permissions, and the local agent log file provides diagnostic details.

Adım Adım Çözüm

Identify the service permissions required for the agent to publish logs.

Confirm that the EC2 instance must be allowed to perform logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents, which are provided by the CloudWatchAgentServerPolicy.

Without these permissions, the agent cannot write logs to CloudWatch.

Locate and review the agent's local logs on the host operating system.

Check the local log file for permission denied errors or configuration errors.

Local agent logs are the primary diagnostic source when logs fail to publish to AWS.

Anahtar Kavram

CloudWatch Logs Ingestion and Troubleshooting

Soru 169Soru →

An application deployed in an Amazon ECS container on AWS Fargate uses the awslogs log driver to stream stdout logs to an Amazon CloudWatch Logs log group. The application outputs logs in JSON format, but the container's logging framework prepends a plaintext timestamp to each log line, resulting in log events formatted as follows:

`2026-07-14T12:00:00Z {"level": "ERROR", "response": {"status_code": 504, "error": "Gateway Timeout"}}`

The developer created a CloudWatch Metric Filter with the pattern `{ $.response.status_code = 504 }` to monitor these errors, but the metric is not registering any data. Which two actions should the developer take to resolve this issue and ensure the metrics are accurately captured?

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

Configure the application's logging framework to output raw JSON without prepended plaintext.

Update the metric filter pattern to use a space-delimited text pattern, such as `[timestamp, json_payload = *status_code": 504*]`.

Modify the metric filter pattern to `$.response.status_code = 504` without curly braces.

Migrate the application to AWS Lambda and implement a try-catch block inside the handler code to intercept execution timeouts and log a custom 504 error payload.

Add logs:PutLogEvents permissions to the ECS Task Role to authorize the metric filter to publish metrics to CloudWatch.

Cevabı ve açıklamayı göster

Cevap: Configure the application's logging framework to output raw JSON without prepended plaintext.; Update the metric filter pattern to use a space-delimited text pattern, such as `[timestamp, json_payload = *status_code": 504*]`.

Cevap

Configure the application's logging framework to output raw JSON without prepended plaintext, or update the metric filter pattern to use a space-delimited text pattern.

The correct options target the underlying parsing failure: either by rendering the log events as valid JSON so the JSON metric filter pattern can function, or by using a space-delimited pattern to extract the JSON substring and match the status code within it.

Adım Adım Çözüm

Analyze why the JSON metric filter pattern is failing to match the log events.

The log event is prepended with a plaintext timestamp, which invalidates the JSON structure of the log event and prevents CloudWatch Logs from parsing it as valid JSON.

CloudWatch Logs JSON metric filters only work on log events that are valid JSON objects from the very first character.

Identify the first valid solution: modify the log format produced by the application.

Removing the prepended plaintext timestamp makes the entire log event a valid JSON object starting with curly braces.

This allows the existing JSON metric filter pattern to parse and match the JSON fields correctly.

Identify the second valid solution: adjust the metric filter pattern to match the actual log format without modifying the application configuration.

Using a space-delimited filter pattern successfully parses the timestamp and matches the JSON string payload.

This maps the log event fields to position-based tokens, where the first token is the timestamp and the second is the JSON payload containing the targeted status code.

Anahtar Kavram

CloudWatch Logs Metric Filters require strict syntax matching: JSON filters require valid JSON log events enclosed in curly braces, while mixed or non-JSON logs must be parsed using space-delimited filter patterns.

Soru 170Soru →

A developer has a Node.js application deployed in Docker containers on Amazon ECS. The application writes data to an Amazon DynamoDB table using the AWS SDK for JavaScript (v3) and calls an external payment processing API over HTTPS using the Node.js native https module. The developer has deployed the AWS X-Ray daemon container as a sidecar in the ECS task definition and verified that the daemon is running and receiving data. However, the X-Ray console only shows the container node without any downstream nodes for DynamoDB or the payment API.

Which two actions should the developer take to ensure that both the DynamoDB calls and the external HTTPS API calls are instrumented and visible in the X-Ray service map?

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

Instrument the DynamoDB client using the captureAWSv3Client function from the AWS X-Ray SDK.

Call the captureHTTPsGlobal function from the AWS X-Ray SDK to automatically trace downstream HTTPS calls.

Hardcode the AWS access key and secret access key in the X-Ray SDK configuration using AWS.config.update().

Configure the API Gateway integration type as a custom integration rather than a proxy integration to pass X-Ray headers.

Increase the visibility timeout of the SQS queue that processes the messages to allow the X-Ray daemon more time to flush its buffer.

Cevabı ve açıklamayı göster

Cevap: Instrument the DynamoDB client using the captureAWSv3Client function from the AWS X-Ray SDK.; Call the captureHTTPsGlobal function from the AWS X-Ray SDK to automatically trace downstream HTTPS calls.

Cevap

Instrument the DynamoDB client using the captureAWSv3Client function from the AWS X-Ray SDK, and call the captureHTTPsGlobal function from the AWS X-Ray SDK to automatically trace downstream HTTPS calls.

To achieve distributed tracing in Node.js applications, the AWS SDK client must be instrumented explicitly (via captureAWSv3Client for SDK v3), and native HTTP/HTTPS modules must be wrapped (via captureHTTPsGlobal) to capture downstream third-party service calls.

Adım Adım Çözüm

Identify the AWS SDK instrumentation method for JavaScript SDK v3.

Determine that wrapping the DynamoDB client with the captureAWSv3Client function from the AWS X-Ray SDK enables tracing for DynamoDB calls.

By default, the SDK clients are not instrumented and their requests are not sent to the X-Ray daemon.

Identify the HTTP/HTTPS tracing method for external API calls in Node.js.

Determine that invoking captureHTTPsGlobal at the entry point of the application instruments the native HTTP/HTTPS modules.

This allows the X-Ray SDK to intercept and record downstream HTTP/HTTPS requests to the payment API.

Anahtar Kavram

To trace downstream calls in AWS X-Ray, developers must instrument both the AWS SDK clients and any HTTP/HTTPS clients using the language-specific AWS X-Ray SDK.

Soru 171Soru →

An organization's deployment pipeline fails during a step that executes an AWS CloudFormation stack template. The pipeline is configured to update a stack that has a status of ROLLBACK_COMPLETE following a failed initial creation attempt. Which actions should a developer take to resolve this issue and enable a successful deployment? (Choose two.)

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

Delete the CloudFormation stack in the ROLLBACK_COMPLETE state.

Resolve the underlying resource configuration issue that caused the initial creation failure.

Initiate a stack update operation using the corrected template directly on the existing stack.

Add the cloudformation:UpdateStack permission to the trust policy of the IAM service role.

Run a drift detection operation on the stack and import the failed resources to force the state to UPDATE_COMPLETE.

Cevabı ve açıklamayı göster

Cevap: Delete the CloudFormation stack in the ROLLBACK_COMPLETE state.; Resolve the underlying resource configuration issue that caused the initial creation failure.

Cevap

Delete the CloudFormation stack in the ROLLBACK_COMPLETE state and resolve the underlying resource configuration issue that caused the initial creation failure.

To resolve a failed initial deployment that resulted in a ROLLBACK_COMPLETE state, the developer must delete the stack and fix the root cause of the failure. CloudFormation does not allow updates to stacks that failed their initial creation (ROLLBACK_COMPLETE). Once the stack is deleted and the template/environment issues are resolved, the pipeline can successfully trigger a new stack creation.

Adım Adım Çözüm

Analyze the CloudFormation event logs to identify the resource and reason that caused the initial creation failure.

The root cause of the deployment failure is understood.

Understanding why the initial deployment failed is necessary to correct the template or parameters.

Delete the failed stack that is in the ROLLBACK_COMPLETE state.

The stack name is freed up, and the failed stack is removed.

Stacks that fail initial creation reach ROLLBACK_COMPLETE and cannot be updated. They must be deleted before a new stack can be created.

Fix the template or environment issues and trigger the CI/CD pipeline to redeploy.

A new stack is successfully created.

Running the pipeline with the corrected configuration creates a fresh stack without hitting the previous errors.

Anahtar Kavram

Managing CloudFormation stack states and resolving failed initial creations in a CI/CD pipeline.

Soru 172Soru →

A mobile gaming application writes daily player high scores to an Amazon DynamoDB table. Although the table's total provisioned write capacity is significantly higher than the aggregate write rate, the application frequently experiences ProvisionedThroughputExceededException errors because all writes use the current date (e.g., YYYY-MM-DD) as the partition key. Which action should the developer take to resolve this throttling issue?

Increase the provisioned Write Capacity Units (WCUs) of the table until the errors stop occurring.

Change the partition key design to combine the date with a random numerical suffix to distribute write requests across multiple partitions.

Replace the write operations with a Scan operation containing a FilterExpression to query the database items in parallel.

Adjust the processing queue's message visibility duration to handle the database write failures.

Cevabı ve açıklamayı göster

Cevap: Change the partition key design to combine the date with a random numerical suffix to distribute write requests across multiple partitions.

Cevap

Change the partition key design to combine the date with a random numerical suffix to distribute write requests across multiple partitions.

The correct answer is to modify the partition key design to include a random numerical suffix. This technique, known as write sharding, distributes the writes for a single day across multiple partition keys (e.g., YYYY-MM-DD.1, YYYY-MM-DD.2), thereby distributing the physical partition load and preventing ProvisionedThroughputExceededException errors.

Adım Adım Çözüm

Identify the cause of the throttling.

The application is encountering ProvisionedThroughputExceededException despite having high total provisioned capacity, indicating a hot partition key issue because all writes target the same partition key (the current date).

DynamoDB partitions data based on the partition key. If too many writes target the same key, that physical partition gets throttled regardless of the table's total provisioned throughput.

Select a solution that increases partition key entropy.

Add a random or calculated suffix (e.g., a number from 1 to N) to the date partition key.

This spreads the write requests across multiple distinct partition keys, distributing the workload across multiple physical partitions.

Anahtar Kavram

Resolving hot partition keys in Amazon DynamoDB by introducing write sharding (adding a random suffix) to distribute the load across multiple physical partitions.

Soru 173Soru →

A developer is troubleshooting an AWS Lambda function written in Python that processes transaction records. The function intermittently fails with a memory limit exceeded error after running successfully for several hours under continuous traffic. The developer reviews the code and notes that a helper class initializes an in-memory cache list in the global scope, outside the handler function, to store transaction IDs. Which of the following is the most likely cause of this issue and the correct resolution?

The Lambda execution environment is being reused across multiple invocations, causing the global transaction ID cache list to grow indefinitely. To resolve this, the developer should initialize the cache list inside the handler function so it is cleared for each request.

The Lambda function's timeout is set too high, preventing the AWS runtime from automatically recycling the execution context and freeing up memory. To resolve this, the developer should decrease the timeout value to force context recycling.

The Lambda function is running in a private VPC subnet without an attached NAT Gateway, causing database connection attempts to hang and consume memory buffers. To resolve this, the developer should configure a NAT Gateway in the VPC's public subnet.

The function is hardcoding AWS IAM access keys within the global SDK initialization block, causing a memory leak during credential verification. To resolve this, the developer should configure the function to use the execution role's temporary credentials by removing the hardcoded keys.

Cevabı ve açıklamayı göster

Cevap: The Lambda execution environment is being reused across multiple invocations, causing the global transaction ID cache list to grow indefinitely. To resolve this, the developer should initialize the cache list inside the handler function so it is cleared for each request.

Cevap

The correct option is correct because AWS Lambda reuses execution environments (warm starts) to improve latency. Objects declared in the global scope (outside the handler function) persist across these invocations. Since the transaction ID cache list is global and items are continuously added to it without being cleared, the memory footprint increases over time, eventually exceeding the configured memory limit. Initializing the list inside the handler ensures it is scoped to a single invocation and garbage collected afterward.

Adım Adım Çözüm

Analyze the symptom where the memory limit is exceeded only after running successfully for several hours under continuous traffic.

This indicates a progressive memory leak that accumulates across multiple invocations rather than a failure on the first execution.

AWS Lambda optimizes performance by keeping execution environments warm and reusing them for subsequent requests.

Inspect the code structure to locate the global variable declaration.

The in-memory cache list is declared in the global scope (outside the handler function).

State stored in global variables persists across invocations in reused execution environments.

Determine the resolution to prevent the list from growing across warm starts.

Declare the cache list inside the handler function or explicitly clear it at the beginning of each handler execution.

This guarantees that the list starts empty for every request, preventing memory accumulation.

Anahtar Kavram

Lambda Execution Context Reuse and Global State

Tahmini Süre:1m 30s

Soru 174Soru →

A developer is troubleshooting a CloudWatch Logs subscription filter that streams log events from a Lambda function's log group to an Amazon Kinesis Data Firehose delivery stream. The delivery stream successfully writes data to an Amazon S3 bucket, but the developer notices that no logs from the subscription filter are arriving in S3. The CloudWatch metric DeliveryErrors for the subscription filter shows a consistently high count. The developer verifies that the Firehose delivery stream is active and that the IAM role specified in the subscription filter has a permissions policy allowing firehose:PutRecord and firehose:PutRecordBatch on the delivery stream. Which of the following is the most likely cause of this issue?

The CloudWatch Logs log group is missing an IAM resource policy that allows the Kinesis Data Firehose delivery stream to read logs.

The IAM role specified in the subscription filter is missing the logs:PutLogEvents and logs:CreateLogStream permissions required to read the log group.

The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.

The trust policy of the IAM role specified in the subscription filter does not list the Kinesis Data Firehose service principal (firehose.amazonaws.com) as a trusted entity.

Cevabı ve açıklamayı göster

Cevap: The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.

Cevap

The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.

To stream logs via a subscription filter, CloudWatch Logs must assume the IAM role specified in the subscription filter to write events to Kinesis Data Firehose. If the trust policy of that IAM role does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity, the sts:AssumeRole call fails, preventing logs from being delivered and causing DeliveryErrors.

Adım Adım Çözüm

Identify the component failing in the log delivery pipeline.

The DeliveryErrors metric for the CloudWatch Logs subscription filter is high, indicating that CloudWatch Logs is unable to write the log events to Kinesis Data Firehose.

Understanding where the failure occurs helps narrow down whether the issue lies within Firehose configuration, IAM permissions, or subscription filter setup.

Analyze the IAM permission requirements for CloudWatch Logs subscription filters.

For CloudWatch Logs to push log data to Kinesis Data Firehose, it must assume the IAM role provided in the subscription filter.

This transition requires an sts:AssumeRole operation, which relies on the role's trust policy.

Evaluate the trust relationship of the IAM role.

The trust policy of the IAM role must permit the logs.amazonaws.com service principal to assume it.

If the trust policy incorrectly trusts firehose.amazonaws.com or lacks the logs service principal entirely, the assume-role request fails, resulting in delivery errors.

Anahtar Kavram

IAM Role Trust Relationships for CloudWatch Logs Subscription Filters

Soru 175Soru →

A developer is troubleshooting a Java application running on Amazon ECS Fargate that receives HTTP requests and uses the AWS SDK for Java to write metadata to an Amazon DynamoDB table. The developer runs the AWS X-Ray daemon as a sidecar container in the ECS task. The X-Ray daemon logs confirm that it is successfully receiving trace segments and uploading them to AWS X-Ray. However, in the X-Ray trace map, the downstream calls to DynamoDB do not appear. Which action should the developer take to ensure DynamoDB calls are included in the trace?

Configure the AWS SDK client in the Java application using the X-Ray SDK's TracingInterceptor to instrument downstream service calls.

Hardcode AWS credentials directly in the X-Ray SDK client initialization code to authenticate with the X-Ray daemon.

Adjust the SQS visibility timeout to allow more time for the X-Ray daemon to collect asynchronous trace segments.

Modify the DynamoDB integration response in API Gateway to map the proxy headers dynamically.

Cevabı ve açıklamayı göster

Cevap: Configure the AWS SDK client in the Java application using the X-Ray SDK's TracingInterceptor to instrument downstream service calls.

Cevap

Configure the AWS SDK client in the Java application using the X-Ray SDK's TracingInterceptor to instrument downstream service calls.

To include downstream calls in an AWS X-Ray trace, the application's AWS SDK client must be instrumented. For Java applications, this is done by adding the X-Ray SDK's TracingInterceptor to the AWS SDK client configuration, which automatically creates subsegments for each downstream service call.

Adım Adım Çözüm

Analyze the daemon logs to verify trace collection functionality.

The daemon logs show that the sidecar container is active, receiving traces locally, and successfully uploading segments to AWS X-Ray.

This rules out daemon configuration or network path issues from the ECS container to the X-Ray service.

Identify why downstream DynamoDB calls are missing from the trace map.

The AWS SDK client itself has not been instrumented with the AWS X-Ray SDK.

By default, the AWS SDK does not record subsegments for X-Ray. The client must be explicitly instrumented using the TracingInterceptor.

Configure the AWS SDK client with the TracingInterceptor.

Downstream calls automatically include tracing headers and generate subsegments.

Adding TracingInterceptor to the AWS SDK client builder allows X-Ray to track calls made to DynamoDB.

Anahtar Kavram

AWS SDK Client Instrumentation with AWS X-Ray SDK

Soru 176Soru →

A developer needs to monitor an AWS Lambda function that occasionally times out during execution. The developer wants to count the occurrences of these timeouts and receive an alert when they happen. Which of the following steps should the developer perform to meet these requirements? (Select TWO.)

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

Create a CloudWatch Logs metric filter on the function's log group with the filter pattern "Task timed out" to increment a custom metric.

Create a CloudWatch Alarm based on the custom metric generated by the metric filter to send an alert when the threshold is exceeded.

Create a CloudWatch Logs subscription filter on the log group to send log data directly to an Amazon SNS topic.

Increase the function's execution timeout limit to automatically publish a custom LambdaTimeout metric to CloudWatch.

Configure a CloudWatch metric filter on the default AWS Lambda metrics stream with the pattern "timeout".

Cevabı ve açıklamayı göster

Cevap: Create a CloudWatch Logs metric filter on the function's log group with the filter pattern "Task timed out" to increment a custom metric.; Create a CloudWatch Alarm based on the custom metric generated by the metric filter to send an alert when the threshold is exceeded.

Cevap

Create a CloudWatch Logs metric filter with the pattern "Task timed out" on the function's log group and configure a CloudWatch Alarm based on the resulting metric.

To monitor and alarm on specific log statements, a developer must create a metric filter on the CloudWatch Logs log group associated with the log source (such as the Lambda log group /aws/lambda/<function-name>). When Lambda times out, it logs a standard message containing the phrase "Task timed out". Creating a metric filter with the pattern "Task timed out" will match this phrase and increment a custom metric. The developer can then associate a CloudWatch Alarm with this custom metric to send alerts when the failure count exceeds thresholds.

Adım Adım Çözüm

Identify the log group associated with the Lambda function and the exact log phrase indicating a timeout.

The log group is /aws/lambda/<function-name> and the timeout log phrase is "Task timed out".

This identifies the target log source and the search criteria needed for tracking timeouts.

Configure a metric filter on the identified log group with the pattern "Task timed out".

A custom metric is generated and incremented whenever a log matches the pattern.

This extracts the text pattern from the raw log stream into a numeric time-series metric.

Create a CloudWatch Alarm that monitors the custom metric.

An alarm is created to trigger alerts (e.g., via SNS) when the count exceeds the defined threshold.

This establishes the alerting mechanism to notify the developer when timeouts occur.

Anahtar Kavram

Using CloudWatch Logs metric filters to extract metrics from plain text log streams and alarming on them.

Soru 177Soru →

A developer attempts to deploy a new stack named `prod-app-backend` using AWS CloudFormation. The initial stack creation fails due to a syntax error in the resource properties, and the stack status transitions to `ROLLBACK_COMPLETE`. After correcting the syntax error in the template, the developer tries to perform a stack update using the corrected template and the same stack name, but the update fails. Which action must the developer take to deploy the stack successfully?

Run the `aws cloudformation continue-update-rollback` CLI command to resume the deployment.

Update the trust policy of the IAM service role to allow CloudFormation to assume the role, then retry the update.

Delete the stack and recreate it using the updated template.

Disable the rollback behavior in the stack settings and retry the stack update.

Cevabı ve açıklamayı göster

Cevap: Delete the stack and recreate it using the updated template.

Cevap

Delete the stack and recreate it using the updated template.

When a CloudFormation stack fails its initial creation, it rolls back all resources and transitions to `ROLLBACK_COMPLETE`. A stack in this state cannot be updated because it was never successfully created. To deploy the stack with the same name, the developer must first delete the existing stack and then create a new one using the corrected template.

Adım Adım Çözüm

Identify the current state of the stack.

The stack is in the `ROLLBACK_COMPLETE` state after a failed initial creation attempt.

CloudFormation stacks that fail their initial creation roll back and enter this state. They contain no successfully deployed resources.

Determine if an update operation is supported.

Update operations are rejected by CloudFormation for stacks in the `ROLLBACK_COMPLETE` state that resulted from a failed creation.

Since the stack was never successfully created in the first place, there is no active baseline to update.

Perform the required cleanup and redeployment.

Delete the failed stack to release the stack name, then run the creation process with the corrected template.

Deleting the stack removes the metadata entry in CloudFormation, allowing a new stack with the same name to be created successfully.

Anahtar Kavram

CloudFormation Stack Lifecycle and Rollback States

Tahmini Süre:1m 30s

Soru 178Soru →

A developer is configuring a custom Amazon CloudWatch metric filter to monitor performance metrics from an API gateway service. The service writes structured JSON logs to a CloudWatch log group. A representative log event has the following structure:

{
"service": "payment-api",
"transaction": {
"success": true,
"amount": 250.00
},
"latency": 150
}

The developer needs to create a metric filter that publishes to a custom metric named `HighValueLatency` in the `PaymentMetrics` namespace. The metric must record the `latency` value, but only for events where the transaction `success` is `true` and the transaction `amount` is strictly greater than $200$ .

Which TWO configurations or values must the developer specify in the metric filter settings to achieve this?

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

Set the filter pattern to `{ (

.transaction.success = true) && (

.transaction.amount > 200) }`

Set the metric value to `$.latency`

Set the filter pattern to `{

.transaction.success == true &&

.transaction.amount > 200 }`

Set the metric value to `$latency`

Set the filter pattern to `filter transaction.success = true and transaction.amount > 200`

Cevabı ve açıklamayı göster

Cevap: Set the filter pattern to `{ ( $.transaction.success = true) && ($ .transaction.amount > 200) }`; Set the metric value to `$.latency`

Cevap

Set the filter pattern to `{ (

.transaction.success = true) && (

.transaction.amount > 200) }` and set the metric value to `$.latency`

To extract a specific field value from a JSON log event based on multiple conditions, the developer must specify both a valid filter pattern and a valid metric value. The pattern must enclose each individual comparison within parentheses and join them with the `&&` operator, using a single `=` for equality, which matches `{ (

.transaction.success = true) && (

.transaction.amount > 200) }`. The metric value must refer to the desired JSON path using standard dot notation starting with `

.`, which matches `

.latency`.

Adım Adım Çözüm

Formulate the JSON path expressions for the target fields.

The target fields are transaction success, transaction amount, and latency. The corresponding JSON path expressions are `

.transaction.success`, `

.transaction.amount`, and `$.latency`.

CloudWatch Logs metric filters use JSON path notation starting with `$.` to reference properties in a JSON log event.

Construct the multi-conditional filter pattern.

Combine the conditions using the syntax `{ (condition1) && (condition2) }`, which yields `{ (

.transaction.success = true) && (

.transaction.amount > 200) }`.

When evaluating multiple conditions in a JSON metric filter, each comparison must be enclosed in parentheses and joined by logical operators like `&&`.

Define the metric value extractor.

Specify `$.latency` as the metric value in the metric filter configuration.

To record the actual latency value rather than a count of events, the metric value must point to the specific JSON path containing the numeric measurement.

Anahtar Kavram

CloudWatch Metric Filter JSON parsing and pattern syntax

Tahmini Süre:2m 30s

Soru 179Soru →

A developer is configuring a multi-account CI/CD pipeline using AWS CodePipeline. The pipeline executes an AWS CodeBuild project in Account A. As part of the build spec, the project runs a deployment script that is designed to deploy an AWS CloudFormation stack in Account B. During execution, the build fails at the deployment step with the error: `An error occurred (AccessDenied) when calling the AssumeRole operation`. Which two actions should the developer take to resolve this failure? (Select TWO.)

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

In Account A, attach a policy to the CodeBuild service role that grants the `sts:AssumeRole` permission on the target role's Amazon Resource Name (ARN) in Account B.

In Account B, update the trust policy of the target IAM role to allow the ARN of the CodeBuild service role from Account A to assume it.

In Account B, update the permissions policy of the target IAM role to grant the `sts:AssumeRole` permission to the AWS CodeBuild service principal.

In Account A, update the trust policy of the CodeBuild service role to trust the target IAM role in Account B.

In Account B, run the `aws cloudformation delete-stack` command to delete the target stack before initiating the pipeline again.

Cevabı ve açıklamayı göster

Cevap: In Account A, attach a policy to the CodeBuild service role that grants the `sts:AssumeRole` permission on the target role's Amazon Resource Name (ARN) in Account B.; In Account B, update the trust policy of the target IAM role to allow the ARN of the CodeBuild service role from Account A to assume it.

Cevap

In Account A, attach a policy to the CodeBuild service role that grants the `sts:AssumeRole` permission on the target role's ARN in Account B; and in Account B, update the trust policy of the target IAM role to allow the ARN of the CodeBuild service role from Account A to assume it.

The correct options state that a policy must be attached to the CodeBuild service role in Account A granting `sts:AssumeRole` on the target role's ARN, and the target role's trust policy in Account B must be updated to trust the CodeBuild service role from Account A. This pair of configurations satisfies the cross-account delegation requirements in AWS IAM.

Adım Adım Çözüm

Configure permissions in the source account (Account A)

The CodeBuild service role is granted permission to perform `sts:AssumeRole` on the target role's ARN.

The initiating identity must have explicit permission to invoke the assume role action on the specific target resource.

Configure the trust relationship in the target account (Account B)

The target IAM role's trust policy is updated to list the CodeBuild service role's ARN as a trusted entity.

An IAM role cannot be assumed by a principal in another account unless that principal is explicitly trusted in the role's trust policy.

Anahtar Kavram

Cross-account IAM role assumption requires granting `sts:AssumeRole` permission in the source account and trusting the source principal in the target role's trust policy.

Tahmini Süre:2m 0s

Soru 180Soru →

A client-side Angular application hosted on `https://claims.healthportal.com` sends a `PUT` request to an Amazon API Gateway REST API secured by a custom Lambda Authorizer. The API is integrated with a backend Lambda function using Lambda Proxy Integration. When users attempt to perform actions with expired session tokens, the application's browser console displays a CORS preflight blocked error, and the request fails without displaying the expected session expiration message to the user. Which actions should the developer take to resolve the CORS preflight blocked error and allow the frontend to receive the correct status codes? (Select TWO.)

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

Configure the CORS configuration of the Amazon S3 bucket hosting the Angular frontend to allow traffic from the API Gateway endpoint.

Modify the backend Lambda integration function to catch authentication errors and return a structured JSON response containing the Access-Control-Allow-Origin header.

Configure the 'Unauthorized' (401) Gateway Response in the API Gateway console to return the Access-Control-Allow-Origin header set to the origin domain.

Modify the Lambda Authorizer to return an IAM policy that explicitly grants the 'apigateway:OPTIONS' permission to the client's IAM role.

Configure the 'Access Denied' (403) Gateway Response in the API Gateway console to return the Access-Control-Allow-Origin header set to the origin domain.

Cevabı ve açıklamayı göster

Cevap: Configure the 'Unauthorized' (401) Gateway Response in the API Gateway console to return the Access-Control-Allow-Origin header set to the origin domain.; Configure the 'Access Denied' (403) Gateway Response in the API Gateway console to return the Access-Control-Allow-Origin header set to the origin domain.

Cevap

Configure the 'Unauthorized' (401) and 'Access Denied' (403) Gateway Responses in API Gateway to include the 'Access-Control-Allow-Origin' header.

When a client-side application receives a CORS preflight error during authentication failure, it is because the API Gateway authorizer rejects the request before it reaches the backend integration. As a result, API Gateway generates a default Gateway Response (either 401 Unauthorized or 403 Access Denied) which does not contain CORS headers by default. Configuring the 'Unauthorized' and 'Access Denied' Gateway Responses to return the 'Access-Control-Allow-Origin' header ensures the browser receives the CORS headers and allows the client application to read the HTTP status code.

Adım Adım Çözüm

Identify the source of the error when session tokens expire.

The Lambda Authorizer either throws an error resulting in a 401 Unauthorized status, or returns a Deny policy resulting in a 403 Access Denied status.

Understanding where execution terminates helps determine why CORS headers are missing.

Determine how CORS headers are handled during gateway-level failures.

Because the execution is terminated at the authorizer level before reaching the backend integration, standard integration response headers are bypassed, and API Gateway returns a Gateway Response.

CORS headers must be attached to the Gateway Responses directly since the backend Lambda code is never executed.

Configure Gateway Responses in API Gateway.

Add the 'Access-Control-Allow-Origin' header to both the 'Unauthorized' (401) and 'Access Denied' (403) Gateway Responses.

This ensures the browser receives the required CORS headers for both failure modes, allowing the client-side code to read the HTTP status codes and display the session expiration message.

Anahtar Kavram

Configuring CORS on Gateway Responses for Custom Authorizer failures

ÖncekiSayfa 9 / 14Sonraki

Troubleshooting and Optimization

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