DVA-C02 AWS Certified Developer - Associate Questions and Answers

Default SSE in DynamoDB: DynamoDB tables are encrypted at rest by default using an AWS owned key (SSE-S3).

No Additional Action Needed: Creating a table without explicitly specifying a KMS key will use this default encryption.

Why Option A is Correct:Converting a Lambda function to use a container image involves packaging the function code into a container image, storing the image in Amazon Elastic Container Registry (ECR), and updating the function to use the ECR repository URI.

Why Other Options are Incorrect:

Option B: SAM templates support container-based Lambda deployment, but storing the image in S3 is not applicable.

Option C: CloudFormation does not natively support specifying Lambda container images in S3.

Option D: While partially correct, it omits the need to specify the image tag for the deployment.

AWS Documentation References:

Lambda Container Images

The requirements describe a Git-driven workflow where each new branch automatically gets its own deployment with minimal setup and management. AWS Amplify is designed for exactly this use case for web (and supporting mobile backends): it integrates directly with Git providers and offers continuous deployment . Amplify’s feature branch deployments automatically create a separate deployment (and typically a distinct preview URL) for each connected branch, enabling developers to test and review changes per branch without manually provisioning environments.

With Amplify, the developer connects the repository once, selects the branches to deploy, and Amplify automatically builds and deploys the application whenever code changes are pushed. When a new branch is added, Amplify can be configured to deploy it as a separate environment, providing isolated testing, previewing, and validation. This dramatically reduces operational overhead because Amplify manages build settings, hosting, SSL, and branch-based environments without needing custom CI/CD wiring.

Option A (ECR + ECS + GitHub Actions) can support branch deployments, but it requires substantial operational work: container build pipelines, task/service management, networking, scaling, and environment isolation per branch. Option B (Elastic Beanstalk) can manage deployments, but branch-based automatic deployments are not as native; creating separate environments and managing application versions typically requires more manual steps or additional automation. Option C (Lambda aliases) is not a general-purpose web/mobile deployment approach and does not naturally map “new Git branch” to an isolated deployment environment without significant custom tooling.

Therefore, D is the best fit with the least operational overhead: use AWS Amplify with feature branch deployments to automatically create and manage separate deployments for Git branches.

The correct answer is C. Use an AWS Lambda function that is invoked by an Amazon EventBridge scheduled event.

C. Use an AWS Lambda function that is invoked by an Amazon EventBridge scheduled event. This is correct. AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, and logging1. Amazon EventBridge is a serverless event bus service that enables you to connect your applications with data from a variety of sources2. EventBridge can create rules that run on a schedule, either at regular intervals or at specific times and dates, and invoke targets such as Lambda functions3. This solution meets the requirements of creating a small application that makes the same API call once each day at a designated time, without requiring any infrastructure in the AWS Cloud or any operational overhead.

A. Use a Kubernetes cron job that runs on Amazon Elastic Kubernetes Service (Amazon EKS). This is incorrect. Amazon EKS is a fully managed Kubernetes service that allows you to run containerized applications on AWS4. Kubernetes cron jobs are tasks that run periodically on a given schedule5. This solution could meet the functional requirements of creating a small application that makes the same API call once each day at a designated time, but it would not be the most operationally efficient manner. The company would need to provision and manage an EKS cluster, which would incur additional costs and complexity.

B. Use an Amazon Linux crontab scheduled job that runs on Amazon EC2. This is incorrect. Amazon EC2 is a web service that provides secure, resizable compute capacity in the cloud6. Crontab is a Linux utility that allows you to schedule commands or scripts to run automatically at a specified time or date7. This solution could meet the functional requirements of creating a small application that makes the same API call once each day at a designated time, but it would not be the most operationally efficient manner. The company would need to provision and manage an EC2 instance, which would incur additional costs and complexity.

D. Use an AWS Batch job that is submitted to an AWS Batch job queue. This is incorrect. AWS Batch enables you to run batch computing workloads on the AWS Cloud8. Batch jobs are units of work that can be submitted to job queues, where they are executed in parallel or sequentially on compute environments9. This solution could meet the functional requirements of creating a small application that makes the same API call once each day at a designated time, but it would not be the most operationally efficient manner. The company would need to configure and manage an AWS Batch environment, which would incur additional costs and complexity.

The most secure way to handle database credentials for a CodeBuild stage—especially with a company requirement for automatic rotation—is to store credentials in AWS Secrets Manager and reference the secret securely from the CodeBuild environment. Secrets Manager is purpose-built to store, retrieve, and rotate secrets such as database credentials, API keys, and tokens. It encrypts secrets at rest (using AWS KMS), supports fine-grained IAM access control, and integrates with services like CodeBuild through environment variables and runtime retrieval.

With CodeBuild, the developer can configure environment variables to reference a Secrets Manager secret (rather than embedding credentials in buildspec.yml). This ensures that the build process retrieves the latest rotated credentials at runtime, reducing exposure risk and eliminating manual credential updates.

Option B is weaker because Systems Manager Parameter Store (SecureString) is a secure storage mechanism, but automatic rotation is not a native Parameter Store feature in the same way it is in Secrets Manager for database credentials. Secrets Manager provides managed rotation workflows (often via Lambda rotation functions) and scheduling that directly matches the requirement.

Options A and D violate secure handling practices by hardcoding credentials or storing plaintext connection strings. Both approaches significantly increase risk of exposure through source control, build logs, or environment inspection. Additionally, bolting on rotation via Lambda or EventBridge does not address the primary weakness of hardcoded/plaintext secret distribution.

Therefore, AWS Secrets Manager with automatic rotation, referenced securely from CodeBuild environment variables, is the most secure solution.

CodeBuild batch builds are designed for running multiple related builds together and can model dependencies between build tasks. This fits the requirement for simultaneous, interdependent builds across web, mobile, and API components. Using a combination of reserved capacity fleets and On-Demand capacity helps optimize cost and availability. Running all builds as separate projects with only On-Demand capacity misses the reserved fleet cost optimization requirement. Assigning separate projects manually creates more operational overhead and does not naturally coordinate dependencies. Running everything sequentially contradicts the requirement to run builds simultaneously and slows delivery. AWS CodeBuild documentation includes batch build concepts and reserved capacity fleet support, including fleet settings for batch builds. ( AWS Documentation )

===============

This solution will meet the requirements by using AWS Serverless Application Model (AWS SAM) templates and gradual deployments to automatically test the Lambda functions. AWS SAM templates are configuration files that define serverless applications and resources such as Lambda functions. Gradual deployments are a feature of AWS SAM that enable deploying new versions of Lambda functions incrementally, shifting traffic gradually, and performing validation tests during deployment. The developer can enable gradual deployments through AWS SAM templates by adding a DeploymentPreference property to each Lambda function resource in the template. The developer can set the deployment preference type to Canary10Percent30Minutes, which means that 10 percent of traffic will be shifted to the new version of the Lambda function for 30 minutes before shifting 100 percent of traffic. The developer can also use hooks to test the deployment, which are custom Lambda functions that run before or after traffic shifting and perform validation tests or rollback actions.

Comprehensive and Detailed Step-by-Step Explanation:

Option A: Amazon Cognito Identity Pool with Unauthenticated Role

Cognito identity pools can generate temporary AWS credentials for both authenticated and unauthenticated users.

For guest users, Cognito assigns an unauthenticated role with limited permissions, ensuring secure access to only their resources.

This is the most secure and efficient solution for managing AWS credentials dynamically without hardcoding or storing them.

Why Other Options Are Incorrect:

Option B: Hardcoding IAM credentials in the application is insecure and violates best practices.

Option C and D: Temporary keys stored in KMS or Secrets Manager require additional implementation overhead and do not inherently manage user-specific access.

TTL for Automatic Deletion: DynamoDB ' s Time-to-Live effortlessly deletes expired items without manual intervention.

DynamoDB Stream: Captures changes to the table, including deletions of expired items, triggering downstream actions.

Lambda for Processing: A Lambda function connected to the stream provides custom logic for handling the deleted items.

Code Efficiency: This solution leverages native DynamoDB features and stream-based processing, minimizing the need for custom code.

Comprehensive and Detailed Step-by-Step Explanation:

Issue Analysis:

The stream uses service name as the partition key. This can cause " hot partition " issues when a few service names generate significantly more logs compared to others, causing uneven distribution of data across shards.

Metrics show that the write capacity used is below provisioned capacity, which confirms that the throughput errors are due to shard-level limits and not overall capacity.

Option C: Change Partition Key to Creation Timestamp:

By changing the partition key to the creation timestamp (or a composite key including timestamp), the distribution of data across shards can be randomized, ensuring an even spread of records.

This resolves the shard overutilization issue and eliminates ProvisionedThroughputExceededException.

Why Other Options Are Incorrect:

Option A: Switching to on-demand capacity mode might temporarily alleviate the issue, but the root cause (hot partitioning) remains unresolved.

Option B: Adding shards increases capacity but does not fix the skewed data distribution caused by using the service name as the partition key.

Option D: Creating separate streams for each service adds unnecessary complexity and does not scale well as the number of services grows.

CloudWatch Logs data protection policies are designed to detect and mask sensitive data in log events. Managed data identifiers can detect common categories of sensitive information, including PII-related data types, and masking applies across log viewing and query workflows. The logs:Unmask permission controls who can view original unmasked data, so only approved security engineers should receive that permission. Updating the Lambda function is good hygiene but does not protect historical logs and depends on application correctness. KMS encryption protects logs at rest, but authorized log readers would still see plaintext after decryption. Firehose and Athena add unnecessary pipeline complexity and do not enforce masking inside CloudWatch Logs Insights or subscription filters. AWS documentation confirms data protection policies mask sensitive log data and logs:Unmask is required to view unmasked data. ( AWS Documentation )

===============

Why Option B is Correct:

Amazon S3 Standard provides immediate access to files and is cost-effective for files that need to be accessed within 5 minutes.

By adding the S3 location to the SQS queue, you avoid transferring large files directly, which is both more efficient and scalable.

Why Other Options are Incorrect:

Option A: S3 Glacier Deep Archive is designed for archival storage with retrieval times ranging from minutes to hours, which does not meet the 5-minute requirement.

Option C: Amazon EBS is designed for block storage attached to EC2 instances, which adds unnecessary complexity and cost.

Option D: SQS is not designed to handle large file content directly and has message size limits (256 KB).

AWS Documentation References:

Amazon S3 Overview

Amazon SQS Best Practices

The requirement is to test a new Lambda version without impacting the production API, and to do so with the least operational overhead. In API Gateway (REST API), the simplest pattern is to create a separate stage (for example, test) and use a stage variable to control which Lambda function version (or alias) the integration invokes.

With option B, the developer creates a new stage and defines a stage variable (commonly something like lambdaAlias or lambdaVersion). The API method integration URI can reference this stage variable so that each stage points to a different Lambda alias/version. The production stage (for example, prod) continues to call the stable version, while the test stage calls the new version. This cleanly isolates testing traffic and prevents any effect on the production REST API because stages have distinct invoke URLs and deployments.

This approach is operationally efficient because it avoids duplicating the API definition (new REST API) and avoids creating extra resources/methods that must be maintained. It also provides a repeatable process: future versions can be tested by updating only stage variables or alias routing rather than restructuring the API.

Why not the others:

A adds additional resources/methods and increases API surface area and maintenance.

C duplicates the entire API, increasing overhead and configuration drift risk.

D would impact production because it changes the integration used by the existing method.

Therefore, using a new stage + stage variables to route to the updated Lambda version meets the requirements with minimal overhead.

The described behavior is a classic cache stampede (also called the “thundering herd” problem): a large set of hot keys share the same expiration time, so they all expire simultaneously. When that happens, many requests miss the cache at the same moment and fall back to the backend database, creating a sudden spike in database load and causing increased latency and poor user experience.

The most effective fix that preserves freshness is to introduce jitter —a small, randomized variance—into the TTL values so cached objects do not all expire at the same time. With TTL jitter, each item still has a bounded lifetime (so freshness is maintained), but expirations become spread out over time. That smooths cache-miss rates and prevents synchronized regeneration, reducing bursts of database traffic. This is a common best practice in high-load caching systems precisely to avoid mass expiration events.

Option A (increase TTL) might reduce how frequently a stampede occurs, but it does not solve the root cause: keys can still align and expire together, and a longer TTL can also reduce freshness if product data changes. Option B (more replicas, disable cluster mode) changes topology and read scaling, but it does not prevent synchronized expiry or the resulting backend spike; disabling cluster mode could also reduce scale for large keyspaces. Option D (more shards) can improve cache throughput capacity, but it does not address the core issue that backend load spikes occur when items expire simultaneously; lowering replica count could even reduce read availability.

Therefore, C is the correct solution: keep TTL-based freshness, but add a randomized component (for example, TTL = baseTTL + random(0..jitter)) so expirations are distributed and the backend database is protected from sudden bursts.

AWS SAM CLI is the correct tool for local Lambda testing with realistic event payloads. The developer can use sam local generate-event s3 put to create a sample S3 PutObject event and then pass that event to sam local invoke to run the Lambda function locally. This avoids deploying to production or manually constructing event JSON. Uploading an object to S3 will invoke a Lambda function configured in AWS, not a local function. The aws lambda invoke command invokes a deployed Lambda function, not a local one. The AWS Management Console also tests deployed functions, not local code. AWS SAM documentation confirms that sam local generate-event creates supported AWS service event payloads and sam local invoke invokes Lambda functions locally. ( AWS Documentation )

===============

The AWS AppConfig Agent Lambda extension is designed to simplify integration. It runs as a sidecar process that manages the fetching and local caching of configurations. Instead of adding complex AWS SDK code for session management (Option D), the developer simply calls a local HTTP endpoint (provided by the agent) to retrieve the config. This results in the least code change and better performance due to the agent ' s built-in caching.

The correct answer is C because for an in-place deployment on Amazon EC2 instances, AWS CodeDeploy automatic rollback works by redeploying the last known good revision when a deployment fails or when a configured monitoring alarm is triggered. AWS documentation explains that when automatic rollback is enabled, CodeDeploy creates a new deployment that uses the most recent successfully deployed application revision. This rollback deployment receives its own new deployment ID , because it is treated as a separate deployment event rather than a simple undo operation.

Option A is incorrect because CodeDeploy does not restore an Amazon S3 snapshot of the previous deployment state for EC2 in-place deployments. It redeploys the last successful revision instead. Option B describes behavior associated with blue/green deployment patterns , not in-place deployments . Route 53 alias switching and blue/green environment replacement are not how CodeDeploy handles failed validation during an EC2 in-place deployment. Option D is incorrect because CodePipeline orchestrates stages in a delivery pipeline, but it is not the service that performs the rollback behavior described here.

This distinction is important in AWS deployment design. In-place deployments update the same EC2 instances already serving the application. If validation fails, CodeDeploy does not roll traffic back through DNS or infrastructure replacement. Instead, it launches a rollback deployment of the previously successful application revision across those same instances. That behavior directly aligns with AWS CodeDeploy automatic rollback functionality for EC2/On-Premises in-place deployments.

Therefore, the correct result is that CodeDeploy redeploys the last known stable version as a new deployment , which makes C the right answer.

Secrets Management: AWS Secrets Manager is designed specifically for storing and managing sensitive credentials.

Built-in Rotation: Secrets Manager provides automatic secret rotation functionality, enhancing security posture significantly.

IAM Integration: IAM policies and roles grant fine-grained access to ECS Fargate, ensuring the principle of least privilege.

Reduced Overhead: This solution centralizes secrets management and automates rotation, reducing operational overhead compared to the other options.

Amazon CloudWatch is a service that monitors AWS resources and applications. The developer can publish custom metrics to CloudWatch that record the failures of the external payment processing API calls. The developer can configure a CloudWatch alarm to notify the existing SNS topic when the error rate exceeds 5% of the total number of transactions in an hour. This solution will meet the requirements in a near real-time and scalable way.

Amazon S3 Glacier Instant Retrieval is an archive storage class that delivers the lowest-cost storage for long-lived data that is rarely accessed and requires retrieval in milliseconds. With S3 Glacier Instant Retrieval, you can save up to 68% on storage costs compared to using the S3 Standard-Infrequent Access (S3 Standard-IA) storage class, when your data is accessed once per quarter. https://aws.amazon.com/s3/storage-classes/glacier/instant-retrieval/

Understanding Storage Requirements:

Files are large and infrequently accessed, but need to be available within minutes when requested in the first year.

Long-term (7-year) retention is required.

Cost-effectiveness is a top priority.

Why S3 Glacier Instant Retrieval:

Matches the retrieval requirements (access within minutes).

More cost-effective than S3 Standard for infrequently accessed data.

Simpler to use than traditional Glacier where retrievals take hours.

Why S3 Glacier Deep Archive:

Most cost-effective S3 storage class for long term archival.

Meets the 7-year retention requirement.

S3 Lifecycle Policy:

Automate the transition from Glacier Instant Retrieval to Glacier Deep Archive after one year.

Optimize costs by matching storage classes to access patterns.

Comprehensive Detailed and Lengthy Step-by-Step Explanation with All AWS Developer References:

1. Understanding the Use Case:

The developer needs to export DynamoDB table data into Amazon S3 buckets using the AWS CLI, and some exports are failing. Proper credentials and permissions have already been configured.

2. Key Conditions to Check:

Region Consistency:DynamoDB exports require that the target S3 bucket and the DynamoDB table reside in the same AWS Region. If they are not in the same Region, the export process will fail.

Point-in-Time Recovery (PITR):PITR is not required for exporting data from DynamoDB to S3. Enabling PITR allows recovery of table states at specific points in time but does not directly influence export functionality.

DynamoDB Streams:Streams allow real-time capture of data modifications but are unrelated to the bulk export feature.

DAX (DynamoDB Accelerator):DAX is a caching service that speeds up read operations for DynamoDB but does not affect the export functionality.

3. Explanation of the Options:

Option A: " Ensure that point-in-time recovery is enabled on the DynamoDB tables. " While PITR is useful for disaster recovery and restoring table states, it is not required for exporting data to S3. This option does not address the export failure.

Option B: " Ensure that the target S3 bucket is in the same AWS Region as the DynamoDB table. " This is the correct answer. DynamoDB export functionality requires the target S3 bucket to reside in the same AWS Region as the DynamoDB table. If the S3 bucket is in a different Region, the export will fail.

Option C: " Ensure that DynamoDB streaming is enabled for the tables. " Streams are useful for capturing real-time changes in DynamoDB tables but are unrelated to the export functionality. This option does not resolve the issue.

Option D: " Ensure that DynamoDB Accelerator (DAX) is enabled. " DAX accelerates read operations but does not influence the export functionality. This option is irrelevant to the issue.

4. Resolution Steps:

To ensure successful exports:

Verify the Region of the DynamoDB tables:

Check the Region where each table is located.

Verify the Region of the target S3 buckets:

Confirm that the target S3 bucket for each export is in the same Region as the corresponding DynamoDB table.

If necessary, create new S3 buckets in the appropriate Regions.

Run the export command again with the correct setup:

aws dynamodb export-table-to-point-in-time \

--table-name < TableName > \

--s3-bucket < BucketName > \

--s3-prefix < Prefix > \

--export-time < ExportTime > \

--region < Region >

This solution will meet the requirements by ensuring that all traffic between users and CloudFront, and all traffic between CloudFront and the web application, are encrypted using HTTPS protocol. The Origin Protocol Policy determines how CloudFront communicates with the origin server (the web application), and setting it to “HTTPS Only” will force CloudFront to use HTTPS for every request to the origin server. The Viewer Protocol Policy determines how CloudFront responds to HTTP or HTTPS requests from users, and setting it to “HTTPS Only” or “Redirect HTTP to HTTPS” will force CloudFront to use HTTPS for every response to users. Option A is not optimal because it will use AWS KMS to encrypt traffic between CloudFront and the web application, which is not necessary or supported by CloudFront. Option C is not optimal because it will set the origin’s HTTP port to 443, which is incorrect as port 443 is used for HTTPS protocol, not HTTP protocol. Option E is not optimal because it will enable the CloudFront option Restrict Viewer Access, which is used for controlling access to private content using signed URLs or signed cookies, not for encrypting traffic.

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and consistent performance with seamless scalability. The developer can create a DynamoDB table and configure the table with a primary key that consists of the title as the partition key and the release year as the sort key. This will enable querying for a given title and release year efficiently. The developer can also create a global secondary index that uses the genre as the partition key and the title as the sort key. This will enable querying for a given genre efficiently. The developer can store additional properties about the cast and production crew as attributes in the DynamoDB table. These attributes can have different data types and structures, and they do not need to be consistent across items.

The CloudWatch PutMetricData API is the direct mechanism for publishing custom application metrics. For 1-second granularity, the metric must be published as a high-resolution metric by setting StorageResolution to 1. Dimensions provide name-value pairs that identify and organize metrics, such as service name, tenant, environment, or operation type. X-Ray is used for distributed tracing, not for storing CloudWatch custom metrics. ECS Container Insights provides container-level observability but is not the cleanest way to publish arbitrary custom metrics with 1-second resolution from application code. ECS Exec is for interactive command execution in containers and is not a monitoring pipeline. AWS CloudWatch documentation confirms that custom high-resolution metrics can be stored at 1-second resolution and published through PutMetricData. ( AWS Documentation )

===============

To measure how long an application spends calling downstream AWS services (for example, DynamoDB, S3, SNS, etc.) in a distributed system, the most effective AWS-native approach is AWS X-Ray with appropriate instrumentation. X-Ray provides distributed tracing by capturing end-to-end request paths and breaking each request into segments and subsegments with precise timing information. When the application is instrumented with the X-Ray SDK, client handlers/interceptors automatically create subsegments for calls to AWS services, recording latency, response status, and error/throttle indicators.

This directly satisfies the requirement: determine the length of time of calls to various downstream services. In the X-Ray trace map and trace details, the developer can see per-service timing, identify which dependency is slow, and distinguish application processing time from downstream call time. This is specifically designed for performance bottleneck analysis and root cause investigation across distributed components.

Option A (VPC Flow Logs) captures network flow metadata (source/destination, ports, bytes, accept/reject), not application-level request timing to AWS service APIs, and it won’t show the latency breakdown per downstream service call.

Option B can work only if the application is already logging detailed timing for each call, but this is manual, inconsistent across services, and does not give a unified distributed trace view. It is also higher effort than using standard tracing instrumentation.

Option C increases CloudWatch metric granularity for EC2 but does not show per-request downstream service call durations.

Therefore, implementing AWS X-Ray with client handlers is the correct solution.

Amazon ElastiCache is a service that offers fully managed in-memory data stores that are compatible with Redis or Memcached. The developer can create an ElastiCache for Redis instance and enable encryption of data in transit and at rest. This will ensure that the PHI is encrypted at all times. The developer can store frequently accessed data in the cache and use Redis features such as sorting and ranking to enhance the performance of the application.

Amazon API Gateway is a service that enables developers to create, publish, maintain, monitor, and secure APIs at any scale. Amazon CloudWatch is a service that monitors AWS resources and applications. API Gateway provides several CloudWatch metrics to help developers troubleshoot issues with their APIs. Two of the metrics that can help the developer troubleshoot the issue of API Gateway timing out are:

IntegrationLatency: This metric measures the time between when API Gateway relays a request to the backend and when it receives a response from the backend. A high value for this metric indicates that the backend is taking too long to respond and may cause API Gateway to time out.

Latency: This metric measures the time between when API Gateway receives a request from a client and when it returns a response to the client. A high value for this metric indicates that either the integration latency is high or API Gateway is taking too long to process the request or response.

The issue occurs because the SSM Parameter Store parameters are managed by CloudFormation as stack resources. When CloudFormation performs a stack update, it will attempt to ensure the deployed resources match the template. If the template includes a parameter value, CloudFormation can overwrite the current value during updates, which explains why the application’s runtime modifications are lost.

The developer’s requirement is to continue deploying the stack (including adding resources/tags) without resetting parameter values that are modified outside CloudFormation. The lowest-effort way to do this is to prevent CloudFormation from updating those specific Parameter Store resources during stack updates.

A CloudFormation stack policy can explicitly deny update actions on selected resources (in this case, the SSM parameters). Stack policies are designed to protect critical resources from being unintentionally modified during stack updates. With an update-deny policy applied to the SSM parameter resources, CloudFormation can still update other resources (such as adding tags or creating new components), but it will not overwrite the parameter values that the application has changed.

Option A (DeletionPolicy: Retain) only affects what happens when a resource is deleted or replaced, not whether CloudFormation updates the resource in place. It will not reliably prevent stack updates from resetting values.

Options B and C are larger architecture changes and require migrating configuration storage to DynamoDB or RDS—much more development effort and operational overhead.

Therefore, applying a stack policy to deny updates on Parameter Store parameters is the best and least-effort solution.

This solution allows the developer to keep the dependencies of the Lambda functions up to date with the least additional complexity because it eliminates the need to update each function individually. A Lambda layer is a ZIP archive that contains libraries, custom runtimes, or other dependencies. The developer can create a layer that contains all of the shared dependencies and attach it to multiple Lambda functions. When the developer updates the layer, all of the functions that use the layer will have access to the latest version of the dependencies.

https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html

Global Secondary Index (GSI): GSIs enable alternative query patterns on a DynamoDB table by using different partition and sort keys.

Addressing Query Bottleneck: By making the slow-query attribute the GSI ' s partition key, you optimize queries on that attribute.

Scalability: GSIs automatically scale to handle increasing data volumes.

This solution meets the requirements because it uses a PostgreSQL-compatible database that can secure and regularly rotate database credentials without requiring additional programming overhead. Amazon Aurora PostgreSQL is a relational database service that is compatible with PostgreSQL and offers high performance, availability, and scalability. AWS Secrets Manager is a service that helps you protect secrets needed to access your applications, services, and IT resources. You can store database credentials in AWS Secrets Manager and use them to access your Aurora PostgreSQL database. You can also enable automatic rotation of your secrets according to a schedule or an event. AWS Secrets Manager handles the complexity of rotating secrets for you, such as generating new passwords and updating your database with the new credentials. Using Amazon DynamoDB for the database will not meet the requirements because it is a NoSQL database that is not compatible with PostgreSQL. Using AWS Systems Manager Parameter Store for storing and rotating database credentials will require additional programming overhead to integrate with your database.

Centralized logging for microservices means collecting application logs from many services into a single managed logging backend where logs can be searched, retained, and monitored. For containerized microservices on AWS, the standard approach is to send each service’s stdout/stderr logs to Amazon CloudWatch Logs.

Option A is the appropriate solution: create separate CloudWatch Logs streams (and typically log groups) per microservice. This scales naturally as microservices increase, supports retention policies, metric filters, alarms, and integrations with tools like CloudWatch Logs Insights for querying across services. Container orchestrators (ECS/EKS) can be configured to use the CloudWatch Logs log driver so logs are shipped automatically without custom log shipping agents.

Option B (CloudTrail) logs AWS API activity, not application logs.

Option C (VPC Flow Logs) captures network flow metadata, not application-level logs.

Option D (Cloud Map) is service discovery, not logging.

Therefore, using CloudWatch Logs streams per microservice is the correct central logging approach.

The correct answer is B because messages in an Amazon SQS queue become temporarily hidden from other consumers only for the duration of the queue’s visibility timeout . If the Lambda function is still processing a message when that visibility timeout expires, the message becomes visible again and can be received another time, which looks like the message is reappearing during processing.

AWS documentation explains that when Lambda polls SQS, the queue’s visibility timeout must be configured long enough to allow the function to finish processing and for Lambda to delete the message successfully. If the visibility timeout is too short, duplicate processing can occur even when the function is working correctly.

Option A is not the best answer because increasing the Lambda timeout alone does not prevent the message from reappearing if the SQS visibility timeout remains shorter than the processing duration. Option C could improve performance in some cases, but it does not directly address the root cause of message visibility. Option D changes how many messages are processed together, but it does not solve the issue of messages becoming visible again before processing is complete.

The key operational principle is that the SQS visibility timeout should exceed the Lambda processing time , with enough buffer for retries and deletion. This ensures that while Lambda is processing the message, other consumers do not see it again. Therefore, the correct fix is to increase the visibility timeout of the SQS queue , making B the correct answer.

AWS Secrets Manager is a service that helps securely store, rotate, and manage secrets such as API keys, passwords, and tokens. The developer can store the API credentials in AWS Secrets Manager and retrieve them at runtime by using the AWS SDK. This solution will meet the requirements of security, code management, and performance. Storing the API credentials in a local code variable or an S3 object is not secure, as it exposes the credentials to unauthorized access or leakage. Storing the API credentials in a DynamoDB table is also not secure, as it requires additional encryption and access control measures. Moreover, retrieving the credentials from S3 or DynamoDB may affect application performance due to network latency.

The solution that will meet the requirements most cost-effectively is to store the smart meter readings in an Amazon DynamoDB table. Create a composite key by using the location ID and timestamp columns. Use the columns to filter on the customers’ data. This way, the company can leverage the scalability, performance, and low latency of DynamoDB to store and retrieve the smart meter readings. The company can also use the composite key to query the data by location ID and timestamp efficiently. The other options either involve more expensive or less scalable services, or do not provide low-latency access to the current usage.

Amazon DynamoDB is a fully managed NoSQL database service that can store and retrieve any amount of data with high availability and performance. DynamoDB can handle concurrent requests from multiple IoT devices without throttling or data loss. To prevent duplicate requests from causing inconsistencies or data loss, the Lambda function can use DynamoDB conditional writes to check if the unique identifier for each request already exists in the table before processing the request. If the identifier exists, the function can skip or abort the request; otherwise, it can process the request and store the identifier in the table. Reference: Using conditional writes

Amazon Cognito user pools is a service that provides a secure user directory that scales to hundreds of millions of users. The developer can use Amazon Cognito user pools to manage user accounts and create an Amazon Cognito user pool authorizer in API Gateway to control access to the API. The developer can use the Lambda function to store the photos in Amazon S3, which is a highly scalable, durable, and secure object storage service. The developer can store the object’s S3 key as part of the photo details in the DynamoDB table, which is a fast and flexible NoSQL database service. The developer can retrieve previously uploaded photos by querying DynamoDB for the S3 key and fetching the photos from S3. This solution will meet the requirements with the least operational overhead.

The requirement is to search for partial matches of email_address but scoped to a specific customer_type. In DynamoDB, efficient partial matching is performed with a Query on a sort key using the begins_with() condition. However, Query requires that the partition key be specified exactly, so we need an index where customer_type can be used as the partition key, and email_address can be used as the sort key for prefix matching.

A Global Secondary Index (GSI) can be added to an existing table without recreating it, and it can use a different partition key and sort key from the base table. Option A correctly proposes a GSI with:

Partition key: customer_type

Sort key: email_address

Then the Lambda can run a Query on the GSI like: customer_type = :ct AND begins_with(email_address, :prefix) which returns emails that start with the typed prefix for that customer type.

Option B is wrong because it keeps email_address as the partition key. That would require an exact email value (not a prefix) to Query, and you cannot do begins_with on a partition key; begins_with is for sort keys.

Options C and D are invalid because Local Secondary Indexes (LSIs) must share the same partition key as the base table (here, email_address). You cannot create an LSI with customer_type or job_title as the partition key when the table partition key is email_address.

Therefore, adding a GSI (customer_type PK, email_address SK) and querying it with begins_with is the correct solution.

AWS Lambda automatically integrates with Amazon CloudWatch Logs, but logging only works if the function’s execution role has the correct IAM permissions . AWS documentation states that Lambda functions require permissions for logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents to successfully publish log entries.

In this scenario, CloudWatch metrics show errors, which confirms that the function is executing. The absence of logs despite logging statements in the code strongly indicates a missing IAM permission issue , not a runtime or tracing issue.

CloudWatch Lambda Insights (Option B) provides performance metrics but does not enable basic logging. AWS X-Ray (Option C) provides distributed tracing but does not replace CloudWatch Logs. Option D is invalid because CloudWatch does not assume roles to collect logs.

AWS documentation explicitly identifies missing log permissions as the most common cause of absent Lambda logs. Therefore, granting the Lambda execution role the appropriate CloudWatch Logs permissions resolves the issue.

Configuring the Lambda function to use ephemeral storage and processing data in the /tmp directory improves performance by leveraging local storage during execution.

Why Option C is Correct:

Ephemeral Storage: Lambda provides temporary storage (up to 10 GB) in the /tmp directory for each invocation, which is faster than pulling data directly from S3 multiple times.

Performance Boost: Data can be downloaded to /tmp, processed locally, and uploaded to the destination S3 bucket, minimizing S3 network calls.

Low Overhead: This approach requires only minimal changes to the function ' s configuration.

Why Not Other Options:

Option A: Using Amazon EFS adds complexity and is unnecessary for this use case.

Option B: Scheduling the function does not address the root cause of slow performance.

Option D: Lambda layers improve deployment efficiency, not runtime performance for this scenario.

Using Ephemeral Storage in AWS Lambda

Best Practices for S3 and Lambda Performance

The requirement has two parts: (1) authenticate users with a third-party SAML IdP , and (2) after authentication, allow those users to access AWS services like Amazon S3 and DynamoDB. The AWS pattern for this is to federate the external identity into AWS and then exchange that identity for temporary AWS credentials .

Amazon Cognito identity pools are designed to provide AWS credentials to authenticated users (via AWS STS) so the users can call AWS services directly or through an application backend. Identity pools support federation with external identity providers, including SAML 2.0 . When a user authenticates with the third-party SAML IdP, the identity pool can accept the SAML assertion, map the user to an IAM role, and return temporary, scoped credentials (AccessKeyId/SecretAccessKey/SessionToken) associated with that role. Those credentials can be restricted using IAM policies to only the required S3 buckets, DynamoDB tables, and actions, satisfying least privilege.

Option A is incorrect because a Cognito user pool is primarily a user directory and OIDC/OAuth provider for application authentication; while user pools can integrate with SAML IdPs for federation, user pools alone do not directly issue AWS service credentials. The key requirement here is access to S3/DynamoDB, which is the role of an identity pool . Option C is not appropriate because IAM is not intended to provide end-user sign-up/sign-in for external users; it is for AWS identities and permissions. Option D is unrelated: CloudFront signed URLs control access to CloudFront-distributed content and do not authenticate users with SAML or provide AWS credentials.

Therefore, B meets both requirements: federate SAML authentication through a Cognito identity pool and provide temporary AWS credentials for accessing S3 and DynamoDB.

Amazon API Gateway has a hard integration timeout that determines how long it waits for a backend response. If the backend (Lambda) does not respond within this time, API Gateway returns an HTTP 504 error to the client.

In this scenario, the Lambda function timeout is longer (20 seconds) than the API Gateway integration timeout (15 seconds). AWS documentation states that API Gateway will terminate the request once its timeout is exceeded, even if Lambda continues executing successfully. This explains why there are no Lambda errors despite 504 responses.

Increasing the Lambda timeout (Option B) does not help because API Gateway times out first. Reserved concurrency (Option A) and throttling limits (Option D) are unrelated to request duration.

The correct solution is to increase the API Gateway integration timeout so that it exceeds the maximum expected Lambda execution time. This ensures API Gateway waits long enough for the Lambda response.

Therefore, increasing the API Gateway timeout prevents HTTP 504 errors.

https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-integrating-user-pools-with-identity-pools.html

In DynamoDB, a ConditionalCheckFailedException occurs when an UpdateItem, PutItem, or DeleteItem operation includes a ConditionExpression that evaluates to false for the target item at the time of the write. This is expected behavior: DynamoDB uses conditional expressions for optimistic concurrency control and for enforcing business rules atomically at write time.

In this scenario, the developer wants to update only items whose status is Inactive by adding an email address. The most correct way to prevent conditional failures is to ensure the update request’s condition matches the intended target state. By adding (or correcting) a condition expression such as #st = :inactive (with expression attribute names/values), the update will proceed only when the item’s status is actually " Inactive " . Items that are " Active " will be skipped by design rather than causing unexpected failures in the workflow.

Option B checks whether the email attribute exists, but that does not enforce the key business rule (“only inactive items”) and may still fail depending on whether the attribute is present or absent across items. Option C (retry on ConditionalCheckFailedException) is not appropriate: the failure is not transient like throttling; it indicates the condition was not met, and retrying will likely fail again unless the item changes state. Option D is unrelated because email format validation is not what triggers DynamoDB conditional failures; the exception is about the conditional expression not matching item state.

Therefore, the correct fix is A : update the request’s conditional expression to explicitly check that status equals " Inactive " before applying the update. This ensures only the intended items are modified and eliminates unnecessary conditional failures.

Amazon API Gateway supports multiple stages , allowing developers to deploy and test different versions of an API independently. By creating a new test stage , the developer can route traffic to an updated Lambda function without impacting production users.

AWS documentation recommends using stage variables to dynamically reference different Lambda function versions or aliases. This approach enables safe testing while reusing the same API configuration.

Canary deployments (Option A) expose a portion of production users to the new code, which violates the requirement. Changing the endpoint type (Option B) disrupts production. Duplicating the entire stack (Option D) introduces unnecessary complexity and overhead.

Using a separate test stage is the most efficient, low-risk, and AWS-recommended solution.

Why Option D is Correct:When using a container-based AWS Lambda function, you are responsible for updating the base image for runtime patches. Rebuilding the container with the latest Node.js patch version ensures the function is updated with the required security patches. Publishing a new version of the Lambda function makes the updated image available for use.

Why Other Options are Incorrect:

Option A: The runtime update mode applies to functions using AWS-managed runtimes, not container-based runtimes.

Option B: Redeploying the same version of the Lambda function does not apply the security patch.

Option C: Rebuilding with the AWS OS base image does not guarantee that the latest Node.js patch version is included.

AWS Documentation References:

Lambda Function Container Images

Node.js Updates in AWS Lambda

The safest way to prevent cross-tenant data leakage during processing is to enforce tenant isolation at the authorization layer , not only in application logic. AWS supports this with ABAC (attribute-based access control) using IAM principal/session tags and policy condition keys. The goal is to ensure that, for each invocation, the function can access only the S3 prefix and DynamoDB items that match the tenant being processed.

First, the Lambda execution role should be permitted to assume a dedicated data access role (B). This creates a clear separation: the execution role has minimal base permissions and can obtain tenant-scoped permissions only by assuming the data role.

Second, the Lambda function should assume that data access role with the tenant name as a session tag and then use the temporary credentials for all S3/DynamoDB calls (F). Session tagging ties the caller’s identity attributes (tenant) to the credentials used for data access.

Third, attach policies to the data access role that restrict access using conditions that compare the session tag to the requested resource attributes (C). For S3, policies can restrict access to object ARNs like arn:aws:s3:::bucket/${aws:PrincipalTag/tenant}/*. For DynamoDB, policies can restrict access by partition key using dynamodb:LeadingKeys so the role can read/write only items whose partition key equals the tenant tag. This ensures that even if the function code has a bug or receives unexpected input, AWS authorization prevents it from reading or writing another tenant’s data.

Option A is not required as stated; you typically need permission to pass session tags (and the trust/policy must allow tagging), but the key actions here are: enable assume role (B), enforce tag-based data policies (C), and actually assume the role with tenant tag (F). Option D is not generally the primary control for DynamoDB; the standard enforcement is via IAM identity policies (and dynamodb:LeadingKeys). Option E (RCP) is an AWS Organizations guardrail and is not necessary for this single-application isolation pattern.

Because the Lambda function is successfully triggered by the S3 event notification, the invocation path (S3 → Lambda) is working correctly. The failure occurs specifically when the function tries to write to DynamoDB, which strongly indicates an authorization problem rather than an invocation, scaling, or infrastructure issue.

In AWS, a Lambda function interacts with other services by using its execution role (an IAM role). AWS documentation explains that a Lambda function must have explicit IAM permissions to call downstream services such as DynamoDB. To write items, the role typically needs actions like dynamodb:PutItem (and sometimes dynamodb:UpdateItem, dynamodb:BatchWriteItem, depending on code behavior) on the target table resource ARN. If these permissions are missing or scoped incorrectly, DynamoDB returns an AccessDeniedException (or similar) and the function fails at the write step.

Option A is unlikely because exceeding concurrency would typically prevent invocation or cause throttling at the Lambda service level, not selectively fail only at DynamoDB write time after the function begins executing.

Option B is incorrect: DynamoDB does not require a GSI to support writes. GSIs are for alternate query access patterns, not mandatory for write operations.

Option D is incorrect because DynamoDB is a regional service, not tied to a single Availability Zone, and Lambda does not need to be “in the same AZ” to access it.

Therefore, the most likely cause is that the Lambda execution role lacks the necessary IAM permissions to perform DynamoDB write operations.

The correct answer is D because Amazon API Gateway REST APIs support canary deployments for stages , which allow a developer to send a controlled percentage of production traffic to a new API deployment while the rest of the traffic continues to use the current deployment. Setting the canary percentage to 20% directly satisfies the requirement to route 20% of traffic to the new release and 80% to the existing production release.

This is the best approach because API Gateway canary deployments are specifically designed to reduce the blast radius of new releases in production. AWS documentation explains that canary releases enable testing of a new deployment with a subset of client traffic before promoting it fully. Since the canary runs within the same production stage , this minimizes the number of errors experienced by any single customer compared to less controlled alternatives. It is also cleaner than routing users to the testing stage, because a testing stage often has different configuration, data, or dependencies and is not intended to serve production traffic.

Option A is incorrect because partially deploying only some planned changes is not a safe traffic-routing strategy. Option B is incorrect because weighted Route 53 routing between production and testing stages does not provide the same controlled deployment semantics and may send the same customer to inconsistent backends. Option C is incorrect because placing an ALB in front of API Gateway is unnecessary and not the intended deployment pattern for API Gateway stage traffic shifting.

Therefore, API Gateway stage canary settings are the AWS-native solution that best meets the requirement.

This solution will most likely solve the issues because it will grant the IAM user the necessary permission to access the DynamoDB table using the AWS CLI command. The error message indicates that the IAM user does not have sufficient access rights to perform the scan operation on the table. Option A is not optimal because it will change the command to use put-item instead of scan, which will not achieve the desired result of getting data from the table. Option B is not optimal because it will involve contacting AWS Support, which may not be necessary or efficient for this issue. Option C is not optimal because it will state that DynamoDB cannot be accessed from the AWS CLI, which is incorrect as DynamoDB supports AWS CLI commands.

This is a classic cross-account S3 access requirement: EC2 instances in Account A must read from a private S3 bucket in Account B without making the bucket public.

The correct pattern is to grant access using IAM + S3 bucket policy while keeping the bucket private. In Account B, you create an IAM role that has the necessary S3 read permissions (such as s3:GetObject and potentially s3:ListBucket depending on access needs). That is Option A.

However, permissions on the role alone are not sufficient, because the S3 bucket is in a different account and is private by default. AWS requires that the bucket owner explicitly grants access to the external principal. This is done by adding a bucket policy in Account B that allows the principal (either the role in Account A or a role session via STS) to access the bucket objects. That is Option D.

Option B is not correct in the “select two” sense because adding permissions to Account A’s instance profile role does not, by itself, grant access to a bucket owned by Account B. You still need the bucket policy or another resource-based policy from the bucket owner.

Option C violates the requirement (“without exposing the S3 bucket to anyone else”). Making the bucket public is unnecessary and insecure.

Option E is incorrect because a trust policy controls who can assume a role (sts:AssumeRole), not what S3 permissions the role has. Also, trust policies do not grant s3:Get* access.

Therefore, create an IAM role with S3 read permissions in Account B and grant access via the Account B bucket policy.

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and consistent performance with seamless scalability. DynamoDB Streams is a feature that captures data modification events in DynamoDB tables. The developer can enable DynamoDB Streams on the table and create a trigger to connect the DynamoDB stream to the Lambda function. This solution will enable the Lambda function to detect changes to the DynamoDB table in near real time.

Requirement Summary:

Lambda function:

Retrieves an item from DynamoDB

Updates its attributes or creates it if it does not exist

Has primary key

Needs minimum required IAM permissions

Analysis of Required Permissions:

To get an item and update it or create it if it doesn ' t exist, the Lambda function must use the **PutItem** or **UpdateItem** API, and read with **GetItem**.

Valid API options:

GetItem: Read the item from the table.

UpdateItem: Update existing item attributes or insert if it doesn ' t exist (with UpdateExpression and ConditionExpression).

When UpdateItem is used without a conditional check for existence, it can create a new item if it does not exist (acts like upsert).

DescribeTable: (Optional) Used if you need table metadata (not strictly required here).

Evaluate the Choices:

Option A:

DeleteItem – Not needed

GetItem –

PutItem – (can create/replace but not partial update)

Close, but PutItem overwrites the full item, not update-in-place. Acceptable, but UpdateItem is better suited.

Option B:

UpdateItem – Required to modify attributes or insert new item

GetItem – Required to check existence or read data

DescribeTable – Optional, but not harmful

BEST FIT – Matches the update-or-create logic.

Option C:

GetRecords – This is used for DynamoDB Streams, not standard GetItem

PutItem –

UpdateTable – Used to change table settings, not data manipulation

Incorrect usage context

Option D:

UpdateItem, GetItem, PutItem – all valid

But UpdateItem alone is sufficient; including PutItem might not be necessary Also, image is faded (possibly invalid), and it ' s redundant

UpdateItem API: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html

PutItem vs UpdateItem: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html

IAM actions for DynamoDB: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html

The requirement is specifically encryption at rest for messages stored in Amazon SQS. The AWS-native way to accomplish this is to enable server-side encryption (SSE) on the SQS queue . When SSE is enabled, SQS encrypts messages as they are stored and decrypts them when they are retrieved, using keys from AWS Key Management Service (AWS KMS) (either an AWS managed key for SQS or a customer managed KMS key). This provides transparent encryption at rest without requiring application-level cryptography changes.

Option C correctly states to enable SSE on the queue. Once enabled, any message content placed in the message body will be protected at rest in SQS. (Message attributes are also stored by SQS; however, the key requirement is to ensure the messages are encrypted at rest, and enabling SSE at the queue level is the control that enforces this.)

Option A (aws:SecureTransport) enforces encryption in transit by requiring HTTPS/TLS, not encryption at rest. It is a good security control, but it does not satisfy the at-rest requirement by itself. Option B is incorrect because SSE is not something the sender “sets within the message”; SSE is configured on the queue, not per-message by the microservices. Option D suggests putting sensitive data in attributes, which does not add security; it can actually increase exposure because attributes are often used for routing/filters and may be logged or surfaced in monitoring. The right pattern is to keep sensitive data where intended and rely on queue-level SSE to encrypt stored messages.

Therefore, enabling SQS SSE on the queue (C) meets the requirement to ensure messages are encrypted at rest while stored in SQS.

S3 Glacier Instant Retrieval is designed for long-lived data that is rarely accessed but requires millisecond retrieval when needed (meeting the " instant access " requirement for the first 90 days). After 90 days, moving to S3 Glacier Flexible Retrieval (formerly Standard) is more cost-effective because it has lower storage costs, though it has retrieval times of minutes to hours (meeting the " more than 10 minutes " requirement).

For service-to-service calls inside AWS, the simplest and most secure way to authenticate a caller (Lambda) to an API Gateway HTTP API is to use IAM authorization . When IAM auth is enabled on a route, API Gateway requires requests to be signed with AWS Signature Version 4 (SigV4) . The calling Lambda function can sign the request using the AWS SDK (or SigV4 utilities) and its execution role credentials .

With this approach, you grant the Lambda function’s execution role explicit permission to invoke the API by allowing the execute-api:Invoke action on the API’s ARN. API Gateway then evaluates the SigV4-signed request against IAM to decide whether to authorize the call. This creates a clean, auditable permission model and avoids embedding static secrets.

Option A is incorrect and overly complex: JWT authorizers are typically used for end-user or workload identities from an OIDC/JWT provider; creating an IAM IdP is not how you enable JWT authorizers for HTTP APIs, and it does not directly solve Lambda-to-API authentication. Option C (API keys) is not considered an authentication mechanism for HTTP APIs in the same way; API keys are primarily for usage plans/throttling (and are more common with REST APIs). Storing an API key in environment variables is also weaker than IAM-based, short-lived credentials. Option D is backwards: a Lambda resource-based policy controls who can invoke the Lambda function, not who can call an API Gateway endpoint.

Therefore, B is the correct solution: enable IAM authorization on the HTTP API route and grant the Lambda function’s IAM role permission to invoke the API (and sign requests with SigV4).

This solution will meet the requirements by using AWS Secrets Manager, which is a service that helps protect secrets such as database credentials by encrypting them with AWS Key Management Service (AWS KMS) and enabling automatic rotation of secrets. The developer can create an AWS Lambda function by using the SecretsManagerRotationTemplate template in the AWS Secrets Manager console, which provides a sample code for rotating secrets for RDS DB instances, Amazon DocumentDB clusters, and Amazon Aurora DB instances. The developer can also create secrets for the database credentials in Secrets Manager, which encrypts them at rest and provides secure access to them. The developer can set up secrets rotation on a schedule, which changes the database credentials periodically according to a specified interval or event. Option A is not optimal because it will set up IAM database authentication for token-based access, which may not be compatible with all database engines and may require additional configuration and management of IAM roles or users. Option B is not optimal because it will create parameters for the database credentials in AWS Systems Manager Parameter Store, which does not support automatic rotation of secrets. Option C is not optimal because it will store the database access credentials as an encrypted Amazon S3 object in an S3 bucket, which may introduce additional costs and complexity for accessing and securing the data.

AWS CodeBuild integrates natively with AWS Secrets Manager , allowing secrets to be securely injected into build environments without being exposed in logs. When referenced using the secrets-manager mapping in the env section of buildspec.yml, CodeBuild automatically retrieves and decrypts the secret at runtime.

AWS documentation states that Secrets Manager provides encryption at rest using AWS KMS, fine-grained IAM access control, and automatic rotation support. Secrets retrieved this way are masked in build logs by default, satisfying the requirement that secrets do not appear in logs.

Parameter Store (Option C) can store encrypted values, but Secrets Manager is AWS’s preferred service for managing secrets, especially when rotation and auditing are required. Options B and D introduce unnecessary steps and higher operational overhead.

Therefore, Secrets Manager with CodeBuild environment variables is the most secure and operationally efficient solution.

A ThrottlingException indicates that calls to an AWS service are being rate limited. The correct developer response is to use SDK retry behavior with backoff rather than scaling the application servers blindly. Boto3 supports retry modes, including adaptive retry mode, which adjusts client-side request rates based on throttling errors, exceptions, or HTTP status codes returned by AWS services. Increasing Elastic Beanstalk instance count or size can actually worsen throttling by producing more calls to SQS. Changing programming language is irrelevant. Adaptive retry mode is specifically intended to handle throttling more gracefully by slowing requests and retrying failed API calls. AWS SDK documentation describes adaptive retry mode as modifying rate-limit variables based on error responses and using those variables to calculate the next call rate. ( AWS Documentation )

===============

AWS Secrets Manager is purpose-built for storing, retrieving, and rotating secrets such as database credentials. For supported databases, Secrets Manager can rotate credentials automatically and update both the stored secret and the database credentials. That directly addresses the risk: credentials are stored securely, access is controlled by IAM, and rotation is automated. Systems Manager Parameter Store can securely store parameters, but it does not provide the same managed database credential rotation workflow. Rotating a KMS key is not the same as rotating database credentials; it only changes encryption key material behavior, not the database password. S3 is not the right service for active secrets management. AWS documentation recommends moving hardcoded database credentials to Secrets Manager and rotating them. ( AWS Documentation )

===============

Distributed Tracing with X-Ray: X-Ray helps visualize request paths and identify bottlenecks in applications distributed across Regions.

Region Annotations (Automatic for AWS Services): X-Ray automatically adds a Region annotation to segments representing calls to AWS services. This aids in tracing cross-Region traffic.

Region Annotations (Manual for User-Defined): For segments representing calls to user-defined services in different Regions, the developer needs to add the Region annotation manually to enable comprehensive tracing.

If a bucket policy denies delete operations for all principals, but objects are still being removed, the most likely cause is S3 Lifecycle configuration. Lifecycle expiration is an S3-managed action that deletes objects automatically based on rules (such as “expire after N days”). These deletions occur as part of the S3 service’s lifecycle management and are not “someone calling DeleteObject” in the usual way from an IAM principal. As a result, developers often observe objects disappearing even though bucket policies deny deletes.

Therefore, to prevent additional deletions, the developer should review and remove (or modify) any Lifecycle rules that expire or transition/delete objects. This directly stops S3 from automatically deleting the log files.

Option A would not help if the policy already denies deletes and no explicit allow is causing the issue. Also, a deny overrides allow anyway.

Option C is unrelated: access points do not bypass bucket policies.

Option D is unlikely and not the primary control plane mechanism for automated S3 deletions. EventBridge can trigger workflows, but the direct, common AWS-native mechanism for periodic deletion is Lifecycle expiration.

Therefore, removing S3 Lifecycle expiration rules prevents further deletions.

The correct answers are D and E .

The requirement states that the company does not want to manage the underlying hosts . That means the containerized application should run on AWS Fargate , which is the serverless compute engine for Amazon ECS. With Fargate, AWS manages the underlying infrastructure, so the company does not need to provision, patch, or scale EC2 instances. To run a task on Fargate, the task definition must specify FARGATE in the requiresCompatibilities field. That is why D is correct.

The developer also needs to monitor CPU and memory utilization in the Amazon CloudWatch console . For ECS tasks on Fargate, the task definition must specify valid CPU and memory values. These values define the task’s resource allocation and enable ECS and CloudWatch to report utilization metrics against those configured resources. Therefore, E is also required.

Option A applies to ECS on EC2, where the company would manage cluster instances, which violates the requirement. Option B is unnecessary because ECS and CloudWatch already provide the needed service metrics without requiring a custom script. Option C is incorrect because the task does not need cloudwatch:GetMetricData permission merely for CloudWatch to display CPU and memory utilization metrics.

This design follows AWS best practices for running containers without host management while still gaining built-in observability. By selecting Fargate and defining the CPU and memory values in the task definition, the application can run serverlessly on ECS and expose the required utilization metrics in CloudWatch.

Therefore, the correct combination is D and E .

AWS CodeBuild supports parallel test execution through batch builds and multiple compute environments. This feature allows a single CodeBuild project to divide test workloads across multiple isolated environments that run concurrently. Each environment executes a subset of the test suite, significantly reducing total build time.

AWS documentation emphasizes using native CodeBuild capabilities to minimize operational complexity. Parallel execution eliminates the need to manually manage infrastructure, test orchestration logic, or EC2 fleets. CodeBuild automatically provisions and terminates build environments, scales as needed, and integrates seamlessly with CI/CD pipelines.

Options A and D require manual coordination and infrastructure management, increasing operational overhead. Option C does not address the performance problem.

Therefore, using CodeBuild’s parallel compute environments is the most efficient and AWS-recommended approach.

Why Option A is Correct:Auto-scaling with a target utilization ensures the DynamoDB table dynamically adjusts capacity based on workload, maintaining high performance while optimizing cost. Setting a reasonable target utilization minimizes overprovisioning and throttling risks.

Why Other Options are Incorrect:

Option B: On-demand capacity is costlier than provisioned throughput for predictable workloads.

Option C: Using manual CloudWatch alarms and Lambda for scaling is less efficient and adds operational overhead.

Option D: DAX accelerates read performance but does not improve write performance.

AWS Documentation References:

DynamoDB Auto Scaling

Step 1: Understanding the Requirements

Best Practices for Security:

Minimize the use of hardcoded credentials or long-lived access keys.

Use IAM roles for EC2 instances to securely grant permissions to applications running on the instance.

Access Scope: The application needs read-only access to an S3 bucket.

Step 2: Solution Analysis

Option A:

Define an IAM policy with the required s3:GetObject permissions.

Attach this policy to an IAM role.

Assign the role to the EC2 instance profile.

This approach follows security best practices by eliminating the need for static credentials and using temporary, scoped credentials provided by the instance profile.

Correct option.

Option B:

IAM groups are used for organizing users, not for EC2 instances or instance profiles.

Not suitable.

Option C:

IAM users are associated with specific individuals or applications and require static credentials.

This violates security best practices for temporary credentials and roles.

Not suitable.

Option D:

IAM web identity federation is used for applications that authenticate users via third-party identity providers.

This is unnecessary for EC2 instances and does not align with the requirements.

Not suitable.

Step 3: Implementation Steps

Create an IAM Policy:

Grant read-only access to the S3 bucket:

json

Copy code

{

" Version " : " 2012-10-17 " ,

" Statement " : [

{

" Effect " : " Allow " ,

" Action " : " s3:GetObject " ,

" Resource " : " arn:aws:s3:::your-bucket-name/* "

}

]

}

Attach the Policy to an IAM Role:

Create an IAM role and attach the policy to the role.

Associate the Role with the EC2 Instance:

Attach the role to the instance profile used by the EC2 instance.

AWS Developer References:

IAM Roles for Amazon EC2

Amazon S3 Permissions Reference

Comprehensive and Detailed Explanation (250–300 words) From Exact Extract of AWS Developer Documents:

AWS Secrets Manager is designed to securely store, rotate, and manage sensitive information such as API keys, database credentials, and tokens. A core feature of Secrets Manager is secret versioning , which enables recovery from failed or partial rotation events. Each secret version is associated with staging labels , most notably AWSCURRENT and AWSPREVIOUS .

According to AWS documentation, during a successful rotation, Secrets Manager creates a new secret version and assigns it the AWSCURRENT label, while the previous version is retained with the AWSPREVIOUS label. Applications that retrieve secrets typically reference the secret using the AWSCURRENT label. If a rotation fails after updating the secret value but before synchronizing the change with the external system, authentication failures can occur.

AWS explicitly states that in such scenarios, customers can restore service quickly by moving the AWSCURRENT label back to the previous version . This rollback capability allows applications to immediately resume using the last known valid credentials without modifying application code, redeploying resources, or interacting with external systems.

This approach represents the least operational overhead because it is a metadata-only operation within Secrets Manager. No new secrets are created, no Lambda functions are invoked, and no manual updates are required in the external REST services. Additionally, AWS recommends postponing troubleshooting until service availability is restored, which aligns precisely with the requirement in this scenario.

Other options introduce unnecessary complexity, increased risk of human error, and longer recovery times. Therefore, rolling back to the last working secret version is the fastest, safest, and AWS-recommended solution.

This solution will meet the requirements by using AWS X-Ray to analyze and debug the performance issues with the distributed Lambda applications. AWS X-Ray is a service that collects data about requests that the applications serve, and provides tools to view, filter, and gain insights into that data. The developer can use AWS X-Ray to identify the root cause of the performance issues by examining the segments and errors that show the details of each request and the components that make up the applications. Option A is not optimal because it will use logging statements and Amazon CloudWatch, which may not provide enough information or visibility into the distributed applications. Option B is not optimal because it will use AWS CloudTrail, which is a service that records API calls and events for AWS services, not application performance data. Option D is not optimal because it will use Amazon Inspector, which is a service that helps improve the security and compliance of applications on Amazon EC2 instances, not Lambda functions.

Amazon ElastiCache for Memcached is a fully managed, multithreaded, and scalable in-memory key-value store that can be used to cache frequently accessed data and improve application performance1. By using Amazon ElastiCache for Memcached, the developer can reduce the load on the main database and handle high traffic surges more efficiently.

To use Amazon ElastiCache for Memcached, the developer needs to create a cache cluster with one or more nodes, and configure the application to store and retrieve data from the cache cluster2. The developer can use any of the supported Memcached clients to interact with the cache cluster3. The developer can also use Auto Discovery to dynamically discover and connect to all cache nodes in a cluster4.

Amazon ElastiCache for Memcached is compatible with the Memcached protocol, which means that the developer can use existing tools and libraries that work with Memcached1. Amazon ElastiCache for Memcached also supports data partitioning, which allows the developer to distribute data among multiple nodes and scale out the cache cluster as needed.

Using Amazon ElastiCache for Memcached is a simple and effective solution that meets the requirements with the least complexity. The developer does not need to change the database schema, migrate data to a different service, or use a different caching model. The developer can leverage the existing Memcached ecosystem and easily integrate it with the application.

This solution will meet the requirements by using AWS Encryption SDK, which is a client-side encryption library that enables developers to encrypt and decrypt data using data encryption keys that are protected by AWS Key Management Service (AWS KMS). The SDK encrypts the data encryption key with a customer master key (CMK) that is managed by AWS KMS, and stores it (encrypted) as part of the returned ciphertext. The developer does not need to keep track of the data encryption keys used to encrypt data, as they are stored with the encrypted data and can be retrieved and decrypted by using AWS KMS when needed. Option A is not optimal because it will require manual tracking of the data encryption keys used for each data object, which is error-prone and inefficient. Option C is not optimal because it will store the data encryption keys automatically in Amazon S3, which is unnecessary and insecure as Amazon S3 is not designed for storing encryption keys. Option D is not optimal because it will store the data encryption key in the user data for the EC2 instance, which is also unnecessary and insecure as user data is not encrypted by default.

This is a feature flag / dynamic configuration requirement: enable a new feature for a subset of users (premium customers), toggle it on/off quickly based on feedback/performance, and deploy configuration changes safely with validation and without disruption. AWS AppConfig (part of AWS Systems Manager) is designed for exactly this use case.

AWS AppConfig helps create, manage, and deploy application configurations, including feature flags, in a controlled way. It supports configuration validators (such as JSON schema or Lambda validators) to catch errors before deployment. It also supports controlled rollouts with deployment strategies to reduce blast radius (for example, gradual deployments). This allows rapid changes without redeploying code and minimizes disruption.

Option A aligns perfectly: use AppConfig feature flags to target premium users and toggle the feature quickly.

Option B is incorrect because Secrets Manager is for sensitive secrets (passwords, API keys), not feature flag management and progressive configuration deployments.

Option C is incorrect because AWS Config evaluates resource compliance and records configuration changes of AWS resources; it does not serve runtime feature flag delivery.

Option D (Parameter Store) can store configuration values, but it does not provide the same feature-flag-focused capabilities, validation/deployment strategies, and safe rollout controls that AppConfig provides. Also, “lifecycle rules” is not how Parameter Store toggles features.

API Gateway Stage Variables: These are designed for configuring dynamic values for your APIs in different deployment stages (dev, test, prod). Here ' s how to use them for third-party endpoints:

In the API Gateway console, access the " Stages " section of your API.

For each stage, create a stage variable named something like thirdPartyEndpoint.

Set the value of this variable to the actual endpoint URL for that specific environment.

When configuring API requests within your API Gateway method, reference this endpoint using ${stageVariables.thirdPartyEndpoint}.

Why Stage Variables Excel Here:

Environment Isolation: This approach keeps the endpoint configuration specific to each deployment stage, ensuring the right endpoints are used during development, testing, and production cycles.

Ease of Management: You manage the endpoints directly through the API Gateway console without additional infrastructure.

On Amazon ECS, the fundamental scheduling unit is a task , which is launched from a task definition . A single task definition can include multiple containers that are intended to run together (often called a “sidecar” pattern). When two containers must share data locally —such as an application container writing log files and a separate log/metrics collector container reading those files—the recommended approach is to place both containers in the same task definition and use a shared task volume .

ECS supports defining volumes at the task level (for example, a Docker volume or bind mount depending on the launch type and configuration), and then mounting that volume into multiple containers inside the same task. Because the containers are co-located by ECS scheduling (same task, same underlying host or Fargate environment), they can safely share the mounted directory for file-based handoff. This design keeps the containers tightly coupled for lifecycle management (start/stop together) and avoids cross-task coordination complexity.

Options A and D refer to “pod specifications,” which are Kubernetes concepts, not ECS-native constructs (unless using ECS with EKS/Kubernetes, which is not stated). Option B is not feasible because ECS does not mount a single shared local volume across two separate tasks in the general case; separate tasks can be placed on different hosts, and task-scoped volumes are not shared between tasks by default. If cross-task sharing were required, you would typically use a network filesystem (like EFS) or an external log pipeline (CloudWatch Logs, FireLens, etc.), but the requirement explicitly says each application container needs to share data with another container, which aligns with the sidecar-in-same-task pattern.

Therefore, the correct solution is C : define both containers in one ECS task definition and mount a shared volume into both containers.

This solution allows the developer to test the changes without affecting the production environment. Cloning an API creates a copy of the API definition that can be modified independently. The developer can then add request validation to the new API and test it using a testing tool. After verifying that the changes work as expected, the developer can apply the same changes to the existing API and deploy it to production.

Comprehensive Detailed and Lengthy Step-by-Step Explanation with All AWS Developer References:

1. Understanding the Use Case:

The company wants to gradually release a new feature to 15% of users to perform testing. AWS AppConfig is designed to manage and deploy configurations, including feature flags, allowing controlled rollouts.

2. Key AWS AppConfig Features:

Feature Flags: Enable or disable features dynamically without redeploying code.

Variants: Define different configurations for subsets of users.

Targeting Rules: Specify rules for which users receive a particular variant.

3. Explanation of the Options:

Option A: " Set up a custom script within the application to randomly select 15% of users. Assign a flag for the new feature to the selected users. " While possible, this approach requires significant operational effort to manage user selection and ensure randomness. It does not leverage AWS AppConfig ' s built-in capabilities, which increases overhead.

Option B: " Create separate AWS AppConfig feature flags for both groups of users. Configure the flags to target 15% of users. " Creating multiple feature flags for different user groups complicates configuration management and does not optimize the use of AWS AppConfig.

Option C: " Create an AWS AppConfig feature flag. Define a variant for the new feature, and create a rule to target 15% of users. " This is the correct solution. Using AWS AppConfig feature flags with variants and targeting rules is the most efficient approach. It minimizes operational overhead by leveraging AWS AppConfig ' s built-in targeting and rollout capabilities.

Option D: " Use AWS AppConfig to create a feature flag without variants. Implement a custom traffic splitting mechanism in the application code. " This approach requires custom implementation within the application code, increasing complexity and operational effort.

4. Implementation Steps for Option C:

Set Up AWS AppConfig:

Open the AWS Systems Manager Console.

Navigate to AppConfig.

Create a Feature Flag:

Define a new configuration for the feature flag.

Add variants (e.g., " enabled " for the new feature and " disabled " for no change).

Define a Targeting Rule:

Use percentage-based targeting to define a rule that applies the " enabled " variant to 15% of users.

Targeting rules can use attributes like user IDs or geographic locations.

Deploy the Configuration:

Deploy the configuration using a controlled rollout to ensure gradual exposure.

AWS CodeArtifact emits events when repository actions occur, such as publishing a new package. AWS documentation recommends Amazon EventBridge as the native service for routing AWS service events to targets with minimal configuration and no infrastructure to manage.

By creating an EventBridge rule that matches CodeArtifact package publication events and routing those events directly to an Amazon SNS topic , the developer can notify the team immediately. SNS provides built-in email subscriptions, retries, and delivery guarantees without custom code.

Option C is the most operationally efficient because it uses fully managed, serverless services and requires no custom compute, code maintenance, or orchestration. EventBridge directly supports SNS as a target, making the configuration straightforward.

Option A is invalid because CodeArtifact does not directly publish notifications to SNS topics. Options B and D introduce unnecessary complexity by adding Lambda or Step Functions and Amazon SES, increasing operational overhead without added value.

Therefore, using EventBridge to route CodeArtifact events to SNS is the AWS-recommended and simplest solution.

The sensitive information is appearing because Step Functions logging is including execution data, such as input and output passed between states. Changing the logging level to ERROR or FATAL reduces the categories of events captured but does not specifically prevent sensitive execution payloads from being included when events are logged. Disabling X-Ray tracing does not solve CloudWatch Logs exposure because tracing and logging are separate configurations. The correct CloudFormation change is to set IncludeExecutionData to false in the Step Functions logging configuration. AWS Step Functions documentation states that includeExecutionData determines whether execution data is included in logs, and when it is set to false, that data is excluded. ( AWS Documentation )

===============

Because the developer cannot change the legacy application code, the solution must apply controls at the logging layer . CloudWatch Logs provides data protection policies that can automatically detect sensitive data using managed data identifiers (including credit card data) and apply masking (de-identification) as log events are ingested. This ensures that sensitive values such as card numbers and verification codes are not displayed in plaintext to general viewers of the log group.

With option A, enabling a data protection policy on the log group and configuring it to mask the relevant credit card data ensures that when support staff query or view logs, the sensitive fields appear redacted. CloudWatch Logs also supports controlled access to view the original unmasked values through an explicit permission: users who have the appropriate IAM authorization (such as logs:Unmask) can retrieve or view the sensitive data, while everyone else sees only the masked version. Granting logs:Unmask to application administrators satisfies the requirement that administrators can access the sensitive data, while withholding it from support staff enforces the restriction.

Option B (KMS encryption) provides encryption at rest for the log group but does not prevent authorized readers from seeing sensitive data once decrypted. Support staff who can read logs would still see plaintext card data. Option C is not a standard or operationally efficient pattern for CloudWatch Logs redaction; Macie is primarily for discovering sensitive data in S3 and does not serve as the native masking mechanism for CloudWatch Logs ingestion. Option D is not applicable: AWS WAF inspects HTTP requests/responses at the edge or load balancer/API layer, not application log streams already being emitted to CloudWatch.

Therefore, A is the correct solution: use CloudWatch Logs data protection to mask sensitive data by default and grant logs:Unmask only to administrators.

API Gateway Stages: Stages in API Gateway represent distinct environments (like PROD and DEV) allowing different configurations.

Stage Variables: Stage variables store environment-specific information, including Lambda function aliases.

Ease of Management: This solution offers a straightforward way to manage different Lambda function versions across environments.

In AWS Lambda, CPU power scales proportionally with the memory configuration. Lambda does not let you directly set “CPU cores” as a standalone setting in the general case; instead, increasing the function’s configured memory increases the CPU allocation (and other resources such as network throughput) available to the function. Therefore, to reduce latency caused by insufficient CPU, the developer should increase the function’s memory setting.

Option B directly addresses the CPU limitation in the supported Lambda configuration model. This is a common performance tuning approach: raise memory, benchmark, and find the optimal cost/performance point.

Option A is not the right lever for most Lambda functions because Lambda compute is configured via memory (and architecture), not by directly raising a “vCPU quota” per function in a typical tuning workflow.

Option C increases /tmp storage capacity and helps when dealing with large temporary files, not CPU availability.

Option D increases the maximum runtime allowed per invocation, but it does not give the function more CPU and will not reduce latency caused by CPU starvation.

Therefore, increasing the allocated memory is the correct way to increase CPU for a Lambda function.

Amazon Q Developer Pro is an AWS-native, generative AI–powered development assistant designed to help developers write, test, and review code directly within supported IDEs such as Visual Studio Code and JetBrains. AWS documentation highlights Amazon Q Developer Pro as a productivity tool that accelerates development without requiring additional infrastructure .

Amazon Q Developer Pro can automatically generate unit tests , suggest improvements, identify potential bugs, and provide context-aware code reviews . Because it integrates directly into the IDE, developers receive immediate feedback during development, which shortens feedback loops and improves overall code quality.

Options A, B, and C require additional tooling, scripting, or manual processes. While CodeBuild and CodeGuru Reviewer are valuable services, they introduce pipeline complexity and do not provide real-time, IDE-integrated assistance for writing tests and reviewing code.

Amazon Q Developer Pro uniquely satisfies all stated requirements:

No infrastructure to manage

Native IDE integration

Automated unit test generation

AI-assisted code reviews

Therefore, using Amazon Q Developer Pro is the most efficient and modern AWS-recommended solution.

To add a caching layer for frequently requested data (such as “most viewed products”), the AWS-native choice is Amazon ElastiCache, commonly using Redis for low-latency key/value caching, counters, sorted sets, and leaderboard-like patterns. Redis is particularly well-suited for ecommerce “top N” or popularity queries because it supports atomic increments and sorted sets, enabling efficient ranking updates.

Option B correctly introduces an ElastiCache (Redis OSS) cluster and updates the application to read from Redis first (cache-aside or write-through patterns) instead of hitting the RDS MySQL cluster for every request. This offloads read pressure from the database, reduces latency, and improves overall throughput.

Option A is not a valid RDS feature: you do not add a “cache node” to an RDS MySQL cluster as part of RDS itself.

Option C is incorrect because DAX is a caching layer specifically for DynamoDB, not for RDS MySQL.

Option D improves availability via Multi-AZ standby, but the standby is not for read scaling in standard RDS Multi-AZ (it’s primarily for failover). It does not provide a cache and does not solve the performance needs for hot reads.

When a Lambda function is configured to run inside a VPC, it receives ENIs in the selected subnets and uses those subnets’ routing to reach other networks. If the function is placed in private subnets (common when it needs to access an RDS database in private subnets), it typically does not have a direct route to the internet. As a result, outbound calls to public external APIs will fail unless the VPC provides a controlled egress path.

The standard AWS networking pattern for private-subnet internet access is a NAT gateway (or NAT instance) deployed in a public subnet , with a route from the private subnet(s) to the NAT gateway (0.0.0.0/0 → NAT). The NAT gateway then uses an internet gateway attached to the VPC to reach the public internet while keeping the Lambda function (and the RDS database) in private address space. This resolves the connectivity issue while maintaining the security posture of private subnets.

Option A is not the solution: Lambda automatically provisions ENIs for VPC-enabled functions; manually provisioning an ENI does not provide internet access. Option C (security group outbound rules) is necessary but not sufficient—security groups control allowed traffic, but without a proper route to the internet (via NAT), the packets still cannot reach external endpoints. Option D (gateway VPC endpoint) is for AWS services like S3 and DynamoDB (gateway endpoints), not for arbitrary public internet APIs, and “in a public subnet” is not how gateway endpoints are used; they are associated with route tables.

Therefore, the correct solution is B : add a NAT gateway in a public subnet and update private subnet route tables so the new Lambda function can reach external public APIs while still accessing the private RDS database.

A feature branch is a branch that is created from the main branch to work on a specific feature or task1. Feature branches allow developers to isolate their work from the main branch and avoid conflicts with other changes1. Feature branches can be merged back to the main branch when the feature or task is completed and tested1.

In this scenario, the developer needs to maintain two parallel streams of work: one for fixing and updating the current version of the application that is deployed in production, and another for developing the new version of the application. The developer can use feature branches to achieve this goal.

The developer can create a feature branch from the main branch for production bug fixes. This branch will contain the code that is currently deployed in production, and any fixes or updates that need to be applied to it. The developer can push this branch to the CodeCommit repository and use it to deploy changes to the production environment.

The developer can also create a second feature branch from the main branch for development of the new version of the application. This branch will contain the code that is under development for the new version, and any changes or enhancements that are part of it. The developer can push this branch to the CodeCommit repository and use it to test and deploy the new version of the application in a separate environment.

By using feature branches, the developer can keep the main branch stable and clean, and avoid mixing code from different versions of the application. The developer can also easily switch between branches and merge them when needed.

AWS X-Ray SDK: The primary way to enable X-Ray tracing within applications. The SDK sends data about requests and subsegments to the X-Ray daemon for service map generation.

Instrumenting All Services: To visualize a complete microservice architecture on the service map, each relevant service must include the X-Ray SDK.

The access restriction must be applied to the REST API, not merely to the static website bucket. API Gateway resource policies can control who can invoke an API and can restrict access by source IP address ranges or CIDR blocks. That directly satisfies the requirement that only computers from the corporate CIDR range can invoke the API. An S3 bucket policy would restrict access to the static website content, but the API endpoint could still be called directly unless API Gateway is also protected. An IAM service- linked role is not the correct control plane for client source IP filtering. Network ACLs apply at the subnet level inside a VPC and do not control public API Gateway invocation. AWS documentation confirms API Gateway resource policies support specified source IP address ranges. ( AWS Documentation )

===============

Comprehensive Detailed Step by Step Explanation with All AWS Developer References:

When you need to provide an AWS Lambda function access to private resources in a VPC, the most common and straightforward approach is to attach the Lambda function to a VPC via private subnets. Once the Lambda function is associated with the VPC, you need to configure appropriate security groups to control the access to the private resources.

Lambda with VPC Access: Lambda functions can be attached to private subnets in a VPC, allowing them to access resources like RDS, EC2, or internal services within that VPC.

Security Groups: A security group acts as a virtual firewall for the Lambda function, ensuring that it can access only the necessary resources and ports in the VPC.

Alternatives:

Option B involves routing traffic through a VPN, which adds unnecessary complexity and operational overhead compared to simply attaching the Lambda to the VPC.

Option C requires configuring a VPC endpoint and a NAT gateway, which can be complex and costly.

Option D refers to AWS PrivateLink, which is used to access services over private connections, but it ' s unnecessary in this scenario unless you need a cross-VPC connection.

Lambda functions in a VPC

The least implementation effort is to publish a custom CloudWatch metric from the existing Lambda function that records the number of orders in each batch, then create a CloudWatch alarm that sends a notification to the SNS topic when the metric value is 0. This avoids building a separate stream-processing pipeline or scheduled analytics job. A new Kinesis consumer and Lambda function would add unnecessary services and operational complexity. A 24-hour scheduled function is also slower than required because the notification must happen as soon as possible. Logging to Kinesis only creates more data movement and still requires separate analysis logic. CloudWatch supports custom metrics, and CloudWatch alarms can send notifications through Amazon SNS when metric thresholds are breached. ( AWS Documentation )

===============

For asynchronous Lambda invocations , AWS provides built-in failure handling options that require minimal code and minimal operational work. When an async invocation fails (after Lambda’s internal retry behavior), the event can be sent to a dead-letter queue (DLQ) so it is not lost. A DLQ is the standard mechanism for capturing events that could not be processed successfully, preserving the original payload for later inspection and reprocessing.

Using a DLQ (typically Amazon SQS or Amazon SNS ) gives durable storage of failed events and decouples failure recovery from the main execution path. The developer can later re-drive the messages by building a simple replay process, such as moving messages from the DLQ back to the original event source or invoking the function again with the stored payloads. This aligns with the requirement: “store messages that resulted in failed invocations so the application can retry later.”

Among the options, C is the only one that uses Lambda’s native async failure capture mechanism. Options A and B introduce unnecessary complexity and do not reliably store the original failed invocation payloads as a first-class workflow (CloudWatch Logs is not a message queue, and EventBridge→SNS doesn’t automatically capture only failed events from Lambda async invocations). Option D changes the architecture to an SQS pull model for the Lambda function; while valid, it is more than needed and adds design/operational considerations (polling, batching, visibility timeouts, DLQ configuration on the queue, etc.) compared with simply enabling DLQ support for async invokes.

Therefore, the least operational overhead solution is C : configure a dead-letter queue for the Lambda function’s asynchronous invocations so failed events are stored for later retry.

The AWS Serverless Application Model (AWS SAM) comes built-in with CodeDeploy to provide gradual AWS Lambda deployments1. The DeploymentPreference property in AWS SAM allows you to specify the type of deployment that you want. The Canary10Percent10Minutes option means that 10 percent of your customer traffic is immediately shifted to your new version. After 10 minutes, all traffic is shifted to the new version1. The AutoPublishAlias property in AWS SAM allows AWS SAM to automatically create an alias that points to the updated version of the Lambda function1. Therefore, option A is correct.

To meet the requirement:

Users must be able to upload (PutObject) and read (GetObject) files but not delete them.

Option D ensures users cannot delete files by omitting the s3:DeleteObject action while allowing s3:GetObject and s3:PutObject.

Option A: Includes s3:DeleteObject, which allows users to delete files and does not meet the requirement.

Option B: Contains unrelated actions like CreateBucket, which is not relevant here.

Option C: Adds s3:PutObjectRetention, which is unnecessary and does not restrict DeleteObject.

By default, an Auto Scaling group uses EC2 status checks to determine instance health. EC2 status checks confirm that an instance is running and reachable at the infrastructure level, but they do not validate that the application is healthy behind the load balancer. In this scenario, the ALB is returning HTTP 502 errors and the target group shows instances as unhealthy, meaning the application is failing health checks (or not responding correctly). However, because the Auto Scaling group is using the default EC2 health check type, it does not consider these instances unhealthy for replacement.

AWS recommends configuring the Auto Scaling group to use ELB health checks when instances serve traffic behind an ALB or NLB. With ELB health checks enabled, Auto Scaling evaluates target health as reported by the load balancer target group. If the ALB marks an instance unhealthy, the Auto Scaling group will treat that instance as unhealthy and terminate and replace it automatically, restoring capacity with healthy targets.

Why the other options are insufficient:

Cooldown period (A) affects scaling timing, not health replacement logic.

Lifecycle hook changes (B) can help with initialization timing, but they do not cause Auto Scaling to replace instances based on ALB target health unless ELB health checks are enabled.

Health check grace period (D) delays health evaluation after launch, which can reduce premature replacement, but it still won’t replace instances based on ALB target group status unless the health check type is ELB.

Therefore, switching the Auto Scaling group health check type to Elastic Load Balancing (ELB) is the correct fix.

Understand the Problem: The existing DynamoDB table has email_address as the partition key. Searching by customer_type requires a different data access pattern. We need an efficient way to query for partial matches on email_address based on customer_type.

Why Global Secondary Index (GSI):

GSIs allow you to define a different partition key and sort key from the main table, enabling new query patterns.

In this case, having customer_type as the GSI ' s partition key lets you group all emails with the same customer type together.

Using email_address as the sort key allows ordering within each customer type, facilitating the partial matching.

Querying the GSI:

You ' ll perform a query operation on the GSI, not the original table.

Use the begins_with key condition expression on the GSI ' s sort key (email_address) to find partial matches as the user types in the customer_type field.

Amazon S3 Glacier storage classes are designed for cost-effective archival with varying retrieval times. S3 Glacier Instant Retrieval provides millisecond access , making it suitable for workloads that require immediate access but at a lower cost than S3 Standard.

For the first 90 days, instant access is required, which rules out S3 Glacier Deep Archive and S3 Glacier Flexible Retrieval as primary storage because they have minutes-to-hours retrieval times. After 90 days, the requirement allows retrieval times exceeding 10 minutes, making S3 Glacier Flexible Retrieval appropriate.

Option D uses Instant Retrieval initially and transitions to Flexible Retrieval, optimizing both performance and cost. EFS and EBS (Options A and C) are significantly more expensive for large objects and are not intended for massive archival workloads. Option B reverses the access requirements and is invalid.

AWS documentation explicitly recommends using S3 lifecycle policies to transition objects between Glacier storage classes based on access requirements.

Therefore, Option D is the most cost-effective and AWS-aligned solution.

Amazon RDS for MySQL supports read replicas, which are copies of the primary database instance that can handle read-only queries. Read replicas can improve the read performance of the database by offloading the read workload from the primary instance and distributing it across multiple replicas. To use read replicas, the application code needs to be modified to direct read queries to the URL of the read replicas, while write queries still go to the URL of the primary instance. This solution requires less current and future effort than using a multi-AZ deployment, which does not provide read scaling benefits, or using open source replication software, which requires additional configuration and maintenance. Reference: Working with read replicas

To meet the requirement for encryption " at rest, " you must enable Server-Side Encryption (SSE) on the SNS topic (Option A). To ensure encryption " in transit, " you must enforce HTTPS. The aws:SecureTransport global condition key checks if the request was made over SSL/TLS. Adding a Deny statement where aws:SecureTransport is false (Option E) effectively mandates that only encrypted connections are allowed to publish to the topic.

AWS CloudFormation is a service that allows developers to model and provision AWS resources using templates. A CloudFormation template can define the load test resources, such as EC2 instances, load balancers, and Auto Scaling groups. A CloudFormation stack set is a collection of stacks that can be created and managed from a single template in multiple Regions and accounts. The AWS CLI create-stack-set command can be used to create a stack set from a template and specify the Regions where the stacks should be created. Reference: Working with AWS CloudFormation stack sets

The X-Ray daemon is a software that collects trace data from the X-Ray SDK and relays it to the X-Ray service. The X-Ray daemon can run on any platform that supports Go, including Linux, Windows, and macOS. The developer can install and run the X-Ray daemon on the on-premises servers to capture and relay the data to the X-Ray service with minimal configuration. The X-Ray SDK is used to instrument the application code, not to capture and relay data. The Lambda function solutions are more complex and require additional configuration.

Comprehensive and Detailed Step-by-Step Explanation:

Option D: AWS AppConfig with CloudWatch Application Signals

AWS AppConfig is designed for managing and deploying application configurations dynamically, without redeployment.

CloudWatch Application Signals provide automatic rollback mechanisms in case of an unhealthy application state due to bad configuration changes.

This solution meets the requirements with minimal operational overhead by ensuring both dynamic updates and rollback functionality.

Why Other Options Are Incorrect:

Option A and B: AWS Secrets Manager is designed for secrets management, not dynamic application configuration. Custom Config rules add unnecessary complexity.

Option C: While CloudWatch alarms can monitor application changes, using alarms for rollback requires manual setup and lacks the automatic rollback provided by Application Signals.

Centralized Logging Benefits: Centralized logging is essential for operational visibility in scalable systems, especially those using multiple EC2 instances like our e-commerce website. CloudWatch provides this capability, along with other monitoring features.

CloudWatch Agent: This is the best way to send custom application logs from EC2 instances to CloudWatch. Here ' s the process:

Install the CloudWatch agent on each EC2 instance.

Configure the agent with a configuration file, specifying:

Which log files to collect.

The format in which to send logs to CloudWatch (e.g., JSON).

The specific CloudWatch Logs log group and log stream for these logs.

Viewing and Analyzing Logs: Once the agent is pushing logs, use the CloudWatch Logs console or API:

View and search the logs across all instances.

Set up alarms based on log events.

Use CloudWatch Logs Insights for sophisticated queries and analysis.

The requirement is to keep profile pictures private in S3 while allowing the browser to display them each time an employee logs in. The standard AWS pattern is to store objects in a private bucket and provide time-limited access through S3 presigned URLs . A presigned URL grants temporary permission to perform a specific operation (such as GET) on a specific object, and it expires automatically after a configured duration. This prevents public access while still allowing simple browser retrieval.

Option D is the viable long-term solution because it stores only the S3 object key (a stable identifier) in DynamoDB and generates a fresh presigned URL at login time . This is important because presigned URLs expire; storing a presigned URL (option A) would eventually store an expired URL and force extra complexity to refresh records. Generating a new presigned URL when needed ensures the link is always valid and keeps the expiration window tight, which improves security.

Option B is not appropriate for employee browsers in general: a VPC endpoint is for traffic from resources inside a VPC (EC2, Lambda in VPC, etc.). Employee browsers on the public internet cannot use a private VPC endpoint to reach S3. Option C is not viable for “no size limit” images: DynamoDB has strict item size limits, base64 inflates data size, and storing large binary blobs in DynamoDB is inefficient and expensive compared to S3.

Therefore, D best meets the requirement: keep images private in S3, store the S3 key in DynamoDB, and generate a presigned URL on each login to provide secure, temporary access for display.

Using Amazon ElastiCache for Memcached to store and manage the session data will reduce the memory load and improve the performance of the web server. Using Amazon RDS for MySQL DB instance to store the application data will provide a scalable, reliable, and managed database service. Option A is not optimal because it does not address the memory issue of the web server. Option C is not optimal because it does not provide a persistent storage for the application data. Option D is not optimal because it does not provide a high availability and durability for the session data.

The requirement is encryption in transit for sensitive data sent in API calls between two Apache-based EC2 fleets in peered VPCs . The most operationally efficient approach is to restrict network access and rely on standard TLS at the application layer. Among the provided options, the only operationally simple and directly relevant network control is security group referencing across VPC peering within the same account and Region.

By creating security groups that allow inbound traffic only from the other fleet’s security group , the developer ensures that only the intended instances can communicate over the required ports (for example, 443 for HTTPS). This is operationally efficient because it avoids managing IP allowlists that change with Auto Scaling and keeps the trust boundary tied to instance membership rather than addresses. It also supports least privilege by limiting which sources can reach the service.

Why the other options are not the best fit:

B (Site-to-Site VPN) is unnecessary for VPC peering in the same account/Region and adds significant operational overhead. It also does not replace the need for TLS at the application layer to guarantee encryption to the endpoint.

C (EBS encryption) addresses encryption at rest on volumes, not encryption in transit between fleets.

D (Nitro Enclaves) is heavy and unrelated to the core requirement; enclaves protect data-in-use and do not replace standard TLS for network encryption.

Important nuance: Security groups alone do not encrypt traffic; encryption is achieved by using HTTPS/TLS between the Apache services. However, option A is the most operationally efficient control offered here to implement secure connectivity between the fleets (paired with using HTTPS on Apache, which is the standard for encrypting API calls).

Therefore, A best meets the requirement with the least operational complexity.

The correct answer is B because Amazon S3 event notifications can directly invoke an AWS Lambda function whenever a supported event occurs, such as ObjectCreated . This is the simplest and most infrastructure-efficient design for processing files that are uploaded to an S3 bucket. Since the requirement is to invoke the function with the least amount of AWS infrastructure , using the native direct integration between S3 and Lambda is the best choice.

AWS documentation explains that S3 can publish event notifications for object-level operations and send those notifications directly to Lambda. This allows the developer to build an event-driven workflow in which each newly uploaded project status file automatically triggers processing logic. There is no need for polling, scheduled scans, or intermediary messaging services unless there are additional requirements such as buffering, fan-out, or decoupling.

Option A is incorrect because polling the bucket every 5 minutes with EventBridge is less efficient and adds unnecessary delay and complexity. Option C is incorrect because introducing an SNS topic adds another infrastructure component when direct invocation is already supported. Option D is also incorrect because using SQS introduces a queue and polling behavior, which increases operational overhead and infrastructure count.

The direct S3-to-Lambda pattern is a common AWS serverless best practice for file processing workloads. It minimizes moving parts, reduces latency, and simplifies permissions and maintenance. Therefore, the developer should configure an S3 event notification for object creation events to invoke the Lambda function directly.

So, B is the correct answer.

DynamoDB distributes throughput across partitions based on the hash key. A hot partition (caused by high usage of a specific hash key) can result in a ProvisionedThroughputExceededException, even if overall usage is below the provisioned capacity.

Why Option B is Correct:

Partition-Level Limits: Each partition has a limit of 3,000 read capacity units or 1,000 write capacity units per second.

Hot Partition: Excessive use of a single hash key can overwhelm its partition.

Why Not Other Options:

Option A: DynamoDB storage size does not affect throughput.

Option C: Provisioned scaling operations are unrelated to throughput errors.

Option D: Sort keys do not impact partition-level throughput.

DynamoDB Partition Key Design Best Practices

Amazon S3 performance scales automatically. Each prefix in an S3 bucket can handle at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET requests per second. There are no limits to the number of prefixes in a bucket. To increase parallel throughput, a developer should partition the data into multiple prefixes. This distributes the request load across multiple partitions of the S3 index, effectively scaling the performance of the application.

IAM Roles for EC2 (A): The most secure way to provide AWS permissions from EC2.

Create a role with a policy allowing s3:GetObject on the specific bucket.

Attach the role to an instance profile and associate that profile with your instances.

Pre-signed URLs (C): Temporary, authenticated URLs for specific S3 actions.

Modify the app to use the AWS SDK to call GeneratePresignedUrl.

Embed these URLs when a user is properly logged in, allowing download access.

This solution will meet the requirements by creating a single S3 bucket policy that denies access to the S3 bucket unless the request comes from one of the specified VPC endpoints. The aws:SourceVpce condition key is used to match the ID of the VPC endpoint that is used to access the S3 bucket. The StringNotEquals condition operator is used to negate the condition, so that only requests from the listed VPC endpoints are allowed. Option A is not optimal because it will create multiple S3 bucket policies, which is not possible as only one bucket policy can be attached to an S3 bucket. Option B is not optimal because it will use the aws:SourceVpc condition key, which matches the ID of the VPC that is used to access the S3 bucket, not the VPC endpoint. Option C is not optimal because it will use the StringNotEquals condition operator with a single value, which will deny access to the S3 bucket from all VPC endpoints except one.

The solution that will solve this problem is to create and inspect the Lambda dead-letter queue. Troubleshoot the failed functions. Reprocess the events. This way, the developer can identify and fix any issues that caused the Lambda function to fail when invoked asynchronously by API Gateway. The developer can also reprocess any orders that were not processed due to failures. The other options either do not address the root cause of the problem, or do not help recover from failures.

API Gateway Mocking: This feature is built for decoupling development dependencies. Here ' s the process:

Create resources and methods in your API Gateway.

Set the integration type to ' MOCK ' .

Define Integration Responses, mapping HTTP status codes to desired mocked responses (JSON, etc.).

Deployment and Use:

Create a deployment stage for the API.

Frontend teams can call this API and get the mocked responses without a real backend.

The destination bucket is in the development account, so the destination encryption key should also be in the development account. A customer managed KMS key is required because its key policy can be edited to allow the production account to use it for encryption during the copy operation. AWS managed keys cannot have their key policies modified to grant cross-account access in the same way. Replicating or copying a KMS key from production is not the correct model for this requirement; KMS keys are regional resources and access is controlled through key policies and IAM permissions. The best design is therefore a new customer managed key in the development account with a key policy that permits the production account to use the key for the copy.

===============

For client-side encryption with AWS KMS, the documented pattern is envelope encryption : you use KMS to generate and protect a data encryption key (DEK) , and you use that DEK locally to encrypt the actual data. This is the correct approach for large payloads (such as 10 MB documents), because the KMS Encrypt API is intended for encrypting small amounts of data (KMS is not designed to directly encrypt multi-megabyte application payloads).

With envelope encryption, the application calls GenerateDataKey on AWS KMS, specifying the KMS key (customer managed key) to use. KMS returns two versions of the DEK in the response:

a plaintext DEK (usable immediately by the application for local cryptographic operations), and

a ciphertext (encrypted) DEK that is encrypted under the specified KMS key.

The application then uses the plaintext DEK to encrypt the 10 MB document on the client side (for example, using an authenticated encryption mode such as AES-GCM via a standard crypto library). After encryption completes, the application must not persist the plaintext DEK; instead, it stores the encrypted document alongside the ciphertext DEK . Later, to decrypt, the application sends the ciphertext DEK to KMS using Decrypt to recover the plaintext DEK, and then decrypts the document locally.

Therefore, option D is correct because it explicitly uses GenerateDataKey and the plaintext DEK to encrypt the data, which is the required envelope-encryption flow. Options A, B, and C do not follow the correct KMS envelope-encryption process for large client-side payloads.

This solution will meet the requirements with the least operational overhead because it uses Amazon S3 as a scalable, secure, and durable storage service for the reports. The presigned URL will allow customers to access their reports for a limited time (8 hours) without requiring additional authentication. The S3 Lifecycle configuration rules will automatically delete the reports that are older than 2 days, reducing storage costs and complying with the data retention policy. Option A is not optimal because it will incur additional costs and complexity to store the reports as DynamoDB items, which have a size limit of 400 KB. Option B is not optimal because it will not provide customers with access to their reports within one hour, as Amazon SNS email delivery is not guaranteed. Option D is not optimal because it will require more operational overhead to manage an RDS database and a Lambda function for storing and deleting the reports.

Why Option C is Correct:Amazon Verified Permissions provides fine-grained access control capabilities, making it ideal for managing complex user permissions. It integrates with OIDC IdPs for authentication and allows applications to request authorization decisions dynamically. It is also easily adaptable to newer applications.

Why Other Options are Incorrect:

Option A: Cognito identity pools do not natively support fine-grained permission analysis or management.

Option B: Managing permissions in application logic adds significant operational overhead.

Option D: IAM roles are not designed for application-specific fine-grained access control and are more suitable for resource-level permissions.

AWS Documentation References:

Amazon Verified Permissions

S3 Object Lambda allows you to add your own code to process data retrieved from S3 before returning it to an application. You can use an AWS Lambda function to modify the data, such as removing PII, redacting confidential information, or resizing images. You can create an S3 Object Lambda access point and associate it with your Lambda function. Then, you can use the access point to request objects from S3 and get the modified data back. This way, you can maintain only one copy of the original document in S3 and apply different transformations depending on who accesses it. Reference: Using AWS Lambda with Amazon S3

For this workload, the access pattern is centered on each user’s activity history over time (the company is planning a marketing campaign based on each user’s activity). In DynamoDB, the most effective way to store and query time-ordered events per entity is to use a composite primary key where the entity identifier is the partition key and a time attribute is the sort key . Therefore, using user ID as the partition key groups all events for a given user together, and using timestamp as the sort key allows efficient retrieval in chronological order and supports range queries (for example, “activities in the last 7 days” or “between two dates”).

This design also helps maximize provisioned throughput efficiency and reduce throttling risk because it distributes data across partitions based on the partition key values (user IDs). With many users, writes and reads naturally spread across multiple partition key values rather than concentrating on a small set. The sort key further enables multiple activity records per user without overwriting items and supports precise queries without scanning.

Option B (product ID as partition key) does not align with the stated marketing need (per-user activity). It would cluster all users’ actions for a popular product into the same partition key, increasing the chance of hot partitions and throttling. Option C also risks hot partitions for popular product IDs; auto scaling helps capacity management but does not fix poor key distribution or hot-key access patterns. Option D (monotonic counter as partition key) is particularly problematic: sequential keys can create uneven distribution and a throughput bottleneck pattern, and it does not support user-centric queries efficiently.

Thus, A best matches the data model (user events over time), supports efficient queries, and reduces throttling risk by distributing workload across user IDs.

Requirement Summary:

EKS containers send logs to CloudWatch Logs

Need to process logs in real time

Trigger logic based on a specific error in logs

Evaluate Options:

Option A: SNS topic with filter policy

SNS filter policies work on message attributes, not on CloudWatch Logs subscription filters

Option B: Subscription filter on log group

This enables real-time log processing

You can create a subscription filter with a pattern matching specific error strings

Sends matched logs to a Lambda function or Kinesis

Option C: CloudWatch agent operator for trace collection

Irrelevant for log processing

Used for monitoring and tracing, not real-time log filtering

Option D: Lambda function to process logs

Once logs match the pattern, Lambda can process and act (e.g., alert, store, analyze)

Option E: EventBridge rule on a schedule

Not real-time

Scheduled EventBridge rules are for cron-like tasks, not log stream processing

Subscription filters: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html

Real-time log processing with Lambda: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#LambdaExample

Logs in EKS to CloudWatch: https://docs.aws.amazon.com/eks/latest/userguide/fargate-logging.html

This solution will limit the ability to download a premier content file in the S3 bucket to paid subscribers only because it uses a pre-signed object URL that grants temporary access to an S3 object for a specified duration. The pre-signed object URL can be generated by the company’s website when a paid subscriber requests a download, and can be verified by Amazon S3 using the signature in the URL. Option A is not optimal because it will allow anyone to download the content from the S3 bucket without verifying their subscription status. Option C is not optimal because it will require additional steps and costs to configure multi-factor authentication for accessing the S3 bucket objects, which may not be feasible or user-friendly for paid subscribers. Option D is not optimal because it will not prevent non-paying website visitors from accessing the S3 bucket objects, but only encrypt them at rest.

This solution will meet the requirements by using Amazon CloudWatch Logs to capture and analyze the logs from API Gateway. Amazon CloudWatch Logs is a service that monitors, stores, and accesses log files from AWS resources. The developer can turn on execution logging and access logging in Amazon CloudWatch Logs for the API stage, which enables logging information about API execution and client access to the API. The developer can create a CloudWatch Logs log group, which is a collection of log streams that share the same retention, monitoring, and access control settings. The developer can specify the Amazon Resource Name (ARN) of the log group for the API stage, which instructs API Gateway to send the logs to the specified log group. The developer can then examine the logs to determine the cause of the HTTP 400 response errors. Option A is not optimal because it will create an Amazon Kinesis Data Firehose delivery stream to receive API call logs from API Gateway, which may introduce additional costs and complexity for delivering and processing streaming data. Option B is not optimal because it will turn on AWS CloudTrail Insights and create a trail, which is a feature that helps identify and troubleshoot unusual API activity or operational issues, not HTTP response errors. Option C is not optimal because it will turn on AWS X-Ray for the API stage, which is a service that helps analyze and debug distributed applications, not HTTP response errors.

This solution meets the requirements in the most operationally efficient manner because it does not require any infrastructure provisioning or management. The developer can create a Lambda function that makes the API call and configure an EventBridge rule that triggers the function once a day at a designated time. This is a serverless solution that scales automatically and only charges for the execution time of the function.

The issue is write throttling during peak login surges. In DynamoDB provisioned capacity mode, throttling happens when the workload exceeds the table’s configured write capacity units (WCU) (or a partition becomes “hot”). To resolve throttling and reduce latency, the table must have sufficient write capacity available when the surge occurs.

Option B directly addresses this by increasing the table’s provisioned throughput (WCU). With more write capacity, DynamoDB can accept more writes per second without returning throttling errors, which reduces retries and improves end-user latency during peak usage.

Option E is also effective: switching the table to on-demand capacity mode automatically accommodates traffic spikes without the team needing to forecast and pre-provision capacity. On-demand is designed for unpredictable workloads and can scale to handle sudden surges, reducing the risk of throttling caused by under-provisioning. For many teams, this is the fastest operational fix because it removes manual capacity planning and reactive scaling steps.

Why the other options are not the best fit:

A (DAX) improves read performance and reduces read latency, but it does not fix write throttling .

C (retries and exponential backoff) is a best practice for handling throttling gracefully, but it does not “resolve” throttling; it reduces contention and improves success rates at the cost of higher latency, and it does not increase available capacity.

D focuses on control plane operations (schema/index/table management) which are unrelated to data plane write throttling during login surges.

Therefore, the two solutions that meet the requirements to resolve write throttling and reduce latency are B (increase provisioned throughput) and E (switch to on-demand capacity mode for automatic scaling).

The solution that will meet the requirements with the most operational efficiency is to create a new CodePipeline stage that occurs after the container image is built. Configure ECR basic image scanning to scan on image push. Use an AWS Lambda function as the action provider. Configure the Lambda function to check the scan results and to fail the pipeline if there are findings. This way, the container image is analyzed earlier in the CI/CD pipeline and any vulnerabilities are detected and reported before deploying to the EKS cluster. The other options either delay the analysis until after deployment, which increases the risk of exposing insecure images, or perform analysis on the source code instead of the container image, which may not capture all the dependencies and configurations that affect the security posture of the image.

The requirement is to analyze existing Lambda logs using a request ID that appears in both functions, and to do so with the least development effort . Amazon CloudWatch Logs Insights is purpose-built for interactive log analysis: it lets you run ad-hoc queries over CloudWatch log groups using a query language that supports filtering, parsing, sorting, and aggregation. This means you can quickly search across the relevant Lambda log groups and filter results to only entries that contain a specific request ID.

With Logs Insights, the developer can select both Lambda log groups, set a time range around the failure, and run a query such as filtering on the request ID field or matching the request ID string in the message. This provides a fast way to reconstruct the end-to-end flow and identify where the failure occurred—without writing any custom code, building data pipelines, or exporting logs.

Option A (using an AWS SDK) requires writing and maintaining code to call CloudWatch Logs APIs, handle pagination, time windows, filtering, and correlation across groups—more effort than necessary. Option B (export to S3 + Athena) adds significant setup (export tasks, S3 storage, Athena tables/partitions) and is better suited to large-scale analytics or long-term archival, not quick troubleshooting. Option D (Live Tail) is primarily for real-time streaming of new log events; it is less suitable for retrospective investigation of an incident that already happened, and it doesn’t provide the same structured querying and cross-log-group correlation capabilities as Logs Insights.

Therefore, CloudWatch Logs Insights (C) is the most direct, AWS-native, low-effort solution to query both Lambda log groups and filter by request IDs to troubleshoot the failing process flow.

In AWS X-Ray, filter expressions can filter trace data based on indexed fields that X-Ray can query efficiently. Custom data can be added to segments in two main ways: annotations and metadata. The critical difference is that annotations are indexed and can be used for filtering, while metadata is not indexed and is intended for additional diagnostic context that you do not typically query on.

Therefore, if the developer wants user-specified custom attributes to be usable in X-Ray filter expressions, the developer should record those attributes as annotations in the segment document. Once recorded as annotations, the developer can write filter expressions that match annotation keys/values and return only the relevant traces.

Option B is incorrect because metadata is not indexed and cannot be used in filter expressions for trace search the same way annotations can.

Option C is incorrect because segment documents have a defined schema; adding arbitrary “new segment fields” is not the intended method for searchable custom attributes.

Option D is unrelated: sampling rules control which requests get traced in the first place. They are not used to filter returned results by custom attributes after traces are recorded.

The correct answer is B because Amazon S3 Lifecycle rules can manage versioned objects, including noncurrent object versions . In a versioning-enabled bucket, the newest object version is the current version, and older ones become noncurrent versions. The requirement is to keep the current version and only the immediately previous version. S3 Lifecycle is the native feature designed to expire or retain noncurrent versions according to policy.

AWS documentation explains that lifecycle configuration for versioned buckets can specify how many newer noncurrent versions to retain before Amazon S3 permanently removes older noncurrent versions. This directly matches the requirement to preserve only the latest prior version while cleaning up older historical versions automatically.

Option A is incorrect because an S3 bucket policy controls access permissions, not retention behavior for object versions. Option C is incorrect because S3 Object Lock is intended for write-once-read-many retention and legal hold scenarios, not for maintaining only one previous object version. Option D is not appropriate because suspending versioning would stop creation of new full versions going forward, but it would not provide an automated retention policy for existing versions, and modifying the application adds unnecessary complexity.

Using an S3 Lifecycle rule is the most operationally efficient and AWS-native solution. It allows the bucket to continue using versioning for protection against accidental overwrites while automatically limiting retained noncurrent versions to only what the business needs. Therefore, B is the correct answer.

The correct answer is C because the API Gateway integration timeout is set to 15 seconds , while the Lambda function timeout is 20 seconds . If the Lambda function takes longer than 15 seconds to return a response, API Gateway will stop waiting and return an HTTP 504 Gateway Timeout to the client, even if the Lambda function itself has not yet timed out. This exactly matches the symptom described in the question.

The fact that there are no errors in the Lambda logs is also an important clue. If Lambda were failing internally, timing out at its own limit, or throwing exceptions, those events would typically appear in Lambda logs. Instead, the likely problem is that API Gateway is timing out first, before Lambda reaches its own timeout threshold or produces an error.

Option A is incorrect because reserved concurrency affects the number of concurrent executions available to Lambda, not the integration response wait time. Option B is incorrect because increasing the Lambda timeout beyond 20 seconds would not help if API Gateway is still configured to stop waiting after 15 seconds. Option D is incorrect because per-client throttling limits control request rates, not backend timeout behavior.

The proper fix is to increase the API Gateway integration timeout so that API Gateway can wait long enough for the Lambda function to complete. This ensures that requests that legitimately need more than 15 seconds can still return successful responses instead of 504 errors.

Comprehensive Detailed Step by Step Explanation with All AWS Developer References:

In this scenario, the developer is configuring a mock integration in API Gateway. The integration request mapping template allows you to map the incoming request data to a format that the API expects. For mock integration, it ' s common to return specific HTTP status codes based on the conditions.

Using $context.integration.status: The $context.integration.status variable refers to the status of the API Gateway integration, which is useful for generating responses based on the condition. Option D correctly uses this variable to determine the HTTP status code, returning 200 for a successful mock request or 500 for a failure.

Alternatives:

Options A, B, and C do not use the correct context variables for handling mock integrations. These options would not return the correct status codes based on the actual integration status.

API Gateway Mapping Templates and Accessing Context Variables

A canary deployment best matches the requirement to test a new feature with a small group of users while the current version remains deployed for everyone else. In a canary approach, a new application revision is released to a limited portion of traffic/users first . This allows the team to collect real user feedback and validate behavior under production-like conditions without exposing the full user base to risk.

AWS deployment guidance for progressive delivery aligns with this concept: you start by directing a small percentage of requests to the new version, monitor results (such as error rates, latency, and business outcomes), and keep the stable version handling the majority of traffic during the evaluation period. This directly satisfies the requirement that the “current software version remains deployed” while testing occurs.

Once the feature is validated, the canary strategy supports promoting the new revision to the remaining population by shifting traffic from the old version to the new version—commonly ending with a transition to 100% of users on the new version. This satisfies the requirement to deploy to “all other users at the same time” after the small-group validation step is complete.

Why the other options are less suitable:

All-at-once exposes all users immediately, so there is no limited-user validation phase.

In-place replaces the existing version on the same infrastructure, typically without maintaining a parallel stable path for a subset of users.

Linear gradually shifts traffic in fixed increments over time, rather than validating with a small group and then moving the remainder in one step.

Amazon API Gateway supports canary deployments , which are designed specifically for controlled production rollouts. Canary deployments allow a developer to direct a configurable percentage of traffic to a new deployment while the remainder continues to use the existing deployment.

AWS documentation states that canary releases help minimize customer impact by exposing only a subset of users to potential issues. Because the routing is request-based , individual users are less likely to encounter inconsistent behavior across multiple requests.

Route 53 weighted routing (Option B) operates at the DNS level and can result in users being routed unpredictably due to DNS caching. An Application Load Balancer (Option C) is not supported as a direct frontend for API Gateway stages and adds unnecessary complexity. Option A lacks traffic control guarantees.

Therefore, configuring a canary deployment on the production stage is the AWS-recommended and lowest-risk approach.

This solution will meet the requirements by creating a Lambda function execution role, which is an IAM role that grants permissions to a Lambda function to access AWS resources such as Amazon S3 objects. The developer can attach a policy to the role that grants access to specific objects in the S3 bucket that are required by the application, following the principle of least privilege. Option A is not optimal because it will hardcode the credentials that are required to access S3 objects in the application code, which is insecure and difficult to maintain. Option B is not optimal because it will create a secret access key and access key ID with permission to access the S3 bucket, which will introduce additional security risks and complexity for storing and managing credentials. Option D is not optimal because it will store the secret access key and access key ID as environment variables in Lambda, which is also insecure and difficult to maintain.

The most operationally efficient way to remove time-bound data from a DynamoDB table is to use Time to Live (TTL) . TTL is a DynamoDB feature that lets you define an attribute (typically a Unix epoch timestamp) that represents an item’s expiration time. After the timestamp has passed, DynamoDB automatically marks the item as expired and later deletes it in the background. This directly satisfies the requirement because the telemetry is only valuable for a limited time, yet it is currently stored indefinitely.

Enabling TTL (option C) improves performance and operational efficiency by preventing the table from growing without bounds. As the item count grows, access patterns that rely on scans, large partitions, or indexes can degrade, and storage-related overhead increases. TTL helps keep the dataset “fresh” by automatically removing stale telemetry, reducing the amount of data the application must work around and decreasing overall storage footprint.

Option A is operationally heavier: scanning and deleting items with a scheduled Lambda introduces ongoing maintenance, costs, and risk of throttling (table scans can be expensive and disruptive). It also requires custom logic, error handling, and retries. Option B addresses cost optimization for archived data but does not fix the DynamoDB table size or the performance degradation caused by keeping old data in the table; archiving is useful, but you still need an efficient deletion mechanism from DynamoDB. Option D (on-demand capacity mode) changes how capacity is managed, not how much data is stored; it does not remove stale items and therefore does not address the core problem.

Therefore, the best and most operationally efficient solution is C : add a TTL attribute to each telemetry item and enable TTL on the DynamoDB table so DynamoDB automatically expires and deletes old telemetry.

AWS Lambda SnapStart is designed specifically to reduce cold start latency for Java and .NET runtimes. SnapStart works by initializing the function once, taking a snapshot of the execution environment, and then reusing that snapshot for future cold starts. This dramatically reduces startup time, often from several seconds to milliseconds.

SnapStart requires the function to be published as a version , and an alias must reference that version. AWS documentation clearly states that SnapStart is the recommended solution for latency-sensitive Lambda workloads with infrequent invocations.

Reserved concurrency (Option B) limits scaling but does not eliminate cold starts. Lambda layers (Option C) improve code organization but have minimal impact on cold start latency. Adding the function to a VPC (Option D) typically increases cold start time due to network interface initialization.

Therefore, enabling SnapStart on a published .NET Lambda function is the correct and AWS-endorsed solution.

The solution that will meet the requirements is to add a second cache behavior to the distribution with the same origin as the default cache behavior. Set the path pattern for the second cache behavior to the path of the login page, and make viewer access unrestricted. Keep the default cache behavior’s settings unchanged. This way, the login page can be accessed without authentication, while all other content remains secure and requires signed cookies. The other options either do not allow unauthenticated access to the login page, or expose private content to unauthorized users.

“Encryption in transit” means the connection between the client (EC2 instances) and Amazon S3 must use TLS/HTTPS , not plain HTTP. The most direct way to enforce this at the bucket level is an S3 bucket policy that denies any request that is not using secure transport. AWS provides the global condition key aws:SecureTransport , which evaluates to true when a request is made over HTTPS and false when made over HTTP.

By adding an explicit Deny statement conditioned on aws:SecureTransport = false, the bucket rejects any insecure requests regardless of who makes them. This ensures that even if an application is misconfigured (or a user tries to access the bucket over HTTP), S3 will refuse the request. This is a strong enforcement mechanism because explicit denies in IAM policies override allows.

Option C (SSE-KMS) provides encryption at rest , not in transit. It protects objects while stored in S3 but does not force clients to use TLS for transport. Option B (VPC endpoint) can keep traffic on the AWS network path and can be combined with endpoint policies, but it does not inherently guarantee TLS usage unless you also enforce HTTPS. Option A (installing certificates) is not the mechanism for controlling whether the application uses HTTPS to S3; the S3 client uses AWS-managed TLS endpoints, and enforcement should happen through policy.

Therefore, the correct solution is D : create an S3 bucket policy that denies requests when aws:SecureTransport is false, ensuring all access uses encrypted transport (HTTPS/TLS).

The correct answer is B because Amazon EventBridge is designed for building loosely coupled event-driven architectures . In this scenario, when an order is placed, the order processing system can publish a single event to an EventBridge event bus. Then, multiple independent consumers can react to that event through separate rules and targets . This matches the requirement to update inventory, send email, notify shipping, and update order history without tightly coupling those actions together.

EventBridge is especially well suited when the company wants to add new processing steps later . A new consumer can be added simply by creating another rule and target for the existing order event, without changing the original order submission code or the existing consumers. This supports extensibility and separation of concerns, which are key goals of event-driven design.

Option A is less appropriate because a single Lambda function that directly calls every downstream system becomes tightly coupled and harder to extend. Option C supports fan-out, but EventBridge provides richer routing, filtering, and event bus semantics for enterprise event-driven workflows. Option D is useful for workflow orchestration, but it creates a more centrally orchestrated pattern rather than the looser publish-and-subscribe model requested in the question.

AWS guidance for modern event-driven architectures emphasizes publishing events and allowing interested services to subscribe independently. EventBridge provides native routing and integration with many AWS services, making it easy to evolve the architecture over time. Therefore, B is the best answer for achieving loose coupling and future extensibility.

The immutable deployment method is the best option for this scenario, because it meets the requirements of maintaining full capacity, avoiding service interruption, and minimizing the cost of additional resources.

The immutable deployment method creates a new set of instances in a separate Auto Scaling group and deploys the new version of the application to them. Then, it swaps the new instances with the old ones and terminates the old instances. This way, the application maintains full capacity during the deployment and avoids any downtime. The cost of additional resources is also minimized, because the new instances are only created for a short time and then replaced by the old ones.

The other deployment methods do not meet all the requirements:

The all at once method deploys the new version to all instances simultaneously, which causes a short period of downtime and reduced capacity.

The rolling with additional batch method deploys the new version in batches, but for the first batch it creates new instances instead of using the existing ones. This increases the cost of additional resources and reduces the capacity of the original environment.

The blue/green method creates a new environment with a new set of instances and deploys the new version to them. Then, it swaps the URLs between the old and new environments. This method maintains full capacity and avoids service interruption, but it also increases the cost of additional resources significantly, because it duplicates the entire environment.

CodeDeploy Predefined Configurations: CodeDeploy offers built-in deployment configurations for common scenarios.

Canary Deployment: Canary deployments gradually shift traffic to a new version, ideal for controlled rollouts like this requirement.

CodeDeployDefault.ECSCanary10Percent15Minutes: This configuration matches the company ' s requirements, shifting 10% of traffic initially and then completing the rollout after 15 minutes.

The requirement in this scenario is encryption in transit for sensitive data exchanged between two EC2-based application fleets. AWS best practices clearly distinguish between network isolation and transport-layer encryption . Security groups (Option A) restrict traffic but do not encrypt it. EBS encryption (Option C) protects data at rest and does not affect data transmitted over the network.

Although a Site-to-Site VPN (Option B) would encrypt traffic, AWS documentation considers this approach unnecessary and operationally heavy when both workloads run inside AWS and application-level encryption is sufficient.

The most efficient and AWS-recommended approach is to use TLS (HTTPS) for application communication. AWS Certificate Manager (ACM) allows developers to provision and manage TLS certificates without manual certificate handling. Apache can be configured to use HTTPS with ACM-issued certificates, ensuring that all API traffic between the fleets is encrypted in transit using industry-standard TLS.

AWS documentation consistently recommends TLS for service-to-service communication within AWS when sensitive data is transmitted. This approach minimizes operational overhead, avoids additional networking infrastructure, and integrates natively with existing EC2-based applications.

Therefore, using ACM-issued certificates and HTTPS for Apache communication is the correct and most efficient solution.

The UnprocessedKeys element indicates that the BatchGetItem operation did not process all of the requested items in the current response. This can happen if the response size limit is exceeded or if the table’s provisioned throughput is exceeded. To handle this situation, the developer should retry the batch operation with exponential backoff and randomized delay to avoid throttling errors and reduce the load on the table. The developer should also use an AWS SDK to make the requests, as the SDKs automatically retry requests that return UnprocessedKeys.

Comprehensive and Detailed Step-by-Step Explanation:

Option C: Use AWS CodePipeline for CI/CD Workflow:

AWS CodePipeline automates the entire CI/CD pipeline, including build, deploy, and test stages. This minimizes manual effort and integrates well with AWS services.

API Gateway Stages: Represent different environments, such as dev, test, and prod, allowing isolated deployment and testing.

AWS CloudFormation Templates: Ensure that the infrastructure for Lambda and API Gateway is consistent across environments.

AWS CodeBuild for Automated Tests: Validates the deployments in each stage, ensuring integration and functionality are tested post-deployment.

Why Other Options Are Incorrect:

Option A and B: While using AWS SAM or CloudFormation for infrastructure management is valid, these options lack the fully automated CI/CD pipeline provided by CodePipeline.

Option D: Manually invoking Lambda functions using the AWS CLI introduces operational overhead and lacks the automation provided by CodePipeline.

AWS Lambda versions and aliases are designed specifically to support safe deployments, testing, and rollback. A Lambda version is immutable, meaning its code and configuration cannot change once published. Aliases act as pointers to specific versions and can be updated instantly.

AWS documentation recommends using aliases to manage environments such as dev , test , and prod . Each environment can reference a specific Lambda version, allowing the same function codebase to be promoted across accounts with confidence. If a defect is detected in production, the alias can be quickly repointed to a previously known good version, enabling an immediate rollback without redeployment.

Options B, C, and D introduce higher operational overhead or do not provide safe rollback. Deploying separately increases risk and management effort. Lambda layers are not intended for environment promotion. Environment variables do not protect against faulty code deployments.

Therefore, using Lambda versions and aliases is the most efficient and AWS-recommended solution.

Requirement Summary:

DynamoDB Provisioned Mode

ProvisionedThroughputExceededException error occurring

App hosted on a small burstable EC2 instance

Option A: Move to a larger EC2 instance

May improve local performance, but does not solve DynamoDB provisioned throughput limits.

Option B: Increase DynamoDB RCUs

Valid: This directly increases the read throughput capacity of the table.

Helps handle more traffic and reduce throughput exceptions.

Option C: Reduce frequency via exponential backoff

Best practice: Using exponential backoff and jitter reduces request pressure and spreads retries out to avoid spiking.

Option D: Increase frequency of retries by reducing delay

Opposite of best practice. Increases load, worsening the issue.

Option E: Change to on-demand mode

Also valid in general, but question is scoped around provisioned capacity.

Since minimizing cost or workload type isn ' t mentioned, and scaling the existing model is the focus, prefer B and C.

ProvisionedThroughputExceededException: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HandlingErrors.html

Exponential backoff: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html

Capacity modes: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html

To reduce the time it takes for new Auto Scaling instances to become ready, the most effective optimization is to bake the time-consuming installation and configuration steps into a custom AMI . By creating a prebuilt AMI that already contains the application binaries, dependencies, and baseline configuration, new instances start from an image that is already near “ready to serve.” This minimizes lengthy bootstrapping and significantly shortens the time required to pass ALB health checks and enter service. Therefore, creating a prebuilt AMI (B) is a primary performance optimization for faster scaling events and lower deployment variability.

After creating the AMI, the Auto Scaling group must actually use it. Because the infrastructure is managed with AWS CloudFormation , the developer should update the launch template resource (or launch configuration equivalent) in the CloudFormation template to reference the new AMI ID. This ensures that all newly launched instances use the optimized image consistently and that the change is tracked and repeatable as part of infrastructure as code. That is option C .

The other options are less optimal for the stated goal. Installing and configuring the app at launch time via Systems Manager Run Command (D) or CloudFormation helper scripts (E) still performs the expensive work during instance initialization, which prolongs launch time and can create variance (for example, dependency download time, repo availability, or transient network slowness). Option A (Marketplace AMI) could help only if a suitable prebuilt image exists for the exact custom application—which is unlikely for a proprietary application—and it also reduces control over the build and hardening process compared to maintaining an internal golden AMI.

Therefore, the best combination is B (bake the app into a custom AMI) and C (update the CloudFormation-managed launch template to use that AMI).

For cross-account access from EC2 in Account A to a Kinesis data stream in Account B , the recommended secure pattern is to use STS AssumeRole into a role in the resource-owning account (Account B). This ensures Account B retains control over what permissions are granted to external principals and allows Account A workloads to obtain temporary credentials scoped to the required actions.

First, create an IAM role in Account B that has the necessary Kinesis read permissions (such as kinesis:GetRecords, kinesis:GetShardIterator, kinesis:DescribeStream, and related read actions as required). That corresponds to option B . This role represents the permission boundary controlled by Account B for accessing its stream.

Second, configure the role’s trust policy in Account B to allow the instance profile role (or another IAM principal) from Account A to assume it. In practice, the trust relationship is defined on the Account B role and specifies the Account A role as the trusted principal, enabling sts:AssumeRole. This corresponds to option C (the intent is “allow the instance profile role to assume the IAM role in Account B”).

Option A alone is insufficient because permissions in Account A do not grant access to resources owned by Account B without an explicit cross-account authorization path. Option D is incorrect because trust policies do not “allow reads from the stream”; they allow principals to assume roles , and permissions policies allow service actions. Option E (resource-based policy) is not the primary mechanism for Kinesis Data Streams cross-account access in this scenario compared with the standard role assumption model; the secure and common approach is to assume a role in the owning account.

Therefore, the correct actions are B (create the role with read permissions in Account B) and C (configure trust to allow Account A’s instance role to assume it).

The solution that will meet the requirements is to create an Amazon EventBridge rule that runs on a regular schedule to invoke the Lambda function. This way, the developer can use an automated and serverless way to invoke the function every 10 minutes. The developer can also use a cron expression or a rate expression to specify the schedule for the rule. The other options either involve using an Amazon EC2 instance, which is not serverless, or using environment variables or query parameters, which do not trigger the function.

For frequently accessed data that causes high RCUs and latency in DynamoDB, ElastiCache (Redis or Memcached) is the recommended solution. It sits in front of DynamoDB as a high-speed, in-memory cache. Implementing a " Cache-Aside " or " Read-Through " pattern reduces the load on DynamoDB and provides sub-millisecond response times for queries. Invalidation ensures that when vital signs are updated, the cache is refreshed, maintaining data consistency.

Why Option B is Correct:A customer-managed AWS Key Management Service (KMS) key allows for encryption at rest and provides the ability to rotate the key on demand. This ensures compliance with security requirements for key management and database encryption.

RDS integrates natively with AWS KMS, allowing the use of a customer-managed key for encrypting data at rest.

Key rotation can be managed directly in AWS KMS without needing custom solutions.

Why Other Options are Incorrect:

Option A: AWS KMS managed encryption keys (AWS-owned keys) do not support key rotation on demand.

Option C & D: Storing keys in AWS Secrets Manager with custom rotation is not a recommended approach for database encryption. AWS KMS is designed specifically for secure key management and encryption.

AWS Documentation References:

Encrypting Amazon RDS Resources

AWS Key Management Service (KMS)

The hourly scheduled batch model is causing timeouts because the function must process an ever-growing backlog in a single invocation, which can exceed AWS Lambda’s maximum 15-minute runtime. A best-practice serverless refactor is to switch from “periodic polling” to an event-driven approach where work is split into smaller, independent units that can scale horizontally.

Configuring Amazon S3 Event Notifications to invoke Lambda on each object upload turns each file into its own discrete event. Instead of one long-running invocation that scans and processes many files, Lambda executes quickly per upload and automatically scales with incoming volume (subject to concurrency and downstream limits). This directly reduces processing time per run and eliminates the backlog buildup that leads to timeouts.

The remaining requirement is preventing duplicate processing. S3 event delivery is designed to be highly reliable, and applications should be built with idempotency in mind. Recording processed identifiers (such as a transaction ID, object key + version ID, or an application-level unique ID) in Amazon DynamoDB allows the function to check whether an item has already been processed before performing writes or downstream actions. Using DynamoDB with a conditional write (for example, “insert only if not exists”) is a common pattern to ensure exactly-once effect even when events are delivered more than once.

The other options do not meet the requirements as well: running more frequently (C) or continuously polling (D) still wastes time scanning and can still create duplicate work; moving to a single EC2 instance (B) reduces elasticity and increases operational overhead, and it doesn’t inherently solve deduplication or scaling.

Therefore, A provides scalable, event-driven processing and a straightforward deduplication mechanism.

Comprehensive and Detailed Step-by-Step Explanation:

Option D: Set up Amazon S3 Caching for CodeBuild:

CodeBuild supports S3 caching to store intermediate build artifacts and dependencies. This reduces the time required to download dependencies during subsequent builds, effectively lowering costs and improving build performance.

By using S3 caching, developers can optimize costs without changing the compute type or adding complexity.

Why Other Options Are Incorrect:

Option A: CodeBuild does not have a " reserved capacity fleet " option.

Option B: AWS Lambda cannot be used as the compute mode for CodeBuild projects. CodeBuild uses its own managed build environments.

Option C: CodeBuild already operates on an on-demand basis, so this does not address the need for optimization or reduced provisioning time.

Feature flags are a classic configuration-management use case: values change over time, multiple applications share them, and clients should retrieve updates efficiently with local caching. AWS AppConfig (part of AWS Systems Manager) is purpose-built to deploy and manage application configuration and feature flags. It provides controlled rollout, validation, and centralized configuration management. For operational efficiency, AWS offers the AWS AppConfig Agent for compute environments such as EC2.

With option C, the AppConfig Agent runs on each EC2 instance and polls AppConfig on a configured interval for updates. The agent maintains a local cache and exposes the current configuration through a localhost HTTP endpoint . The application then reads the feature flag values from the local endpoint, which is fast and reduces direct calls to AWS APIs. This meets both requirements: periodic polling for new values and caching once retrieved, while minimizing application changes and centralizing operational control in AppConfig.

Option D (Parameter Store + in-memory cache) can work, but it pushes more responsibility into each application: polling logic, caching behavior, error handling, and consistency. Option A misuses Secrets Manager (intended for secrets, not dynamic flags) and adds ElastiCache operational overhead. Option B similarly adds DAX and DynamoDB infrastructure and is not a standard feature-flag pattern; it also requires the app to implement polling and caching logic, reducing operational efficiency.

Therefore, C is the most operationally efficient solution: store flags in AWS AppConfig , run the AppConfig Agent on EC2 to handle polling and caching, and have the application read flags from the agent’s localhost endpoint.

Drafts are represented by noncurrent object versions after the final version is written. They are frequently accessed for the first month, so they should remain in a frequent-access storage class during that period. After 30 days, access is rare but the drafts must still be available within minutes. S3 Glacier Instant Retrieval is designed for rarely accessed archive data that still needs millisecond retrieval, making it a better fit than Deep Archive, which is not suitable for minute-level access. The drafts must be deleted after more than 1 year, so a noncurrent version expiration action is required after that period. AWS S3 Lifecycle supports transitions for noncurrent versions and expiration of noncurrent object versions. ( AWS Documentation )

===============

Problem: Directory access without file names fails.

S3 Static Website Hosting:

Configuring S3 as a static website enables automatic serving of index.html for directory requests.

Bucket policies ensure correct access permissions.

Updating the CloudFront origin simplifies routing.

Avoiding Public Exposure: The S3 website endpoint allows CloudFront to access content without making the bucket public.

Problem: CloudFormation can ' t find the custom AMI in the target region (us-west-1) because AMIs are region-specific.

Copying AMIs:

AMIs can be copied across regions, maintaining their configuration.

This approach minimizes operational overhead as the existing CloudFormation template can be reused with a minor update.

Updating the Template:

Modify the CloudFormation template in us-west-1 to reference the newly copied AMI ' s ID in that region.

AWS Elastic Beanstalk supports several deployment policies, and in this case, the requirement is to forward a specific percentage of traffic to the new version without causing downtime. The Traffic-splitting deployment policy is the most appropriate choice.

Traffic-splitting Deployment: This deployment method allows you to gradually shift a specified percentage of incoming traffic from the old environment version to the new one. During the evaluation period, if any issues are detected, the traffic can be redirected back to the old version.

No Downtime: This method ensures no downtime since both versions of the application run concurrently, and traffic is split between them.

Alternatives:

Rolling deployments (Option A): These gradually replace instances but may result in partial downtime if some instances fail during deployment.

In-place deployments (Option C): In-place deployments replace instances without creating new ones, which can lead to downtime.

Immutable deployments (Option D): While this ensures no downtime by creating entirely new instances, it doesn ' t provide traffic splitting during the evaluation phase.

Elastic Beanstalk Deployment Policies

The goal is to identify performance bottlenecks across a Lambda function that calls a database (DocumentDB). The most operationally efficient way to pinpoint where time is being spent—without building custom logging/metrics pipelines—is to use distributed tracing . AWS X-Ray provides end-to-end request traces, timing breakdowns, and service maps that help identify whether latency is dominated by Lambda initialization, downstream calls, or database queries.

By enabling X-Ray tracing on the Lambda function, the developer can capture traces for report-generation requests and examine segments that show duration spent inside the function and in downstream dependencies. To specifically diagnose database time, the developer can add custom subsegments around DocumentDB operations (query execution, connection acquisition, cursor iteration). This produces precise timing data for each step, making it straightforward to identify slow queries, excessive connection setup time, or serialization overhead. Because X-Ray aggregates and visualizes traces, the developer can quickly compare “fast” and “slow” traces and isolate the bottleneck.

Option B focuses on errors and generic metrics dashboards; it’s useful for monitoring, but it won’t precisely attribute the extra 22+ seconds to a particular downstream call path. Option C proposes performance improvements (pooling/async), but the question asks to identify bottlenecks first, and it also requires code changes and validation without confirming the root cause. Option D requires adding detailed logging statements and then querying logs; this is more development effort and more ongoing log volume/cost than turning on X-Ray and using trace analysis, especially when the intent is bottleneck identification rather than permanent instrumentation.

Therefore, A is the best choice: enable AWS X-Ray for the Lambda function and trace DocumentDB interactions with custom subsegments to quickly and efficiently identify the specific source(s) of increased latency.