DVA-C02 Flashcards — Free AWS Certified Developer Associate DVA-C02 Study Cards

Increase the batch size to 100.

Increasing the batch size to 100 allows each Lambda invocation to process up to 100 messages from the SQS queue instead of the current 10. Since the function is idempotent and can handle 100 messages per invocation, this change maximizes the number of messages processed per invocation without altering the reserved concurrency of 5. With a batch size of 100, each of the 5 concurrent invocations can process up to 100 messages, yielding a potential throughput of 500 messages per invocation cycle, which directly reduces the backlog and throttling by consuming messages faster.

Increase the reserved concurrency of the Lambda function

Increasing the reserved concurrency from 10 to a higher value directly addresses the root cause of throttling. With a batch size of 100, each invocation processes more messages, but the function's reserved concurrency of 10 limits the maximum number of concurrent executions to 10. This means the Lambda service can only invoke the function 10 times at once, regardless of how many messages are in the queue. By raising reserved concurrency, you allow more concurrent invocations to handle the larger batches, reducing throttling and improving throughput.

DynamoDB Accelerator (DAX)

DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to 10x read performance improvement by reducing response times from milliseconds to microseconds for repeated read queries. By integrating DAX with the Lambda function, the developer can cache the results of frequent DynamoDB queries directly in memory, bypassing the read capacity units and the underlying storage engine, which directly addresses the latency bottleneck shown in the X-Ray trace.

Use the Amazon States Language (ASL) Retry field in the Task state definition.

The Amazon States Language (ASL) provides a native Retry field within a Task state definition that allows you to specify retry policies, including a maximum retry count and exponential backoff. This is the intended mechanism for handling transient failures in Step Functions without requiring custom code or external retry logic.

Enable API Gateway caching on the stage and configure the client ID header as a cache key parameter. Set a cache TTL of 5 minutes.

API Gateway caching allows you to store responses for a configurable TTL and use the client ID header as a cache key parameter. This means that when a request with the same client ID arrives within the TTL window, API Gateway returns the cached response directly without invoking the Lambda function, reducing invocations and improving performance.

The Lambda function does not have kms:Decrypt permission on the KMS key used by the bucket.

When an S3 bucket uses SSE-KMS, the Lambda function must have explicit kms:Decrypt permission on the KMS key to decrypt the object after s3:GetObject retrieves the encrypted data. Even though the bucket policy and execution role allow s3:GetObject, the missing KMS permission causes an Access Denied error because S3 returns the encrypted object and the Lambda runtime cannot decrypt it without the key.

Deny effect with a Condition: StringNotEquals on s3:x-amz-server-side-encryption-aws-kms-key-id

SCPs use a Deny effect to block non-compliant requests. The condition key `s3:x-amz-server-side-encryption-aws-kms-key-id` with `StringNotEquals` ensures that any PutObject request that does not specify the exact KMS key alias/logs-key is denied. This enforces encryption with the required key for all S3 buckets containing 'logs' in their name.

The user in Account B must have an IAM policy that allows s3:GetObject on the bucket ARN

The bucket policy in Account A grants s3:GetObject access to the IAM user in Account B, but this alone is insufficient. For cross-account access, the IAM user in Account B must also have an IAM policy attached that explicitly allows s3:GetObject on the bucket ARN. Without this, the user’s own account denies the request before it reaches Account A’s bucket policy, resulting in Access Denied.

Enable CloudTrail data events for the specific KMS key ARN.

CloudTrail data events can be configured to log individual API operations (such as Decrypt and Encrypt) on specific KMS keys. By default, CloudTrail management events do not include these data-plane operations; enabling data events for the specific KMS key ARN ensures every cryptographic call is recorded for auditing.

Modify the blue/green deployment configuration to use the same database endpoint for both task sets by updating the environment variables in the task definition before deployment.

The issue stems from the green task set using a different database endpoint than the blue task set, which is configured via environment variables in the ECS task definition. By updating the task definition to use the same database endpoint before deployment, both task sets will connect to the same database, ensuring consistency during the traffic shift. This is the simplest fix as it requires no additional infrastructure or complex routing changes.

Deployment type: blue/green, with rollback configuration enabled to trigger automatic rollback and reroute traffic to the original task set

The developer needs to configure the CodeDeploy deployment group with a blue/green deployment type and enable automatic rollback. This ensures that if the green task set fails health checks, CodeDeploy automatically terminates the green deployment and reroutes traffic back to the original blue task set, meeting the requirement for a fully healthy green task set before termination.

Create two separate ECS services, each with its own task definition, and place the web server in a public subnet with the worker in a private subnet.

It uses two separate ECS services, each with its own task definition, allowing independent scaling of the web server and worker. Placing the web server in a public subnet with an Application Load Balancer makes it internet-accessible, while the worker in a private subnet is isolated from direct internet traffic, meeting the security requirement.

CodeDeployDefault.OneAtATime

CodeDeployDefault.OneAtATime, is correct because it deploys the application to one instance at a time, ensuring that only one instance is taken offline during the deployment. This satisfies the requirement for the application to remain fully available. Additionally, this configuration fails fast: if any instance fails to deploy, the deployment stops immediately, preventing further instances from being updated.

Increase the read and write capacity units on the DynamoDB table

The primary cause of the throttling is insufficient DynamoDB capacity to handle the request volume from the Lambda function. Increasing the read and write capacity units (RCUs/WCUs) directly addresses the throttle events by providing more throughput to match the function's concurrency of 100. This is the most effective solution because it resolves the bottleneck at the data store level without reducing the application's ability to process requests concurrently.

Switch the DynamoDB table to on-demand capacity mode

The DynamoDBProvisionedThroughputExceededException errors indicate that the Lambda function is exceeding the provisioned write capacity of 5 WCUs. Switching to on-demand capacity mode eliminates the need to manage throughput, automatically scaling to handle the workload without throttling. This directly resolves the root cause—capacity exhaustion—without requiring manual adjustments or architectural changes.

The Auto Scaling group's cooldown period prevents new instances from being added quickly enough during rapid traffic spikes

The 503 errors occur because the simple scaling policy has a cooldown period (default 300 seconds) that prevents the Auto Scaling group from launching new instances during rapid traffic spikes. When CPU exceeds 70% for 5 minutes, the policy adds 2 instances, but the cooldown blocks further scaling actions until it expires, even if the newly launched instances are still initializing and the healthy host count drops to zero. This mismatch between traffic demand and scaling responsiveness causes the ALB to have no healthy targets, resulting in 503 errors.