Amazon Web Services DVA-C02 AWS Certified Developer - Associate Exam Practice Test

The goal is near-real-time propagation of changes from one DynamoDB table (Accounts) to another service’s datastore (Payments) while keeping services decoupled. The simplest and most reliable DynamoDB-native change feed is Amazon DynamoDB Streams.

DynamoDB Streams captures item-level modifications (inserts, updates, deletes) in time order and makes them available as a stream of change records. A consumer (commonly an AWS Lambda function) can process stream records and apply the necessary updates to the Payments database/table (or publish events for downstream processing). This provides near-real-time updates with minimal operational overhead, strong integration, and a decoupled architecture because the Accounts service simply emits changes and does not need to call Payments synchronously.

Option A (Glue ETL) is batch-oriented and adds heavy operational complexity; it’s not the simplest nor near-real-time.

Option B introduces a cache as a synchronization mechanism, which complicates consistency and durability; caches are not ideal as the primary propagation channel.

Option C (Firehose) is designed for delivering streaming data to destinations like S3, Redshift, OpenSearch, etc., and is not the standard approach for DynamoDB-to-DynamoDB change replication.

Therefore, DynamoDB Streams is the best fit for near-real-time, decoupled updates between DynamoDB-backed microservices.

The Immutable deployment method is the best choice when a company requires minimal downtime and automatic rollback in case of a failure. Here ' s why:

In Immutable deployments, a new set of instances is launched with the updated version. These instances are tested and validated before they replace the old instances. This ensures zero downtime and immediate rollback if the deployment fails.

All at once (A) causes downtime because the update replaces all instances simultaneously.

Rolling deployments (B) update a few instances at a time, but if a failure occurs midway, downtime or partial unavailability can happen.

Snapshots (C) are not a deployment strategy in Elastic Beanstalk.

The GenerateDataKey API returns a data key that is encrypted under a symmetric encryption KMS key that you specify, and a plaintext copy of the same data key1. The data key is a random byte string that can be used with any standard encryption algorithm, such as AES or SM42. The plaintext data key can be used to encrypt or decrypt data outside of AWS KMS, while the encrypted data key can be stored with the encrypted data and later decrypted by AWS KMS1.

In this scenario, the developer needs to use the GenerateDataKey API to encrypt the PDF file so that it can be decrypted later. The developer also needs to use an AWS KMS symmetric customer managed key for encryption. To achieve this, the developer can follow these steps:

Call the GenerateDataKey API with the symmetric customer managed key ID and the desired length or specification of the data key. The API will return an encrypted data key and a plaintext data key.

Write the encrypted data key to disk for later use. This will allow the developer to decrypt the data key and the PDF file later by using AWS KMS.

Use the plaintext data key and a symmetric encryption algorithm to encrypt the PDF file. The developer can use any standard encryption library or tool to perform this operation, such as OpenSSL or AWS Encryption SDK.

Discard the plaintext data key from memory as soon as possible after using it. This will prevent unauthorized access or leakage of the data key.

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

AWS Systems Manager Parameter Store is a service that provides secure, hierarchical storage for configuration data and secrets. Parameter Store supports SecureString parameters, which are encrypted using AWS Key Management Service (AWS KMS) keys. SecureString parameters can be used to store license keys in AWS and retrieve them securely from automation scripts that run in EC2 instances or CloudFormation stacks. Parameter Store is a cost-effective solution because it does not charge for storing parameters or API calls. Reference: Working with Systems Manager parameters

AWS Lambda allocates CPU, network throughput, and other resources proportionally to the function’s configured memory . If a Lambda function is CPU-bound (common for image manipulation such as resizing and thumbnail generation) or limited by I/O throughput, increasing the configured memory often improves performance because it also increases the amount of CPU available to the function. This is a standard Lambda optimization technique: tune memory to reduce runtime and achieve a lower latency target.

In this scenario, the thumbnail generation is taking more than 2 minutes, but the requirement is to process each image in under 30 seconds. Without changing the code, the most direct lever is to increase the function’s memory setting and retest. As memory increases, Lambda provides more compute power, which can significantly speed up CPU-intensive libraries (for example, image decoding, resizing, encoding) and reduce overall execution time. Many workloads show near-linear improvements until other bottlenecks (such as downstream service latency) dominate.

Options A and B are not applicable to Lambda in this way. Lambda does not let you directly select a fixed number of vCPUs or choose an EC2 instance type such as m6a.4xlarge for a function; those are EC2 concepts, not Lambda configuration parameters. Option D (“burstable performance”) is also not a Lambda configuration model; burstable performance applies to certain EC2 instance families, not Lambda’s managed execution environment.

Therefore, the correct action is C : increase the Lambda function’s memory allocation (which also increases available CPU and throughput). This is the AWS-supported way to improve performance for compute-intensive Lambda functions and is the most likely to bring processing time down toward the 30-second requirement without code changes.

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.

The correct answer is C because reserved concurrency guarantees that a specific AWS Lambda function has access to a defined number of concurrent executions. In this scenario, the function normally runs correctly but occasionally receives a surge of up to 500 S3 object-created events per minute . Since each invocation runs for about 30 seconds , the function may need substantial concurrency during those bursts. Configuring reserved concurrency ensures that this function has dedicated execution capacity available during peak periods and is not affected by concurrency consumption from other functions in the account.

AWS documentation explains that reserved concurrency both sets the maximum concurrency for a function and reserves that capacity exclusively for the function. This is especially helpful when one function must continue operating reliably under burst traffic. Even though other functions are currently running as expected, reserved concurrency is the direct AWS mechanism to protect the processing function from account-level concurrency contention during spikes.

Option A is incorrect because the function already completes in about 30 seconds; changing timeout does not solve high-volume invocation scaling. Option B is not the best answer because adding a Lambda layer does not guarantee improved throughput or concurrency handling. Option D is incorrect because decreasing memory usually reduces available CPU and can make performance worse, which would increase the chance of delays or failures.

Therefore, the most effective approach is to configure reserved concurrency for the processing function so it can continue to run reliably during high-volume object upload periods.

Comprehensive and Detailed 250 to 300 words of Explanation (AWS-doc-aligned):

To minimize widget latency for ranking and sorting, the best fit is Amazon ElastiCache for Redis OSS because Redis provides built-in in-memory data structures specifically suited for ranking use cases, such as Sorted Sets (ZSETs) . Sorted sets maintain members in order by score, which enables fast retrieval of “top N” items and efficient re-ranking without repeatedly querying the primary database and sorting at the application tier. Memcached, by contrast, is a simpler key-value cache and does not provide comparable native ranking/sorting data structures.

To ensure data remains up to date , a write-through caching strategy is preferred. With write-through, updates are written to the cache at the same time as the system of record, so the cache reflects the latest values immediately after writes. This avoids stale rankings that can occur with lazy-loading (cache-aside), where the cache is only populated or refreshed on reads and can serve older data until expiration or explicit invalidation.

Combining Redis’s native sorted/ranking structures with write-through updates yields the least latency because the page widgets can fetch pre-ranked/pre-sorted results directly from Redis memory with minimal computation, while still maintaining freshness as new plays, likes, or album changes occur. Operationally, this pattern reduces database load, avoids repeated sorting work in the application, and provides consistently fast reads for a high-traffic page.

This solution will meet the requirements by using Amazon RDS Proxy, which is a fully managed, highly available database proxy for Amazon RDS that makes applications more scalable, more resilient to database failures, and more secure. The developer can create a proxy in Amazon RDS Proxy, which sits between the application and the DB instance and handles connection management, pooling, and routing. The developer can query the proxy instead of the DB instance, which reduces the number of open connections to the DB instance and avoids errors for too many connections. Option A is not optimal because it will create a read replica for the DB instance, which may not solve the problem of too many connections as read replicas also have connection limits and may incur additional costs. Option B is not optimal because it will migrate the data to an Amazon DynamoDB database, which may introduce additional complexity and overhead for migrating and accessing data from a different database service. Option C is not optimal because it will configure the Amazon Aurora MySQL DB instance for Multi-AZ deployment, which may improve availability and durability of the DB instance but not reduce the number of connections.

Why Option A is Correct:Creating a CloudWatch metric filter with " ERROR " as the search term ensures that occurrences of the word " ERROR " in logs are counted. An alarm can then be set to notify the SNS topic when the count exceeds 1. This is the standard approach to monitor specific patterns in CloudWatch Logs.

Why Other Options are Incorrect:

Option B: CloudWatch Logs Insights is used for querying logs manually and does not integrate directly with alarms for automated notifications.

Option C: SNS subscription filters are not a feature for filtering log patterns in CloudWatch Logs.

Option D: CloudWatch alarms do not directly include log filter patterns; a metric filter is needed to create the metric first.

AWS Documentation References:

Creating CloudWatch Metric Filters

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.

For a serverless web application that needs user registration and authentication with minimal configuration, the standard AWS solution is Amazon Cognito User Pools. User Pools provide managed user directories, sign-up/sign-in flows, MFA options, password reset, and token-based authentication (OAuth2/OIDC/JWT). This integrates naturally with API Gateway (Cognito authorizers) and Lambda.

Option A is best because it uses Cognito User Pools plus an app client and the Hosted UI, which provides ready-made sign-up/sign-in pages. Hosted UI minimizes custom UI and backend authentication code while still allowing branding customization and secure token issuance. The SPA can authenticate via Cognito, receive JWT tokens, and call API Gateway endpoints securely.

Option B (identity pool) is primarily for granting temporary AWS credentials to access AWS services directly (federation). It does not replace User Pools for user registration/login flows; typically identity pools are used in addition to user pools, not instead, and require more configuration.

Option C adds unnecessary infrastructure (EC2) and defeats the “minimize configuration” goal.

Option D is not appropriate for end-user authentication. IAM users/groups are for workforce/admin access, not for customer-facing apps.

Therefore, Cognito User Pool + Hosted UI is the minimal-configuration secure solution.

Amazon CloudWatch is a service that monitors AWS resources and applications. The developer can use CloudWatch to monitor and troubleshoot all applications from one place. To do so, the developer needs to download the CloudWatch agent to the on-premises server and configure the agent to use IAM user credentials with permissions for CloudWatch. The agent will collect logs and metrics from the on-premises server and send them to CloudWatch.

The solution that will meet the requirements is to use the AWS SDK ssm PutParameter operation in the Lambda function from the existing custom resource to store the credentials as a parameter. Set the parameter value to reference the new credentials. Set the parameter type to SecureString. This way, the developer can store the API credentials with minimal operational overhead, as AWS Systems Manager Parameter Store provides secure and scalable storage for configuration data. The SecureString parameter type encrypts the parameter value with AWS Key Management Service (AWS KMS). The other options either involve adding additional resources to the CloudFormation template, which increases complexity and cost, or do not encrypt the parameter value, which reduces security.

Comprehensive and Detailed 250 to 300 words of Explanation (AWS-doc-aligned):

The most operationally efficient way to share and patch common dependencies across multiple Lambda functions is to use AWS Lambda layers . A Lambda layer is an independently managed deployment artifact that can contain libraries and other dependencies. Multiple functions can reference the same layer, which avoids packaging identical open source modules into each function bundle.

When a vulnerability or bug is found in a shared module, you patch it once by publishing a new layer version that contains the updated dependencies. Then you update each Lambda function configuration to reference the new layer version. This centralizes dependency management, reduces duplicated artifacts, and makes rollouts and rollbacks cleaner (you can switch layer versions quickly). It also keeps function deployment packages smaller, which often improves deployment speed and can reduce cold-start overhead associated with larger bundles.

The other options introduce unnecessary operational burden:

Downloading modules at cold start (CloudFront/S3) increases latency and adds failure modes at runtime.

Hosting a private registry on EC2 requires patching, scaling, availability management, and security hardening—high operational overhead.

A CloudFormation registry extension and daily scans are not a standard or efficient mechanism for packaging runtime Node.js dependencies into Lambda functions.

Lambda layers are a documented AWS-native feature intended for precisely this use case: sharing common code and libraries across functions while enabling controlled versioning. Therefore, creating a layer for the open source modules and updating the functions to consume the layer is the most efficient and maintainable approach.

Requirement Summary:

Orders are being processed more than once

Need to prevent duplicate processing

Looking for least implementation effort

Key Concept:

Lambda + Event-driven patterns can occasionally result in duplicate invocations (at-least-once delivery model)

You need idempotency (i.e., prevent repeated processing of same event)

Evaluate Options:

A. Use DynamoDB for de-duplication

Simple and widely used approach

Store a unique orderId as the primary key

Before processing, check if order exists

If yes → skip

If no → process and store the ID

Minimal code changes required

B. ECS + Step Functions

Overkill for basic de-duplication

Adds significant complexity

C. Retry logic with fixed delay

Doesn ' t prevent duplication — makes it worse

Retrying might trigger the same message again

D. Athena to identify duplicates

Reactive solution, not preventative

Not suitable for real-time event de-duplication

Lambda idempotency: https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html

Using DynamoDB for idempotent design: https://aws.amazon.com/blogs/compute/how-to-design-idempotent-APIs-on-aws/

The correct answer is C because Amazon SNS FIFO topics are designed for applications that require both message ordering and deduplication , and high throughput mode extends the throughput capability to support large-scale workloads such as sending thousands of notifications per second . This directly matches the requirement for ordered notification delivery at very high scale.

The requirement to filter out some notifications before sending them to the HTTP endpoint is also handled natively by SNS subscription filter policies . With a filter policy, only messages with matching message attributes are delivered to the subscribed endpoint. This means the application can publish all notification events to the SNS topic, while SNS ensures that only relevant notifications are forwarded to the HTTP subscriber. This avoids unnecessary downstream traffic and reduces custom logic.

Option A is incorrect because Amazon Data Firehose is intended primarily for streaming data delivery to analytics and storage destinations, not for ordered notification delivery to HTTP endpoints with filtering requirements. Option B is incorrect because Amazon SQS standard queues do not preserve strict ordering . Also, this design adds Lambda processing complexity and does not align as cleanly with native FIFO and filtering capabilities. Option D is not the best choice because EventBridge supports filtering and API destinations, but it does not provide the same straightforward FIFO ordered delivery guarantee required here.

Therefore, Amazon SNS FIFO in high throughput mode with an HTTP subscription and subscription filter policy is the AWS service combination that best satisfies all the stated requirements.

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.

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).

Amazon DynamoDB throttling during peak periods is commonly caused by hot partitions . In this scenario, using order_date as the partition key results in a large number of writes targeting the same partition during peak ordering times. Even in on-demand mode, DynamoDB enforces per-partition limits, which leads to throttling when traffic is unevenly distributed.

AWS best practices emphasize designing partition keys that provide high cardinality and uniform access patterns . Using customerId as the partition key distributes write traffic across many partitions because customer IDs naturally vary and scale with the number of users.

Switching to provisioned capacity (Option B) does not solve the root cause and can still result in throttling due to uneven access patterns. Sequential partition keys (Option A) worsen the hot partition problem. Migrating to Aurora (Option C) is unnecessary and does not address DynamoDB design issues.

AWS documentation clearly states that access pattern design is critical , and changing the partition key to better distribute workload is the correct solution. Therefore, using customerId as the partition key resolves throttling and aligns with DynamoDB best practices.

Amazon API Gateway stages are designed to represent different deployment environments such as development, testing, and production. AWS documentation recommends using separate stages combined with stage variables to reference different backend resources without duplicating API definitions.

In this scenario, the development stage already uses a stage variable to reference the Lambda dev alias. To expose the production alias safely, the developer should deploy the API to a new stage named production and configure a stage variable that points to the Lambda prod alias. This approach allows the same API configuration and methods to be reused while cleanly separating environments.

Stage variables are resolved at runtime and are commonly used to reference Lambda aliases in integration ARNs. This enables controlled promotion of code from development to production without modifying methods or integrations.

Creating new methods (Options A and B) is unnecessary and increases operational complexity. Directly hardcoding the Lambda alias in the integration (Option D) removes flexibility and deviates from AWS best practices for environment separation.

Therefore, deploying a new API stage and using stage variables to reference the prod Lambda alias is the correct and most efficient 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

Amazon Machine Images (AMIs) are encrypted snapshots of EC2 instances that can be used to launch new instances. The developer can create new AMIs from the existing instances and specify encryption parameters. The developer can copy the encrypted AMIs to the destination Region and use them to create a new application stack. The developer can delete the unencrypted AMIs after the encryption process is complete. This solution will meet the encryption requirement and allow the developer to expand the application to run in the destination Region.

Comprehensive and Detailed Step-by-Step Explanation:

To ensure successful software deployments using AWS CodeDeploy, the application specification file (appspec.yml or appspec.json) must adhere to specific requirements:

File Format Requirement (Option B):

The appspec.yml file is a YAML-formatted file required for defining deployment actions and file locations. This is the modern and recommended format for application specification files.

It can also be a JSON-formatted file named appspec.json, but YAML is most commonly used and accepted.

File Placement Requirement (Option D):

The application specification file must reside in the root directory of the application ' s source code. This is necessary so that AWS CodeDeploy can detect and use the file during deployment.

Incorrect Options:

Option A: While a JSON-formatted file (appspec.json) is valid, this is not a mandatory requirement. YAML is also acceptable, and this option does not account for it.

Option C: The application specification file is not required to be stored in AWS CodeBuild; it must be included in the source code ' s directory structure.

Option E: The application specification file does not need to be stored in Amazon S3. S3 is commonly used for application artifacts, but the appspec.yml or appspec.json file must exist within the deployment package or source code root.

Lambda Layers: These are designed to package dependencies that you can share across functions.

How to Use:

Create a layer, upload your 100MB library as a zip.

Attach the layer to your function.

In your function code, import the library from the standard layer path.

This solution will meet the requirements by using AWS X-Ray to enable tracing of application requests to debug performance issues in the code. 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 install the AWS X-Ray daemon on the EC2 instances, which is a software that listens for traffic on UDP port 2000, gathers raw segment data, and relays it to the X-Ray API. The developer can also install and configure the AWS X-Ray SDK for Python in the application, which is a library that enables instrumenting Python code to generate and send trace data to the X-Ray daemon. Option A is not optimal because it will install the Amazon CloudWatch agent on the EC2 instances, which is a software that collects metrics and logs from EC2 instances and on-premises servers, not application performance data. Option C is not optimal because it will configure the application to write JSON-formatted logs to /var/log/cloudwatch, which is not a valid path or destination for CloudWatch logs. Option D is not optimal because it will configure the application to write trace data to /var/log/xray, which is also not a valid path or destination for X-Ray trace data.

The correct answer is B because AWS AppConfig is designed specifically for application configuration, feature flags, controlled rollouts, configuration validation, and safe deployment practices . The scenario requires rollout in staging first, then gradual exposure to 10% of production users , audience targeting by user attributes , validation before deployment, and the ability to perform instant rollback without redeploying code . AWS AppConfig feature flags provide all of these capabilities.

AWS documentation describes AppConfig as a service for creating, managing, and deploying dynamic application configurations. With feature flags, a company can separate release from deployment and safely enable or disable features for selected audiences. AppConfig supports environment-scoped configurations , so staging and production can have different flag states. It also supports deployment strategies for gradual rollouts and includes validators to check configuration before deployment. In addition, AppConfig supports immediate rollback if a problem occurs, which is a major advantage over approaches that depend on application redeployment.

Option A is incorrect because environment variables typically require a deployment change and do not provide audience targeting, staged rollout controls, or fast rollback. Option C is better suited for storing configuration values, but it does not provide the same rich feature flag targeting and rollout management capabilities as AppConfig. Option D is possible in theory, but it requires building and maintaining a custom service, which is more complex and less reliable than using the managed AWS service built for this purpose.

Therefore, AWS AppConfig feature flags are the best fit for the stated requirements.

Amazon ElastiCache for Redis: An in-memory data store known for extremely low latency, ideal for caching frequently accessed, complex data.

Write-Through Caching: Ensures that data is always consistent between the cache and the database. Writes go to both Redis and RDS.

Performance Gains: Redis handles reads with minimal latency, offloading the RDS database and improving the application ' s responsiveness.

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 correct answer is A because the requirement is to encrypt data in transit and data at rest while ensuring that the developer can manage encryption keys . AWS Key Management Service (AWS KMS) is the AWS-managed service specifically designed for creating, controlling, and auditing cryptographic keys. When used with the AWS Encryption SDK , it supports envelope encryption , a recommended pattern for protecting sensitive application data.

In this model, the application uses data keys to encrypt the actual sensitive data, while AWS KMS protects and manages the master keys that encrypt those data keys. This provides strong security and centralized key management, including access control through IAM, key rotation options, and auditability through AWS logging integrations. For data in transit , the application should also use TLS/HTTPS , which is standard AWS guidance for secure communications.

Option B is incorrect because Parameter Store is not the correct mechanism for directly managing application encryption keys in this way. SecureString protects stored values, but it is not a substitute for using KMS as the primary managed key service for encryption architecture. Option C is incorrect because Secrets Manager is intended for storing secrets such as passwords and tokens, not as the main key management system for application encryption design. Option D is incorrect because SSE-S3 uses Amazon S3-managed keys, not customer-managed KMS keys, so it does not satisfy the requirement that the developer be able to manage encryption keys.

Therefore, AWS KMS with envelope encryption through the AWS Encryption SDK is the most appropriate and secure solution.

AWS Amplify’s most direct support for GraphQL APIs is through AWS AppSync, and the Amplify CLI can generate and configure an AppSync GraphQL API directly from a schema with minimal setup. The requirement says the API already has an existing GraphQL schema, and the goal is to migrate it with the least configuration effort.

Option D is the simplest: run amplify add api, choose GraphQL, and provide the existing schema. Amplify then provisions the AppSync API, sets up the schema, creates the backend resources (depending on chosen data sources), and wires the configuration into the Amplify project so the SPA can consume the API.

Option A is incorrect because it selects REST and does not align with an existing GraphQL schema.

Option B is incorrect because API Gateway is not the native GraphQL service and would require additional mapping/proxy logic—more configuration.

Option C can be valid if an AppSync API already exists and you want to import it, but the question asks to “migrate the API along with the application” with least configuration. Creating it directly in Amplify is typically less configuration than creating separately and importing.

Therefore, using Amplify CLI to add a GraphQL API and supply the existing schema is the least-config approach.

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.

The correct answer is A because AWS CodeBuild natively integrates with AWS Secrets Manager for securely injecting secrets into build environments. In the env section of buildspec.yml , CodeBuild supports a secrets-manager mapping that references a secret directly. This approach keeps the secret encrypted at rest in Secrets Manager, makes it available to the build only when needed, and minimizes custom retrieval logic and operational complexity.

This solution also aligns with the requirement that the secret must not appear in the build logs. AWS CodeBuild is designed to handle environment variables sourced from supported secret stores in a way that avoids exposing plaintext secret values during normal build output. By granting the minimum necessary IAM permissions to the CodeBuild service role, access to the secret is tightly controlled according to least-privilege principles.

Option B is not the best answer because storing secrets in S3 and downloading them during the build adds unnecessary operational overhead and increases the chance of accidental exposure. NoEcho is associated with CloudFormation parameters, not with securely masking S3-downloaded secrets in CodeBuild logs. Option C can also work because Parameter Store integrates with CodeBuild, but for secrets specifically, Secrets Manager is the more direct AWS-managed secret storage service and is generally preferred for this use case. Option D is less efficient because custom CLI retrieval in pre-build steps adds more code and more operational work than native integration.

Therefore, the solution with the least operational overhead and strong security is to use Secrets Manager with the buildspec.yml secrets-manager mapping , making A the correct answer.

This solution will meet the requirements by using a rolling with additional batch deployment method, which deploys the new version of the application to a separate group of instances and then shifts traffic to those instances in batches. This way, the application maintains full capacity and avoids service interruption during deployment, as well as minimizes the cost of additional resources that support the deployment. Option A is not optimal because it will use an all at once deployment method, which deploys the new version of the application to all instances simultaneously, which may cause service interruption or downtime during deployment. Option C is not optimal because it will use a blue/green deployment method, which deploys the new version of the application to a separate environment and then swaps URLs with the original environment, which may incur more costs for additional resources that support the deployment. Option D is not optimal because it will use an immutable deployment method, which deploys the new version of the application to a fresh group of instances and then redirects traffic to those instances, which may also incur more costs for additional resources that support the deployment.

This solution allows the developer to troubleshoot the failure by capturing unprocessed events in a queue for further analysis. Dead Letter Queues (DLQs) are queues that store messages that could not be processed by a service, such as Lambda, for various reasons, such as configuration errors, throttling limits, or permissions issues. The developer can configure DLQs for Lambda functions by sending events to either an Amazon Simple Queue Service (SQS) queue or an Amazon Simple Notification Service (SNS) topic. The developer can then inspect the messages in the queue or topic to identify and fix the root cause of the failure. Configuring AWS CloudTrail logging will not capture invocation failures for asynchronous Lambda invocations, but only record API calls made by or on behalf of Lambda. Configuring Amazon Simple Workflow Service (SWF) or AWS Config will not process any direct unprocessed events, but require additional integration and configuration.

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.

Amazon CloudFront is a global content delivery network (CDN) designed to deliver static and streaming content with low latency and high throughput . AWS documentation explicitly recommends CloudFront for media streaming and high-request-rate workloads.

By placing CloudFront in front of Amazon S3, video content is cached at edge locations close to end users. This dramatically reduces latency, minimizes buffering, and offloads request volume from the S3 bucket. CloudFront is built to handle sudden traffic spikes and supports tens of thousands of requests per second per edge location.

Route 53 routing policies (Option A) control DNS resolution but do not cache content. Cross-Region Replication (Option B) improves regional availability but does not provide edge caching or streaming optimization. S3 Intelligent-Tiering (Option C) optimizes storage cost, not performance.

Therefore, using CloudFront with S3 as the origin provides the largest and most immediate performance improvement.

Amazon S3 is a service that provides highly scalable, durable, and secure object storage. The developer can create an S3 bucket to host the repository and migrate the existing .xml files to the S3 bucket. The developer can update the application code to use the AWS SDK to read and write configuration files from S3. This solution will meet the requirement of high availability for the repository in a cost-effective way.

Step 1: Problem Understanding

Asymmetric Encryption Requirement: Users encrypt data with a public key, and only the company can decrypt it using a private key.

Data Encryption at Rest and In Transit: The data must be encrypted during upload (in transit) and when stored in Amazon S3 (at rest).

Step 2: Solution Analysis

Option A: Server-side encryption with Amazon S3 managed keys (SSE-S3).

Amazon S3 manages the encryption and decryption keys.

This does not meet the requirement for asymmetric encryption, where the company uses a private key.

Not suitable.

Option B: Server-side encryption with customer-provided keys (SSE-C).

Requires the user to supply encryption keys during the upload process.

Does not align with the asymmetric encryption requirement.

Not suitable.

Option C: Client-side encryption with a data key.

Data key encryption is symmetric, not asymmetric.

Does not satisfy the requirement for a public-private key pair.

Not suitable.

Option D: Client-side encryption with a customer-managed encryption key.

Data is encrypted on the client side using the public key.

Only the company can decrypt the data using the corresponding private key.

Data remains encrypted during upload (in transit) and in S3 (at rest).

Correct option.

Step 3: Implementation Steps for Option D

Generate Key Pair:

The company generates an RSA key pair (public/private) for encryption and decryption.

Encrypt Data on Client Side:

Use the public key to encrypt the data before uploading to S3.

S3 Upload:

Upload the encrypted data to S3 over an HTTPS connection.

Decrypt Data on the Server:

Use the private key to decrypt data when needed.

AWS Developer References:

Amazon S3 Encryption Options

Asymmetric Key Cryptography in AWS

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.

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

Amazon CloudWatch Logs Insights is a purpose-built log analytics tool that allows developers to run interactive queries directly against CloudWatch Logs. AWS documentation highlights Logs Insights as the fastest and most efficient way to search, filter, and analyze log data without exporting it.

Logs Insights queries can filter error messages, extract timestamps, and aggregate failure counts over specific time windows. This directly satisfies the requirement to identify when intermittent failures occurred and what errors caused them.

Manual browsing (Option A) and local downloads (Option C) are time-consuming and do not scale. Exporting logs to S3 and querying with Athena (Option D) introduces unnecessary infrastructure and operational overhead.

Therefore, CloudWatch Logs Insights is the most operationally efficient solution.

The base table’s primary key is UserID, which means efficient Query operations on the table natively require specifying UserID (partition key equality). The required access pattern, however, is to retrieve many users for a given Location and then filter/sort by RegistrationDate (users who registered after a given date). Because Location is not part of the table’s primary key, the efficient DynamoDB approach is to create an index that supports this access pattern.

A global secondary index (GSI) can have a different partition key and sort key than the base table. By creating a GSI with Location as the partition key and RegistrationDate as the sort key, the application can use the Query operation to fetch all users in a specific location (Location = :loc) and apply a sort key condition such as RegistrationDate > :date (or BETWEEN), which is efficient and avoids a full-table scan. This design is the canonical pattern for optimizing DynamoDB queries: model the table and indexes around known access patterns so the application can use Query instead of Scan.

Option C (LSI) is not valid for this requirement because an LSI must use the same partition key as the base table (UserID). Since the access pattern is by Location, an LSI cannot make Location the partition key. Option B (Scan + filter) is inefficient at scale because Scan reads every item (or every item in the scanned segments) and then filters results, consuming read capacity and increasing latency. Option D (BatchGetItem) requires the caller to already know the primary keys of the items to retrieve; it cannot discover “all users in a location after a date” and does not support filtering in the way Query on an index does.

Therefore, A is the correct and most efficient solution: a GSI on (Location, RegistrationDate) and Query with a date range condition.

The correct answer is C because AWS AppConfig provides built-in support for feature flags , allowing developers to enable or disable features dynamically without redeploying application code. This is exactly what the question requires: keeping features hidden from end users until the features are ready for release, and then selectively activating them when appropriate.

AWS documentation describes AppConfig as a service for managing application configuration in a safe and controlled way. Feature flags in AppConfig let teams separate deployment from release , which is a core best practice in modern application development. A developer can deploy code that contains unfinished or hidden functionality, while the actual visibility and activation of that functionality is controlled through feature flag values stored in an AppConfig configuration profile. When the feature is ready, the flag can be turned on without changing the application package.

Option A is incorrect because AWS AppSync is a managed GraphQL service and is not the AWS feature flag service for application configuration management. Option B is incorrect because DynamoDB Streams are used for capturing item-level changes and reacting to table updates, not for controlled feature activation. Option D is incorrect because Amplify DataStore is intended for client-side data synchronization and offline access patterns, not centralized production feature flag management.

Using AppConfig also provides operational benefits such as deployment strategies, configuration validation, and rollback support, which make it safer than building a custom feature toggle mechanism. For these reasons, AWS AppConfig feature flags are the most appropriate and AWS-recommended solution for hiding prerelease features and selectively enabling them later.

Therefore, C is the correct answer.

AWS Lambda has a maximum execution time of 15 minutes , which makes batch-style processing unsuitable as workloads scale. AWS best practices recommend using event-driven architectures to process individual objects independently and in parallel.

Amazon S3 event notifications invoke Lambda automatically whenever a new object is uploaded. This allows each file to be processed in its own execution, eliminating long-running batch jobs and enabling horizontal scaling. AWS Lambda automatically scales concurrency based on event volume, ensuring faster processing as uploads increase.

To prevent duplicate processing, AWS documentation recommends using an idempotency mechanism . Storing processed file identifiers or transaction IDs in Amazon DynamoDB provides a highly available, low-latency way to track processed files. DynamoDB’s conditional writes can enforce exactly-once processing semantics.

Options B, C, and D either increase operational overhead, reintroduce batching issues, or rely on unreliable polling mechanisms that can miss or reprocess files.

Thus, using S3 events with DynamoDB tracking is the correct and scalable solution.

The requirement is specifically to have ECS automatically restore the last known good deployment when a new deployment fails, while the service is using the rolling update deployment type. Amazon ECS supports this through the deployment circuit breaker with the option to rollback on failures.

When enabled, the deployment circuit breaker monitors the deployment and detects failure conditions such as tasks repeatedly failing health checks, not reaching steady state, or being unable to start successfully. With rollback enabled, ECS automatically stops the failing deployment and reverts the service to the most recently completed (stable) task definition, restoring service stability without manual intervention.

Option D matches exactly: keep the rolling deployment type and enable circuit breaker + rollback. This is minimal change and directly addresses the behavior observed.

Options A and B are unrelated: service autoscaling adjusts desired count based on metrics and does not roll back failed deployments.

Option C could also achieve rollback behavior, but switching to blue/green introduces additional components (AWS CodeDeploy integration, target groups, and traffic shifting), which is unnecessary when the requirement can be met within rolling deployments.

Therefore, enabling the ECS deployment circuit breaker with rollback on failures for a rolling deployment is the correct solution.

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.

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 rotate database credentials at least weekly . The AWS service that is purpose-built for storing and automatically rotating secrets is AWS Secrets Manager . Secrets Manager supports rotation schedules (including daily, weekly, or custom intervals) and integrates with supported databases through rotation Lambda functions. With rotation enabled, Secrets Manager can periodically generate a new password, update the secret value, and apply the new credential to the database user, while allowing applications to retrieve the current credential securely at runtime.

Option C matches this best practice: create a database user, store the username/password in a Secrets Manager secret, and enable rotation (daily rotation more than satisfies a weekly requirement). Applications on EC2 can retrieve the secret at startup or on a refresh interval using the AWS SDK, and can cache it according to best practices to reduce API calls, while still supporting rotation.

Option A (Parameter Store secure string) encrypts parameters, but Parameter Store does not provide the same managed secret rotation workflow for database credentials; rotating the KMS key is not the same as rotating the database password. Option B is not applicable as stated for RDS for Microsoft SQL Server: IAM database authentication is supported for specific engines (commonly MySQL and PostgreSQL) and is not the standard mechanism for SQL Server password rotation. Option D is insecure and operationally fragile: embedding long-lived credentials in user data and environment variables makes rotation difficult and increases exposure risk.

Therefore, the most secure and compliant configuration is C : store DB credentials in AWS Secrets Manager and enable automated rotation on an interval that meets or exceeds the weekly rotation requirement.

AWS SAM provides built-in tooling to generate realistic event payloads that match the structure of events produced by AWS services (such as S3, SNS, SQS, API Gateway, EventBridge, and others). The command designed specifically for this purpose is sam local generate-event. It produces sample event JSON that mirrors the format AWS services deliver to Lambda, which meets the requirement that payload structures match real service events.

This approach also requires the least development effort because the developer does not need to manually craft and maintain JSON payload files. Instead, the developer can generate the appropriate event type with SAM, optionally tweak values (bucket name, object key, request parameters), and then run sam local invoke using the generated payload. This significantly reduces mistakes and saves time, especially when testing multiple event sources.

Why other options are less suitable:

A (shareable test events) is vague and typically still requires manual creation/maintenance.

B requires manually creating payloads, which is error-prone and higher effort.

C adds unnecessary operational overhead (S3 storage) and still relies on manual payload creation.

Therefore, using sam local generate-event is the quickest and lowest-effort way to generate accurate AWS-service-like test payloads for local Lambda testing.

Why Option C is Correct:Ensuring that pipeline artifacts are encrypted with a customer-managed AWS KMS key involves configuring the S3 bucket policy to require encryption. This policy ensures all objects uploaded to the bucket are encrypted with the specified KMS key.

Why Other Options are Incorrect:

Option A: A gateway endpoint improves S3 access efficiency but does not enforce encryption.

Option B: Encrypting CloudWatch Logs is unrelated to securing pipeline artifacts.

Option D: Configuring SNS for encryption does not affect the artifacts stored in the S3 bucket.

AWS Documentation References:

Using Server-Side Encryption with S3 Bucket Policies

This solution allows the Lambda function to be invoked by the DynamoDB stream whenever updates are made to items in the DynamoDB table. Event source mapping is a feature of Lambda that enables a function to be triggered by an event source, such as a DynamoDB stream, an Amazon Kinesis stream, or an Amazon Simple Queue Service (SQS) queue. The developer can configure event source mapping for the Lambda function using the AWS Management Console, the AWS CLI, or the AWS SDKs. Changing the StreamViewType parameter value to NEW_AND_OLD_IMAGES for the DynamoDB table will not affect the invocation of the Lambda function, but only change the information that is written to the stream record. Mapping an Amazon Simple Notification Service (Amazon SNS) topic to the DynamoDB stream will not invoke the Lambda function directly, but require an additional subscription from the Lambda function to the SNS topic. Increasing the maximum runtime (timeout) setting of the Lambda function will not affect the invocation of the Lambda function, but only change how long the function can run before it is terminated.

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.

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

AWS Secrets Manager supports multi-Region secret replication, which is designed specifically for redundancy, disaster recovery, and multi-Region applications. With this feature, the primary secret resides in one Region (here, us-west-1) and Secrets Manager automatically maintains a replica in another Region (us-east-1). This provides local read access and resilience if one Region is impaired.

Option A accurately describes the standard configuration: enable secret replication and add us-east-1 as the replica Region. Because encryption keys are Region-scoped, the replica secret in us-east-1 should be encrypted with a KMS key in us-east-1 (either the default Secrets Manager key for that Region or a customer managed key), satisfying encryption requirements and proper key locality.

Option B is incorrect because you don’t configure replication “from the destination.” Replication is configured on the primary secret, and the replica uses a KMS key in the replica Region, not in the source Region.

Option C is not how Secrets Manager replication works. Replication is not only during rotation; it maintains replicas continuously. The “replication rule during rotation” framing is not the standard mechanism.

Option D is inappropriate and insecure/operationally complex: exporting secrets to S3 for replication is not the recommended pattern and introduces unnecessary exposure.

Therefore, enable Secrets Manager multi-Region replication and encrypt replicas with a KMS key in the destination Region.

HTTP 429 errors indicate throttling (“Too Many Requests”). In this architecture, throttling can occur at multiple layers (API Gateway rate limits, downstream AWS service API throttles, or dependency throttling). Regardless of which service is throttling, the correct resilience pattern is to implement retries with exponential backoff and jitter for retryable failures. AWS SDKs and AWS best practices recommend backoff to reduce contention and allow the system to recover, while ensuring requests eventually succeed.

Option C directly addresses the problem and the requirement “ensure that all of the application ingests all files.” With a retry + backoff pattern, transient throttling is handled gracefully: failed operations are retried after increasing delays, avoiding immediate retry storms that worsen throttling. This increases successful completion rate without requiring major architectural changes.

Option A (Transfer Acceleration) can improve upload latency from geographically distributed clients, but it does not resolve request throttling (429) caused by API limits.

Option B (multipart upload) helps with large object uploads and can improve throughput/reliability for big files, but it does not inherently prevent 429 throttling at API Gateway or other throttled calls.

Option D (Intelligent-Tiering) affects storage cost optimization, not ingestion throttling.

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).

The application relies on shared file storage that behaves like NFS and must be accessible concurrently by multiple containers across Kubernetes nodes. AWS documentation clearly identifies Amazon EFS as the AWS-native, fully managed, NFS-compatible file system designed for this purpose.

Amazon EFS provides elastic scaling , high availability across multiple Availability Zones, and native integration with container orchestration platforms. It is the most direct replacement for on-premises NFS, requiring minimal architectural change.

To run Kubernetes workloads on AWS with high availability, AWS recommends Amazon EKS , a managed Kubernetes service that automatically handles control plane availability and upgrades. EKS integrates natively with EFS using the Amazon EFS CSI driver, allowing pods across multiple nodes to mount the same file system concurrently.

Amazon EBS (Options A, C, and D) is block storage that can be attached to only one EC2 instance at a time (except in limited Multi-Attach scenarios) and is therefore unsuitable for shared NFS-style access across a Kubernetes cluster.

Uploading container images to Amazon ECR ensures secure, scalable storage for container images and seamless integration with EKS.

Therefore, migrating the NFS data to Amazon EFS and running the workloads on Amazon EKS is the fastest, most scalable, and AWS-recommended solution.

This benefit occurs when initializing the AWS SDK outside of the Lambda handler function because it allows the SDK instance to be reused across multiple invocations of the same function. This can improve performance and reduce latency by avoiding unnecessary initialization overhead. If the SDK is initialized inside the handler function, it will create a new SDK instance for each invocation, which can increase memory usage and execution time.

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.

Comprehensive and Detailed 250 to 300 words of Explanation From AWS Developer Documents:

The key requirement in this scenario is that the data must be encrypted before it is uploaded to Amazon S3 , and the data is generated outside of AWS . This explicitly points to a client-side encryption requirement.

AWS documentation distinguishes clearly between server-side encryption and client-side encryption . Server-side encryption options for Amazon S3—including enabling default bucket encryption or specifying the x-amz-server-side-encryption request header—encrypt the data after it is received by Amazon S3. Therefore, options B and D do not satisfy the requirement because the plaintext data is transmitted to AWS before encryption occurs.

Option A, using the AWS KMS encrypt command, is not suitable for large binary objects. AWS KMS is designed to encrypt small pieces of data (up to 4 KB). AWS documentation explicitly states that for large payloads, customers should use envelope encryption instead of directly encrypting data with AWS KMS.

The AWS Encryption SDK is specifically designed for client-side encryption of large data objects. It implements envelope encryption , where a data encryption key (DEK) is generated locally to encrypt the data, and the DEK is then encrypted with an AWS KMS key. This approach allows efficient encryption of large binary files while maintaining strong key management and security controls.

AWS documentation recommends the AWS Encryption SDK for applications that need to encrypt data before sending it to AWS services , including Amazon S3. It supports multiple programming languages, handles key management automatically, and ensures data confidentiality even before transmission.

Therefore, using the AWS Encryption SDK for client-side encryption is the only solution that fully satisfies all requirements.

AWS AppConfig , a capability of AWS Systems Manager, is specifically designed to manage feature flags , configuration changes, and application toggles safely and dynamically. AWS documentation highlights AppConfig as the recommended service for enabling and disabling application features without redeploying code.

Feature flags in AppConfig allow developers to control visibility, rollout strategies, and gradual releases across environments. AppConfig supports validation, monitoring, and rollback to prevent misconfigurations from impacting users.

Option A is incorrect because AWS AppSync is a GraphQL service and does not manage feature flags. Options B and D misuse data storage and synchronization services for configuration management, introducing unnecessary complexity and risk.

Using AWS AppConfig enables developers to hide features , activate them instantly when ready, and manage them centrally with minimal operational overhead.

Therefore, AWS AppConfig feature flags are the correct and AWS-recommended solution.

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.

This solution meets the requirements most cost-effectively because it optimizes the photos on demand and caches them for future requests. Lambda@Edge allows the developer to run Lambda functions at AWS locations closer to viewers, which can reduce latency and improve photo quality. The developer can create a Lambda@Edge function that uses the GET parameters from each request to optimize the photos with the required dimensions and resolutions and returns them as a response. The function can also store a copy of the processed photos on Amazon S3 for subsequent requests, which can reduce processing time and costs. Using S3 Batch Operations to create new variants of the photos will incur additional storage costs and may not cover all possible dimensions and resolutions. Creating a dynamic CloudFront origin or a Lambda@Edge function to route requests to corresponding photo variants will require maintaining a mapping of device types and photo variants, which can be complex and error-prone.

The core requirement is to perform a one-time deployment for testing without impacting the existing pre-production stack that other team members rely on. The safest way to avoid disruption is to deploy into an isolated AWS account (a dedicated development/testing account) instead of modifying the shared pre-production environment.

Option C achieves this with the least effort: use the AWS SAM CLI to package and deploy the same SAM application into a new AWS account designated for development. This creates an isolated copy of the stack (Lambda + SNS topics) where the developer can validate changes without affecting the shared pre-production deployment or the release pipeline.

Option A still deploys into pre-production, which directly violates the requirement to avoid impacting the existing application. A “debug parameter” does not prevent resource updates or side effects.

Option B is inconsistent: a CloudFormation change set is created against a specific account/stack. You cannot create a change set in one account and “execute it” in a different account as stated. Cross-account execution would require different credentials and a separate deployment process.

Option D introduces additional pipeline/stage complexity and is not necessary for a one-time test; it also implies changing the existing stack/pipeline, which can itself cause disruption.

The workload is explicitly very I/O intensive and requires reading the same file multiple times. Reading repeatedly from S3 across the network will introduce latency and repeated network I/O. For best performance, the function should download the file once to fast local storage and perform all repeated reads locally.

AWS Lambda provides ephemeral storage mounted at /tmp. AWS allows increasing this ephemeral storage beyond the default size. Because the files are at most 2 GB, the developer can configure the Lambda function’s ephemeral storage to 2 GB and copy each S3 object into /tmp before processing. This converts repeated network reads into repeated local filesystem reads, which is significantly faster and more consistent for I/O-heavy workloads.

Option D (read directly from S3) is the least optimized because each pass over the file requires additional network I/O and S3 GET requests.

Option A is not feasible: Lambda cannot directly attach and manage an EBS volume like an EC2 instance can.

Option B is not applicable: ENA is an EC2 networking feature; Lambda networking is managed by the service and does not allow attaching ENAs for performance tuning in that way.

Because the files are disposable after processing, using ephemeral /tmp storage is also cost-effective and operationally simple, and it is aligned with the “process once per file” pattern.

Therefore, increase Lambda ephemeral storage and copy the video into /tmp for repeated reads.

This solution allows the fastest response for the query because it enables the query to use a single partition key value (the Product ID) and a range of sort key values (the Product Rating) to find the matching items. A global secondary index (GSI) is an index that has a partition key and an optional sort key that are different from those on the base table. A GSI can be created at any time and can be queried or scanned independently of the base table. A local secondary index (LSI) is an index that has the same partition key as the base table, but a different sort key. An LSI can only be created when the base table is created and must be queried together with the base table partition key. Using a GSI with Product ID as the partition key and Review ID as the sort key will not allow the query to use a range of sort key values to find the highest ratings. Using an LSI with Product ID as the partition key and Product Rating as the sort key will not work because Product ID is not the partition key of the base table. Using an LSI with Review ID as the partition key and Product ID as the sort key will not allow the query to use a single partition key value to find the matching items.

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.

“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).

SNS as a Fan-out Mechanism: SNS is perfect for triggering multiple actions from a single event (here, the image upload).

Workflow:

SNS Topic: Create an SNS topic that will be the central notification point.

S3 Event Notification: Configure the S3 bucket to send ' Object Created ' event notifications to the SNS topic.

Lambda Subscription: Subscribe your thumbnail-creating Lambda function to the SNS topic.

Email Subscription: Subscribe an email address to the SNS topic to trigger notifications.

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and consistent performance with seamless scalability. The developer can store each employee’s contact information in a DynamoDB table along with the object keys for the photos stored in Amazon S3. Amazon S3 is an object storage service that offers industry-leading scalability, data availability, security, and performance. The developer can use AWS APIs to search and retrieve the employee details and photos from DynamoDB and S3.

The solution that will meet the requirements is to write data to Amazon ElastiCache. This way, the application can write session data to a fast, scalable, and reliable in-memory data store that can be served reliably across multiple requests. The other options either involve writing data to persistent storage, which is slower and more expensive than in-memory storage, or writing data to the root filesystem, which is not shared among multiple EC2 instances.

Amazon EventBridge: A service that reacts to events from various AWS sources, including S3. Rules define which events trigger actions (like invoking Lambda functions).

S3 Object Created Events: EventBridge can detect these, providing seamless integration for automated CSV processing.

S3 Lifecycle Rules: Allow for actions based on object age or prefixes. These can directly trigger Lambda functions for file processing.

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

This solution will meet the requirements by using AWS Config to monitor and evaluate whether Secrets Manager secrets are unused or have been deleted, based on specified time periods. The secrets manager-secret-unused managed rule is a predefined rule that checks whether Secrets Manager secrets have been rotated within a specified number of days or have been deleted within a specified number of days after last accessed date. The Amazon EventBridge rule will trigger a notification when the AWS Config managed rule is met, alerting the developer about unused secrets that can be removed without causing application downtime. Option A is not optimal because it will use AWS CloudTrail log file delivery to an Amazon S3 bucket, which will incur additional costs and complexity for storing and analyzing log files that may not contain relevant information about secret usage. Option C is not optimal because it will deactivate the application secrets and monitor the application error logs temporarily, which will cause application downtime and potential data loss. Option D is not optimal because it will use AWS X-Ray to trace secret usage, which will introduce additional overhead and latency for instrumenting and sampling requests that may not be related to secret usage.

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.

This solution meets the requirements because it encrypts data at rest using AWS KMS keys and provides an audit trail of when and by whom they were used. Server-side encryption with AWS KMS managed keys (SSE-KMS) is a feature of Amazon S3 that encrypts data using keys that are managed by AWS KMS. When SSE-KMS is enabled for an S3 bucket or object, S3 requests AWS KMS to generate data keys and encrypts data using these keys. AWS KMS logs every use of its keys in AWS CloudTrail, which records all API calls to AWS KMS as events. These events include information such as who made the request, when it was made, and which key was used. The company policy can use CloudTrail logs to audit critical events related to their data encryption and access. Server-side encryption with Amazon S3 managed keys (SSE-S3) also encrypts data at rest using keys that are managed by S3, but does not provide an audit trail of key usage. Server-side encryption with customer-provided keys (SSE-C) and server-side encryption with self-managed keys also encrypt data at rest using keys that are provided or managed by customers, but do not provide an audit trail of key usage and require additional overhead for key management.

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.

These solutions will mitigate the error most cost-effectively because they do not require increasing the provisioned throughput of the DynamoDB table or creating additional resources. Exponential backoff is a retry strategy that increases the waiting time between retries to reduce the number of requests sent to DynamoDB. The AWS SDKs for DynamoDB implement exponential backoff by default and also provide other features such as automatic pagination and encryption. Increasing the read and write throughput of the DynamoDB table, creating a DynamoDB Accelerator (DAX) cluster, or creating a second DynamoDB table will incur additional costs and complexity.

The response from the API call indicates that the ProvisionedThroughputExceededException exception has occurred. This exception means that the rate of incoming requests exceeds the throughput limit for one or more shards in a stream. To mitigate this exception, the developer can use one or more of the following techniques:

Implement retries with exponential backoff. This will introduce randomness in the retry intervals and avoid overwhelming the shards with retries.

Reduce the frequency and/or size of the requests. This will reduce the load on the shards and avoid throttling errors.

Increase the number of shards in the stream. This will increase the throughput capacity of the stream and accommodate higher request rates.

Use a PutRecord API instead of PutRecords. This will reduce the number of records per request and avoid exceeding the payload limit.

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.

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.

Reserved concurrency guarantees a specific number of concurrent executions for a critical Lambda function. This ensures that the critical function always has sufficient resources to execute, even if other functions are consuming concurrency.

Why Option A:

Ensures Function Availability: Reserved concurrency isolates the critical Lambda function from other functions.

Low Overhead: Configuring reserved concurrency is straightforward and requires minimal setup.

Why Not Other Options:

Option B: Provisioned concurrency is ideal for reducing cold starts, not for managing execution limits.

Option C & D: Alarms and re-invocation mechanisms add complexity without resolving the root cause.

Managing Concurrency for AWS Lambda

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.

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.

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

To redact PII from S3 objects before they are accessed by the analytics service, the most efficient solution is to use S3 Object Lambda. S3 Object Lambda allows you to add your own code (Lambda function) to process and transform data when it is retrieved from Amazon S3. You can attach a Lambda function to an S3 Object Lambda Access Point, which in this case would run a redaction API to remove PII from the reports.

Operational Efficiency: S3 Object Lambda handles data processing on the fly, without requiring the data to be permanently transformed or moved to another service (like Amazon Redshift).

Alternatives:

Option A: Loading the data into Amazon Redshift would require refactoring the analytics service and maintaining an additional data pipeline, increasing complexity.

Option C: Using AWS KMS for encryption protects data at rest and in transit, but it does not address PII redaction.

Option D: SNS is a messaging service and does not support direct data transformation.

The correct answer is B because when an IAM role is attached to an Amazon EC2 instance through an instance profile, changes to the permissions policy for that role propagate automatically to applications that use the instance role credentials. This is the least disruptive approach because the developer does not need to restart, hibernate, terminate, or replace the EC2 instance.

AWS documentation explains that applications running on EC2 can obtain temporary security credentials from the instance metadata service for the attached IAM role. When the IAM policy attached to that role is updated to allow Amazon S3 read access , new temporary credentials issued for the role will reflect the updated permissions. This makes it possible to correct the access issue without changing the application deployment model or interrupting the running instance.

Option A is unnecessary because terminating and relaunching the instance causes avoidable disruption. Option C is also unnecessary because hibernation and restart are not required for IAM policy changes to take effect. Option D is not the best answer because although bucket policies can grant access, the issue identified is specifically that the instance role lacks S3 read permission , and restarting the instance is still unnecessary.

The AWS best-practice approach is to grant the required permission directly to the IAM role used by the EC2 instance. This keeps authorization centralized and lets the running application continue using temporary role credentials with minimal operational impact.

Therefore, the solution with the least application disruption is to add the S3 read permission to the IAM role , making B the correct answer.

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.

Visibility Timeout: When an SQS message is processed by a consumer (here, the Lambda function), it ' s temporarily hidden from other consumers. Visibility timeout controls this duration.

How It Helps:

Increase the visibility timeout beyond the maximum processing time your Lambda might typically take for long videos.

This prevents the message from reappearing in the queue while Lambda is still working, avoiding premature timeouts.

The solution that will meet the requirements is to use multiple stages in API Gateway. Create a Lambda function for each environment. Configure API Gateway stage variables to route traffic to the Lambda function in different environments. This way, the company can test the code in a dedicated, monitored test environment before releasing it to the production environment. The company can also use stage variables to specify the Lambda function version or alias for each stage, and avoid hard-coding the Lambda function name in the API Gateway integration. The other options either involve using a single stage in API Gateway, which does not allow testing in different environments, or adding different code blocks for different environments in the Lambda function, which increases complexity and maintenance.

The AWS Serverless Application Model Command Line Interface (AWS SAM CLI) is a command-line tool for local development and testing of Serverless applications2. The sam local start-api subcommand of AWS SAM CLI is used to simulate a REST API by starting a new local endpoint3. Therefore, option D is correct.

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.

When IAM user credentials require MFA for API access, the correct approach is to obtain temporary security credentials from AWS Security Token Service (STS) that are validated with an MFA code. AWS documentation describes using STS to issue temporary credentials that applications can use instead of long-term access keys, especially when MFA is required.

The specific STS API operation used for an IAM user to obtain temporary credentials is GetSessionToken. This call supports MFA by accepting the user’s MFA device serial number and a time-based one-time password (TOTP) code. STS then returns a set of temporary credentials: AccessKeyId, SecretAccessKey, and SessionToken, which the SDK can use to sign subsequent API requests. This is the standard method for enabling MFA-protected API access for IAM users.

Why the other options are wrong:

GetFederationToken is used to obtain temporary credentials for a federated user, often for scenarios where you want to grant access to resources for users who do not have IAM users. It’s not the typical method for IAM-user MFA enforcement for all calls.

GetCallerIdentity simply returns identity details for the current credentials; it does not generate credentials.

DecodeAuthorizationMessage is used to decode encoded authorization failure messages returned by AWS, not to authenticate.

Therefore, to access an API protected by MFA requirements for an IAM user, the developer should call GetSessionToken and then use the returned temporary credentials in the AWS SDK.

DynamoDB TTL (Time-to-Live): A native feature that automatically deletes items after a specified expiration time.

Efficiency: Eliminates the need for scheduled deletion jobs, optimizing write throughput by avoiding potential throttling conflicts.

Seamless Integration: TTL works directly within DynamoDB, requiring minimal development overhead.

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.

The objects are “rarely accessed after 1 week” but must remain immediately available at all times. That means the storage class must support millisecond access without a restore process. S3 Standard-Infrequent Access (Standard-IA) is designed for exactly this: lower storage cost than S3 Standard, while still providing rapid access when needed.

With option B, an S3 Lifecycle rule transitions objects from S3 Standard to S3 Standard-IA after 7 days. This aligns perfectly with the usage pattern: frequent access initially, then infrequent access after a week, while keeping immediate availability.

Option C (S3 Glacier Flexible Retrieval) is not appropriate because Glacier classes are archival. Access typically requires a restore operation and retrieval time (minutes to hours), which violates “immediately available at all times.”

Option A expires objects, which deletes them after 7 days—this contradicts the requirement to keep objects available.

Option D is irrelevant because delete markers exist only when versioning is enabled. The bucket does not have versioning enabled, so this rule would not help.

Therefore, transitioning to S3 Standard-IA after 7 days is the correct cost-optimized solution while maintaining immediate availability.

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.

Requirement Summary:

Multi-tier app on EC2 + Aurora PostgreSQL

Must comply with least privilege and security policies

Need to manage credentials and API keys securely

Must support key rotation on demand

Evaluate Options:

A. Secrets Manager + AWS managed KMS keys

Best practice for secure secret storage

Supports auto rotation

Uses AWS SDK to fetch at runtime (secure, avoids hardcoding)

AWS managed keys are rotated automatically and easier to manage

B. Secrets Manager + customer managed keys

Also valid, but adds complexity

Since the question asks for LEAST development effort, AWS-managed keys are preferred

C. Store secrets in code

Violates all security best practices

D. Use SSM Parameter Store + AWS managed keys

Possible, but Secrets Manager is preferred when rotation is needed

Parameter Store does not natively rotate secrets

Secrets Manager: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html

Automatic key rotation: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

Best practices for secret management: https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html

AWS Lambda is a service that lets developers run code without provisioning or managing servers. Lambda provides a local file system that can be used to store temporary files during invocation. The local file system is mounted under the /tmp directory and has a limit of 512 MB. The temporary files are accessible only by the Lambda function that created them and are deleted after the function execution ends. The developer can store temporary files that are less than 10 MB in the /tmp directory and access and modify them multiple times during invocation.

The requirements are: (1) store an API key that a Lambda function will use, (2) ensure the secret is encrypted at rest using AWS KMS , and (3) the company must control key rotation , which implies using a customer managed KMS key (CMK) rather than an AWS managed key.

Option C meets the requirements by storing the API key in AWS Systems Manager Parameter Store as a SecureString parameter encrypted with a customer managed KMS key . SecureString is designed for sensitive configuration data and integrates with KMS so the organization can choose the CMK, manage its lifecycle, and control rotation policies. The Lambda function can retrieve the parameter at runtime using the AWS SDK, and IAM policies can tightly control access to the parameter and to the KMS key.

Option E also meets the requirements by storing the API key in a Lambda environment variable encrypted with a customer managed KMS key . Lambda encrypts environment variables at rest and allows you to specify a customer managed KMS key for encryption. This gives the company control over key rotation and key policy, satisfying the “must control key rotation” requirement. The function reads the value from the environment at runtime without additional network calls.

Why the other options fail:

A uses an AWS managed KMS key, which does not satisfy the requirement for the company to control rotation (you cannot manage rotation of AWS managed keys in the same way).

B is a plain String parameter, which is not encrypted as a secret and does not meet the at-rest encryption requirement.

D uses an AWS managed KMS key, again failing the company-controlled rotation requirement.

Therefore, the two valid solutions are C (Parameter Store SecureString with a customer managed CMK) and E (Lambda environment variable encrypted with a customer managed CMK).

Amazon EFS: A network file system (NFS) providing shared, scalable storage across multiple Lambda functions and other AWS resources.

Lambda Mounting: EFS file systems can be mounted within Lambda functions to access a shared storage space.

Log Appending: EFS supports appending data to existing files, making it ideal for the log file scenario.

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 >

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.

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.

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.

In the CloudFormation template, the developer should create a parameter with the list of approved EC2 instance types as AllowedValues. This way, users can select the instance type they want to use when launching the CloudFormation stack, but only from the approved list.

A function alias is a pointer to a specific Lambda function version. You can use aliases to create different environments for your function, such as development, testing, and production. You can also use aliases to perform blue/green deployments by shifting traffic between two versions of your function gradually. This way, you can easily roll back to a previous version if something goes wrong, without having to redeploy your code or change your configuration. Reference: AWS Lambda function aliases

Requirement Summary:

Prevent unauthorized code changes in AWS Lambda

Ensure only trusted code is deployed

AWS Lambda supports Code Signing:

You can configure code signing in Lambda using AWS Signer

Packages must be digitally signed and verified against the signing profile

Rejects unauthorized/modified packages automatically

Evaluate Options:

A. Trusted code option in CodeDeploy

No such feature exists for Lambda

CodeDeploy is more for EC2/On-Prem/Containers, not Lambda code signing

B. Define code signing config + use AWS Signer

This is exactly how AWS enforces trusted code deployment

Attach a code signing configuration to the Lambda function

Use AWS Signer to digitally sign deployment packages

C. Link to KMS to sign code

KMS is not used to sign Lambda packages

KMS is for data encryption, not application code integrity

D. Set KmsKeyArn

This configures data encryption, not code signing

Lambda code signing: https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html

AWS Signer overview: https://docs.aws.amazon.com/signer/latest/developerguide/what-is-signer.html

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.

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.

To provide login functionality with branded sign-in pages and minimal custom code, the best solution is Amazon Cognito Hosted UI. Cognito User Pools include a managed authentication service that can handle sign-up/sign-in, MFA options, password resets, and OAuth/OpenID Connect flows. The Hosted UI provides ready-to-use authentication pages and endpoints, which removes the need to build and maintain custom authentication pages and backend logic.

AWS allows customization of the Hosted UI to match company branding (for example, logo, colors, and CSS styling). This directly meets the requirement that “all pages must match branding” while minimizing development effort. The application can integrate with Cognito using standard authorization flows and tokens, which works well with Lambda-based architectures (for example, API Gateway authorizers with Cognito user pools).

Option A (S3 static pages) would still require implementing authentication flows, session handling, token management, and secure integration with the backend—significantly more custom code.

Option B requires writing and maintaining custom sign-in page serving logic plus authentication handlers, which increases code and operational overhead.

Option C (Lambda@Edge) is even more complex, introducing edge execution and additional deployment/versioning considerations, and still requires custom auth logic.

Therefore, using Amazon Cognito User Pools with the Hosted UI and branding customization is the lowest-code, most maintainable solution.

The correct answer is C because the requirement is for a live feed of log events in near real time , filtered to show only lines that begin with “ERROR.” The live tail feature for AWS Lambda and CloudWatch Logs is specifically intended for this kind of operational debugging. It allows developers to watch logs as they are generated and apply filtering so they can focus only on relevant messages during active troubleshooting.

This is particularly suitable because the function is already in production , and the company wants immediate visibility into timeout-related issues without waiting for a full batch of logs to accumulate. With live tail and a filter expression for ERROR , the developer can observe only the important log lines as new invocations happen, which speeds up root-cause analysis.

Option A is not the best answer because CloudWatch Logs Insights is powerful for querying logs, but it is primarily used for searching and analyzing logs after they have been collected, not as a continuous near-real-time live stream. Option B is incorrect because a subscription filter is used to forward logs to another destination such as Lambda, Kinesis, or Firehose; it is not the simplest way to give an operator a live interactive filtered view. A metric filter also creates metrics from log patterns but does not present the actual live log lines for review. Option D is incorrect because Amazon Athena is not used directly for querying CloudWatch Logs in real-time operational troubleshooting.

Therefore, the best solution is to use live tail with an ERROR filter to inspect relevant Lambda log events as they occur.

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 A is Correct:Encrypting PII at rest and in transit before storing it in DynamoDB ensures end-to-end security. Using the AWS Database Encryption SDK with KMS keys allows the Lambda function to encrypt data before transmission, meeting security and compliance requirements.

Why Other Options are Incorrect:

Option B: While AWS-managed KMS keys encrypt DynamoDB data at rest, they do not encrypt data in transit.

Option C: DynamoDB streams process updates after the data is written to the table, failing to encrypt PII in transit.

Option D: Step Functions and SQS add unnecessary complexity and still require encryption logic for both transit and at rest.

AWS Documentation References:

Encrypting Data in DynamoDB

AWS Database Encryption SDK

The requirement here is to ensure that Lambda functions are executed in a specific order. AWS Step Functions is a low-code workflow orchestration service that enables you to sequence AWS services, such as AWS Lambda, into workflows. It is purpose-built for situations like this, where different steps need to be executed in a strict sequence.

AWS Step Functions: Step Functions allows developers to design workflows as state machines, where each state corresponds to a particular function. In this case, the developer can create a Step Functions state machine where each step (order processing, inventory management, etc.) is represented by a Lambda function.

Operational Overhead: Step Functions have very low operational overhead because it natively handles retries, error handling, and function sequencing.

Alternatives:

Amazon SQS (Option A): While SQS can manage message ordering, it requires more manual handling of each step and the logic to sequentially invoke the Lambda functions.

Amazon SNS (Option B): SNS is a pub/sub service and is not designed to handle sequences of Lambda executions.

EventBridge (Option D): EventBridge Scheduler allows you to invoke Lambda functions based on scheduled times, but it doesn’t directly support sequencing based on workflow logic.Therefore, AWS Step Functions is the most appropriate solution due to its native orchestration capabilities and minimal operational complexity.

AWS Step Functions documentation

Amazon CloudWatch is the service that collects and stores logs from AWS Lambda functions. The developer can use CloudWatch Logs Insights to query and analyze the logs for errors and metrics. Option A is not correct because Amazon S3 is a storage service that does not store Lambda function logs. Option B is not correct because AWS CloudTrail is a service that records API calls and events for AWS services, not Lambda function logs. Option D is not correct because Amazon DynamoDB is a database service that does not store Lambda function logs.

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.

The Secrets Manager Agent provides an out-of-the-box solution for securely caching secrets locally, reducing latency and operational overhead.

Why Option B is Correct:

Caching: The agent securely caches secrets locally, minimizing Secrets Manager API calls.

Security: Secrets remain secure during retrieval and storage.

Low Operational Overhead: Managed solution eliminates the need for custom logic.

Why Not Other Options:

Option A: Custom scripts introduce complexity and require ongoing maintenance.

Option C: Using Redis requires managing an additional service, increasing overhead.

Option D: Storing secrets in S3 lacks the fine-grained security controls of Secrets Manager.

Caching Secrets in AWS Secrets Manager

The requirement is to redact PII before the object content reaches the consumer, while the analytics service continues to use standard S3 GET requests. The most operationally efficient way is Amazon S3 Object Lambda.

S3 Object Lambda lets you add your own code to process and transform data as it is retrieved from S3. Instead of the analytics service reading directly from the bucket, it reads through an S3 Object Lambda Access Point. When the service performs a GET request, S3 invokes the associated Lambda function, which can modify the object payload on the fly—for example, by calling an external or internal PII redaction API and returning a redacted version of the report. The original object remains unchanged in the bucket, while consumers receive the transformed (redacted) response.

This approach is operationally efficient because it avoids:

duplicating and storing redacted copies of every report,

refactoring the analytics service to use a different datastore or ingestion path,

building a separate proxy service layer.

Option A requires significant refactoring and ongoing ETL/warehouse ops.

Option C provides confidentiality via encryption but does not perform redaction (analytics would still see PII after decryption).

Option D changes the access pattern completely (analytics no longer uses GET) and adds messaging complexity without directly returning redacted object content.

Therefore, S3 Object Lambda + Object Lambda Access Point is the most efficient solution to redact data at retrieval time.

Option B: The target group port in the ALB must match the port specified in the ECS task definition. If there is a mismatch, the ALB health check will fail since it cannot correctly route traffic to the container.

Option E: The ALB listener must have a default action that forwards requests to the correct target group associated with the ECS service. If this configuration is missing, the health check will fail as no traffic is routed to the service.

Option A is irrelevant to resolving health check issues since capacity providers relate to provisioning compute capacity.

Option C (hosted zone) is not directly related to ALB health checks.

Option D (redirecting traffic) is not related to ECS health check configurations.

Mocking API Responses: API Gateway ' s Mock integration type enables simulating API behavior without invoking backend services.

Testing with Sample Data: Using captured responses from the real third-party API ensures realistic testing of the integration code.

Focus on Integration Logic: This solution allows the developer to isolate and test the application ' s interaction with the payment APIs, even without a test environment from the third-party providers.

S3Bucket and S3Key: These properties in a CloudFormation AWS::Lambda::Function resource specify the location of the function ' s code in S3.

Least Development Effort: This solution minimizes code changes, relying on CloudFormation to reference the existing S3 deployment package.

The correct policy condition ensures that:

The LeadingKeys condition restricts operations to the authenticated user ' s user_id.

The Attributes condition limits the updatable attributes to user_name.

Explanation of Choices:

Option A: Correctly enforces both the key restriction (dynamodb:LeadingKeys) and ensures only the user_name attribute can be updated.

Option B, C, D: Use incorrect conditions, such as referencing user_name in the LeadingKeys or including other attributes like user_id in updatable fields.

Store the credentials in AWS Secrets Manager and enable rotation. Configure the API to have Secrets Manager access. This is correct. This solution will meet the requirements most securely, because it uses a service that is designed to store and manage secrets such as API credentials. AWS Secrets Manager helps you protect access to your applications, services, and IT resources by enabling you to rotate, manage, and retrieve secrets throughout their lifecycle1. You can store secrets such as passwords, database strings, API keys, and license codes as encrypted values2. You can also configure automatic rotation of your secrets on a schedule that you specify3. You can use the AWS SDK or CLI to retrieve secrets from Secrets Manager when you need them4. This way, you can avoid storing credentials in plaintext files or hardcoding them in your code.

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

Environment Isolation: Creating separate secrets for each environment (development, staging, etc.) ensures clear separation and prevents accidental leaks.

Automatic Rotation: Secrets Manager provides built-in rotation capabilities, enhancing security posture.

Versioning: Tracking changes to secrets is essential for auditing and compliance.

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.

Requirement Summary:

DynamoDB table Orders

Partition key: OrderID

No sort key

100,000+ records

Need to efficiently retrieve all records where:

OrderSource = " MobileApp "

Must optimize for user experience (i.e., performance)

Evaluate Options:

Option A: Scan with FilterExpression

Inefficient for large tables

A Scan reads every item in the table and then applies a filter condition.

This is slow, expensive, and not scalable as the dataset grows.

Option B: Create a Local Secondary Index (LSI) with OrderSource

Invalid: LSIs require the same partition key (OrderID) as the base table.

Since OrderSource is not part of the primary key, and we want to query based on it, LSI won’t help.

Option C: Create a GSI with OrderSource as the sort key

Misuse of sort key: Querying by sort key alone is not allowed in DynamoDB.

You must specify a partition key in a Query.

This design is not valid for the use case.

Option D: Create a GSI with OrderSource as the partition key

BEST CHOICE: With a GSI on OrderSource, you can query efficiently for all items where OrderSource = " MobileApp " .

DynamoDB GSIs allow an alternative access pattern for queries not supported by the base table schema.

GSI Design: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html

Querying a GSI: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html

Scan vs Query: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-query-scan.html

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.

Amazon Cognito user pools support Lambda triggers, which are custom functions that can be executed at various stages of the user pool workflow. A post authentication Lambda trigger can be used to perform custom actions after a user is authenticated, such as sending an email notification. Amazon SES is a cloud-based email sending service that can be used to send transactional or marketing emails. A Lambda function can use the Amazon SES API to send an email to the user’s email address after the user logs in successfully. Reference: Post authentication Lambda trigger

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.