Amazon Web Services SAA-C03 AWS Certified Solutions Architect - Associate (SAA-C03) Exam Practice Test

AWS STS issues temporary credentials with automatically expiring permissions based on IAM roles. This eliminates the need to manually manage or deactivate IAM users.

“You can use AWS STS to grant temporary security credentials that automatically expire after a specified duration.”

— Temporary Security Credentials

This is the least operational overhead and follows AWS best practices for short-term access.

Amazon SQS FIFO queues support deduplication and ordering. AWS documents thatMessageDeduplicationIdis used with FIFO queues to prevent duplicate delivery within a5-minute deduplication window, which matches this requirement exactly. Standard queues do not provide this deduplication guarantee, and SNS filter policies are not a deduplication mechanism for this use case. Because the company wants the least development effort, using API Gateway to place messages directly on an SQS FIFO queue with a deduplication token is the cleanest approach.

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

Deploying the web application on EC2 instances in private subnets behind an internal ALB ensures that the application is not directly accessible from the internet. By setting up a Site-to-Site VPN connection, the application can be accessed securely from the company ' s office network. Deploying NAT gateways in public subnets allows instances in private subnets to initiate outbound connections to the internet for downloading security patches.

Key Requirements:

Serverless architecture.

Handle traffic bursts with high availability.

Process orders asynchronouslyin the order they are received.

Analysis of Options:

Option A:Amazon SNS delivers messages to subscribers. However, SNS does not ensure ordering, making it unsuitable for FIFO (First In, First Out) requirements.

Option B:Amazon SQS FIFO queues support ordering and ensure messages are delivered exactly once. AWS Lambda functions can be triggered by SQS to process messages asynchronously and efficiently. This satisfies all requirements.

Option C:Amazon SQS standard queues do not guarantee message order and have " at-least-once " delivery, making them unsuitable for the FIFO requirement.

Option D:Similar to Option A, SNS does not ensure message ordering, and using AWS Batch adds complexity without directly addressing the requirements.

AWS References:

Amazon SQS FIFO Queues

AWS Lambda and SQS Integration

Amazon EC2 On-Demand Instances: Since the batch jobs cannot be disrupted, On-Demand Instances provide the necessary reliability and availability.

Amazon S3 Standard: Storing data in S3 Standard for the first 30 days ensures quick and frequent access.

S3 Glacier Deep Archive: After 30 days, moving data to S3 Glacier Deep Archive significantly reduces storage costs for data that is rarely accessed.

S3 Lifecycle Configuration: Automating the transition and deletion of objects using lifecycle policies ensures cost optimization and compliance with data retention requirements.

AWS Lake Formation provides fine-grained (column-level) access control for data stored in S3. Using a Lake Formation blueprint ensures database ingestion is automated and governed.

QuickSight can query Athena, and Athena honors Lake Formation permissions, enforcing column-level controls automatically.

Options A, B, and C rely on manual filtering or IAM policies, which cannot enforce column-level authorization for SQL queries.

ECS with Fargate: Allows containerized workloads to scale rapidly without managing underlying servers, handling unpredictable growth effectively.

RDS for Relational Data: Manages large relational datasets efficiently while supporting high availability.

SQS for Decoupling: Ensures message processing occurs in a specific order, decoupling application components and allowing independent evolution.

AWS ECS with Fargate Documentation,AWS SQS Documentation

Amazon S3 is suitable for storing data that needs to be accessed weekly and integrates with AWS Key Management Service (KMS) to provide encryption at rest with server-side encryption using KMS-managed keys (SSE-KMS).

SSE-KMS uses envelope encryption and allows automatic key rotation and logging through AWS CloudTrail, satisfying the requirements for audit trails and compliance.

S3 Glacier Deep Archive is unsuitable due to its high retrieval latency. SSE-C requires customer-side management of encryption keys, with no support for automatic rotation or audit. SSE-S3 does not use customer-managed keys and lacks fine-grained control and auditing.

BothAmazon KinesisandSQS FIFOqueues ensure the sequential processing of messages. By using the payment ID as the partition key in Kinesis or as the message group in the SQS FIFOqueue, messages are processed in order. Both solutions also allow for long-term retention (up to 10 days) of messages, making them suitable for this payment processing use case.

Option A (DynamoDB): DynamoDB does not guarantee message ordering for real-time processing.

Option C (ElastiCache): ElastiCache is for caching, not suitable for sequential message processing.

Option D (Standard SQS queue): A standard SQS queue does not guarantee ordering of messages.

AWS References:

Amazon Kinesis

Amazon SQS FIFO Queues

To meet the requirements, the key must support automatic rotation, and the company must be able to disable (deactivate) the key and schedule deletion. In AWS KMS, these lifecycle controls are available for customer managed keys. Automatic key rotation is supported for symmetric customer managed KMS keys used for encryption and decryption operations. When automatic rotation is enabled, AWS KMS generates new cryptographic material for the key on a regular schedule while the key ID remains the same, helping organizations meet compliance and security best practices without manual operational work.

Option C is the only choice that explicitly combines a symmetric customer managed key with automatic rotation enabled, which directly satisfies the rotation requirement. As a customer managed key, it can also be disabled (to prevent use) and scheduled for deletion (with a waiting period), meeting the rest of the lifecycle needs.

Option A is incorrect because automatic rotation is not generally available for asymmetric KMS keys in the same way; asymmetric keys are used for specialized use cases such as signing or asymmetric encryption, and rotation behavior differs. Options B and D mention “disabling envelope encryption,” which is not a configurable “option” you turn off in KMS; envelope encryption is a recommended pattern where KMS protects data keys, and services commonly use it under the hood. Those options therefore do not describe a valid configuration that meets the requirement.

Therefore, the correct solution is to create a symmetric customer managed KMS key and enable automatic rotation, while using standard KMS controls to disable and schedule deletion when required.

With AWS Shield Advanced, you can add multiple protected resources (like ALBs) to a protection group and choose an aggregation type for mitigation and billing.

Sum aggregation provides combined protection for all resources in the group during blue/green deployment.

“You can add multiple resources to a Shield Advanced protection group and choose an aggregation type. Sum aggregation provides combined protection across all resources.”

— Shield Advanced Protection Groups

This ensures the new ALB inherits protection and avoids additional configuration during deployment.

Amazon EFS provides a shared, fully managed, POSIX-compliant file system that can be mounted by all EC2 instances. Any update made to the file system is immediately visible to all instances, ensuring every new instance has the latest product manuals without delay.

EFS automatically scales storage and throughput, meeting high-demand conditions with no application changes required.

S3 requires instances to download files locally, causing delay and stale data issues (Options B and D). Instance store volumes (Option A) are ephemeral and not shared, making them unsuitable for consistent data distribution.

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

In Amazon Aurora, a custom endpoint is a feature that allows you to create a load-balanced endpoint that directs traffic to a specific set of instances in your Aurora DB cluster. This is particularly useful when you want to route traffic to a subset of instances that have different configurations or when you want to isolate specific workloads (e.g., reporting queries) to certain instances.

Custom Endpoint: The correct solution is to create a custom endpoint that includes the three Aurora Replicas that the department wants to use for near-real-time reporting. This custom endpoint will distribute the reporting queries only across the three selected replicas with the specified compute and memory configurations, ensuring that these queries do not affect the rest of the DB cluster.

Other Options:

Option B (Create a three-node cluster clone): This would create a separate cluster with its own resources, but it is not necessary and could incur additional costs. Also, it doesn ' t leverage the existing replicas.

Option C (Use any of the instance endpoints): This would involve manually managing connections to individual instances, which is not scalable or automatic.

Option D (Use the reader endpoint): The reader endpoint would distribute the read queries across all replicas in the cluster, not just the selected three. This would not meet the requirement to limit the reporting queries to only three specific replicas.

AWS References:

Amazon Aurora Endpoints- Provides detailed information on the different types of endpoints available in Aurora, including custom endpoints.

Custom Endpoints in Amazon Aurora- Specific documentation on how to create and use custom endpoints to direct traffic to selected instances in an Aurora cluster.

For Amazon RDS for PostgreSQL, AWS provides IAM database authentication. With this feature, applications do not use stored long-term usernames and passwords. Instead, they use temporary authentication tokens that are generated by AWS and validated by the RDS database.

The AWS best practice pattern is:

Attach an IAM role to the EC2 instances (instance profile).

Grant that role the necessary permissions (for example, rds-db:connect) to the specific RDS database user.

The application running on the EC2 instance uses the role’s temporary credentials to call the RDS token-generation API and obtain a short-lived authentication token.

The application then uses this token as the password when connecting to RDS for PostgreSQL.

This removes the need to store long-term credentials in the application or on the instance and uses IAM roles with temporary credentials, aligning with the security requirement.

Option A still relies on stored credentials (even if in Secrets Manager), which are long-lived and rotated but not token-based per-connection IAM authentication.

Option B uses static passwords and IP-based access, which does not meet the “no long-term credentials” requirement.

Option C stores long-term IAM user keys on the instances, which is explicitly against best practices and does not directly integrate with RDS authentication.

Using S3 gateway endpoints allows private and cost-free access to S3 without routing traffic through a NAT gateway. NAT gateway traffic incurs charges, especially when used across multiple Availability Zones.

By using an S3 gateway endpoint, EC2 instances in private subnets can access S3 directly without needing internet access, reducing both data transfer and NAT gateway costs.

Interface endpoints are more expensive and typically used for services like API Gateway or Systems Manager.

AWS WAF is the correct service because AWS documents that it protects web applications at Layer 7 and defends against common web exploits such as SQL injection and cross-site scripting. Associating WAF with the ALB allows malicious requests to be filtered before they reach the EC2 instances, which minimizes application impact and avoids pushing inspection logic onto the hosts. CloudTrail, GuardDuty, and network ACLs are not the best tools for active application-layer request filtering against SQLi and XSS. Shield Advanced can add further protection for broader attack scenarios, but the key control in this answer is WAF on the ALB with rules that block malicious traffic patterns.

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

A. Fixed desired instances:Does not adapt to traffic load fluctuations, leading to inefficiencies.

B. Larger EC2 instances:Increases costs unnecessarily.

C. Target tracking scaling policy:Adjusts capacity based on actual demand, optimizing costs.

D. Instance store volumes:Not persistent and unsuitable for shared data across instances.

AWS recommends using Amazon ElastiCache as an in-memory caching layer in front of relational databases such as Amazon RDS to offload read traffic and significantly improve performance for read-heavy workloads. ElastiCache (Redis OSS) provides microsecond latency and can cache the results of frequent or expensive queries without requiring any change to the underlying database schema or engine. This directly addresses the requirement to improve performance without changing the database structure and with minimal operational overhead, because ElastiCache is a fully managed service (patching, failure detection, replacement, etc., are handled by AWS).

Option A (DynamoDB) would require a full data migration and application changes, including schema and query rewrites.

Option C (Memcached on EC2) introduces additional management overhead for EC2 instances (scaling, patching, HA).

Option D (DAX) is a caching layer only for DynamoDB and cannot be used directly with Amazon RDS.

AWS Security Hub provides a centralized view of security findings across AWS accounts and services. It integrates natively with AWS Config conformance packs, which evaluate compliance against industry standards such as CIS and PCI-DSS.

From AWS Documentation:

“AWS Security Hub aggregates, organizes, and prioritizes security alerts and compliance status across AWS accounts. Use AWS Config conformance packs to assess compliance with security frameworks.”

(Source: AWS Security Hub User Guide – Managing Findings and Compliance)

Why C is correct:

Security Hub provides a centralized dashboard for compliance visibility.

Conformance packs in AWS Config automate compliance checks across accounts.

Fully managed, minimal maintenance, and integrates natively with AWS services.

Why others are incorrect:

A: Conformance packs are not a feature of Amazon Inspector.

B: Third-party tools on EC2 require management and add operational overhead.

D: Systems Manager is not designed for compliance aggregation.

For infrequent or ad hoc querying of log data, Amazon S3 + Amazon Athena provides the most cost-effective, serverless, and scalable analytics solution.

From AWS Documentation:

“Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries that you run.”

(Source: Amazon Athena User Guide)

Why A is correct:

Amazon S3 offers durable, scalable, and cost-efficient storage.

Athena allows SQL-based querying on structured or semi-structured data like logs.

No need to provision or manage infrastructure.

Ideal for occasional querying at low cost.

Why the others are not optimal:

Option B: OpenSearch adds cost and is best for frequent, low-latency log querying.

Option C: RDS is not optimized for large-scale write-heavy log ingestion and costs more.

Option D: CloudWatch Logs is suitable for real-time monitoring, not for long-term storage and analytics of large log volumes.

To achieve high availability for the website, two key actions should be taken:

Amazon RDS for MySQL Multi-AZ: By migrating the database to an RDS for MySQL Multi-AZ deployment, the database becomes highly available. Multi-AZ provides automatic failover from the primary database to a standby replica in another Availability Zone, ensuring database availability even in the case of an AZ failure.

Application Load Balancer and Auto Scaling: Deploying an Application Load Balancer (ALB) in front of the EC2 instances ensures that traffic is evenly distributed across the instances. Configuring an Auto Scaling group to run EC2 instances across multiple Availability Zones ensures that the application remains available even if one instance or one AZ becomes unavailable. This setup enhances fault tolerance and improves reliability.

Why Not Other Options?:

Option A (Internet Gateway per AZ): Internet Gateways are region-wide resources and do not need to be provisioned per Availability Zone. This option does not contribute to high availability.

Option C (DynamoDB + Auto Scaling): DynamoDB would require changes to the application code to switch from MySQL, which is not possible per the question ' s constraints.

Option D (DataSync): AWS DataSync is used for data transfer and synchronization, not for achieving high availability for a database.

AWS References:

Amazon RDS Multi-AZ Deployments- Explanation of how Multi-AZ deployments work in Amazon RDS.

Application Load Balancing- Details on how to configure and use ALB for distributing traffic across multiple instances.

A. Kinesis Data Streams:Supports high throughput, strict ordering, multiple consumers, and data retention for 365 days.

B. SNS + SQS FIFO:Can enforce ordering but lacks native support for 500 KB messages and retention requirements.

C. EventBridge:Lacks strict ordering and message size compatibility.

D. SNS + Firehose:Not designed for strict ordering or large message sizes.

AWS Service Catalogallows organizations to centrally manage commonly deployed IT services and offers self-service deployment capabilities to customers. By creatingService Catalog products, the consulting company can package their solutions and tools for easy reuse by customers while maintaining central control over configuration and access. This provides a standardized and automated solution with the least operational overhead for managing and deploying solutions across different customers.

Option A (CloudFormation): CloudFormation templates are useful but don ' t provide the same level of management and user-friendly self-service capabilities as Service Catalog.

Option C (Systems Manager): Systems Manager is more focused on managing infrastructure and doesn ' t offer the same self-service capabilities.

Option D (AWS Config): AWS Config is used for tracking resource configurations, not for deploying solutions.

AWS References:

AWS Service Catalog

AWS WAF (Web Application Firewall) is designed to protect public-facing web applications from common web exploits and allows for deep inspection of HTTP and HTTPS requests. By enabling logging on AWS WAF, you can gain insights into traffic flow, request sources, and blocked requests, which improves both security visibility and posture. Integrating AWS WAF logging with Amazon Kinesis Data Firehose allows automatic, near-real-time delivery of log data to Amazon S3 for analysis, reporting, or integration with analytics tools. This solution not only secures the website but also enables comprehensive traffic analysis, satisfying both requirements efficiently.

Reference Extract from AWS Documentation / Study Guide:

" AWS WAF provides detailed logs of web requests, which can be delivered to Amazon S3 via Amazon Kinesis Data Firehose. This logging enables analysis of web traffic and sources, supporting both security and operational monitoring. "

Source: AWS Certified Solutions Architect – Official Study Guide, Security and Compliance section; AWS WAF Developer Guide (Logging and Monitoring).

AWS documentation states that the correct and least-privilege method for cross-account SNS-to-SQS integration is:

• Add specific SNS topic ARNs to the SQS queue policy.

• Allow only those topics to publish messages to the queue.

• Ensure SNS has permission to publish to the specific queue ARN.

This ensures strict scoping and adheres to least privilege.

Options A and D grant overly broad permissions. Option B allows publishing to any queue, which violates least privilege.

Amazon S3 with Amazon CloudFront:

Amazon S3 provides highly scalable and durable storage for petabytes of data.

Amazon CloudFront, as a content delivery network (CDN), caches frequently accessed data at edge locations to reduce latency. This combination is ideal for storing and accessing engineering drawings.

Incorrect Options Analysis:

Option B: Amazon S3 Glacier Deep Archive is for long-term archival storage, not frequent access.

Option C: Amazon EBS is unsuitable for large-scale, multi-user data access and does not support caching directly.

Option D: AWS Storage Gateway is for hybrid cloud storage, which is unnecessary for a fully cloud-based architecture.

The company is looking for a solution that provides single sign-on (SSO) across multiple AWS accounts while continuing to manage users and groups in their on-premises Active Directory (AD). AWS IAM Identity Center (formerly AWS SSO) is the recommended solution for this type of requirement.

AWS IAM Identity Centerprovides a centralized identity management solution, enabling single sign-on across multiple AWS accounts and other cloud applications. It can integrate with on-premises Active Directory to leverage existing users and groups.

By configuring a two-way forest trust relationship between AWS Directory Service for Microsoft Active Directory and the company ' s on-premises Active Directory, users can be authenticated by their on-premises AD and still access AWS resources through IAM Identity Center. This solution allows centralized management of AWS accounts within AWS Organizations.

The two-way trust allows mutual access between the on-premises AD and the AWS Directory Service. This means that users and groups in the on-premises AD can be used for authentication in AWS IAM Identity Center while maintaining the existing identity management system.

AWS References:

AWS IAM Identity Center Documentation

AWS Directory Service for Microsoft Active Directory Trust Relationships

AWS Directory Service Integration with IAM Identity Center

Why the other options are incorrect:

A. Create an Enterprise Edition Active Directory in AWS Directory Service: This would require setting up a new directory and managing it in AWS, which adds unnecessary overhead. The requirement is to continue using the existing on-premises AD, making this option unsuitable.

C. Use AWS Directory Service and create a two-way trust relationship: While this approach establishes a trust between on-premises AD and AWS Directory Service, it does not address the single sign-on (SSO) requirements across multiple AWS accounts through IAM Identity Center.

D. Deploy an identity provider (IdP) on Amazon EC2: This is more complex than necessary and introduces more management overhead. AWS IAM Identity Center natively supports integration with on-premises Active Directory without requiring a custom IdP.

AWS Step Functions is the recommended service for orchestrating multi-step, long-running workflows with state tracking, retries, and external API calls. It reduces operational overhead by eliminating the need for custom orchestration logic.

API Gateway receiving work items and sending them to SQS (Option E) provides buffering, elasticity, and decoupling, ensuring immediate ingestion regardless of backend load.

Option A forces Lambda to handle long execution paths, which is not optimal for 30-minute tasks and multi-state workflows. Option C triggers Lambda directly without buffering. Option D uses fixed EC2 instances, which does not scale dynamically.

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

The question focuses on minimizing costs while serving static content to users in the US and Europe.

Option Auses a single S3 bucket and configures CloudFront to limit edge locations, reducing costs by using fewer edge locations while still improving performance.

Option Bmaximizes edge locations, which increases costs unnecessarily.

Options C and Dinvolve storing data in multiple regions, which increases storage and operational costs.Thus, Option A is the most cost-effective solution.

DynamoDB Accelerator (DAX) is a fully managed, in-memory cache for DynamoDB that delivers up to a 10x performance improvement—even at millions of requests per second. DAX requires minimal changes to existing applications and offloads the read workload from DynamoDB during report generation.

Reference Extract:

" DAX provides in-memory acceleration for DynamoDB tables, reducing response times from milliseconds to microseconds with minimal application changes. "

Source: AWS Certified Solutions Architect – Official Study Guide, DynamoDB and Performance section.

This solution allows for secure and least-privilege access with minimal operational overhead.

IAM Identity Center: AWS IAM Identity Center (formerly AWS SSO) enables you to centrally manage access to multiple AWS accounts and applications. By using IAM Identity Center, you can assign permission sets that define what users or groups can access, ensuring that only necessary permissions are granted.

Permission Sets: Permission sets in IAM Identity Center allow you to define granular access controls for specific services, such as Amazon RDS and S3. You can tailor these permissions to meet the needs of different teams, adhering to the principle of least privilege.

Group Management: By assigning users to groups and associating those groups with specific permission sets, you reduce the complexity and overhead of managing individual IAM roles and policies. This method also simplifies compliance and audit processes.

Why Not Other Options?:

Option A (IAM roles): While IAM roles can provide least-privilege access, managing multiple roles and policies across teams increases operational overhead compared to using IAM Identity Center.

Option C (Individual IAM users): Managing individual IAM users and roles can be cumbersome and does not scale well compared to group-based management in IAM Identity Center.

Option D (AWS Organizations with cross-account roles): Creating separate accounts and cross-account roles adds unnecessary complexity and overhead for this use case, where IAM Identity Center provides a more straightforward solution.

AWS References:

AWS IAM Identity Center- Overview and best practices for using IAM Identity Center.

Managing Access Permissions Using IAM Identity Center- Guide on creating and managing permission sets for secure access.

Security groups are stateful, but they cannot explicitly deny traffic — only allow.

Network ACLs are stateless and support explicit deny rules.To prevent Application A from sending traffic to Application B, configure a deny outbound rule in the network ACL of Application A’s subnet to block traffic to Application B’s subnet.

“Unlike security groups, network ACLs support both allow and deny rules, enabling you to explicitly block traffic.”

— Network ACLs

This is the correct method to block outbound traffic between subnets.

Amazon EBS io2 Block Express volumes are designed to deliver sub-millisecond latency and up to 256,000 IOPS per volume, with durability and high availability. This makes io2 Block Express the recommended choice for workloads requiring very high and predictable IOPS, such as enterprise databases and high-transaction-rate applications.

Reference Extract:

" EBS io2 Block Express volumes deliver up to 256,000 IOPS and sub-millisecond latency, supporting high-performance, high-durability workloads. "

Source: AWS Certified Solutions Architect – Official Study Guide, EBS Performance section.

The most cost-effective and scalable solution for generating thumbnails when photos are uploaded to an S3 bucket is to useS3 event notificationsto trigger anAWS Lambda function. This approach avoids the need for a long-running EC2 instance or EMR cluster, making it highly cost-effective because Lambda only charges for the time it takes to process each event.

S3 Event Notifications: Automatically triggers the Lambda function when a new photo is uploaded to the S3 bucket.

AWS Lambda: A serverless compute service that scales automatically and only charges for execution time, which makes it the most economical choice when dealing with periodic events like photo uploads.

The Lambda function can generate the thumbnail and upload it to a second S3 bucket, fulfilling the requirement efficiently.

Option AandOption B(EMR or EC2 with scheduled scripts)**: These are less cost-effective as they involve continuously running infrastructure, which incurs unnecessary costs.

Option D (S3 Storage Lens): S3 Storage Lens is a tool for storage analytics and is not designed for event-based photo processing.

AWS References:

Amazon S3 Event Notifications

AWS Lambda Pricing

S3 Object Lock: Enables Write Once Read Many (WORM) protection for data, preventing objects from being deleted or modified for a set retention period.

S3 Versioning: Helps maintain object versions and ensures a recovery path for accidental overwrites.

CloudFront Distribution: Ensures secure and efficient public access by serving content through an edge-optimized delivery network while protecting S3 data with OAC.

Bucket Policy for OAC: Restricts public access to only the CloudFront origin, ensuring maximum security.

Amazon S3 Object Lock Documentation

The issue described is a classic case of read-heavy reporting workloads interfering with transactional application traffic. Although the RDS instance is configured for Multi-AZ, Multi-AZ deployments are designed for high availability and failover, not for scaling read performance. All reads and writes still occur on the primary instance, which explains why reporting queries negatively affect customer-facing performance.

Option C, adding an Amazon RDS read replica, is the most effective and AWS-recommended solution. Read replicas asynchronously replicate data from the primary instance and provide a separate endpoint for read-only workloads such as reporting, analytics, and dashboards. By redirecting the finance team’s reporting queries to the replica endpoint, the primary database is freed to handle transactional workloads, significantly improving overall application performance.

Option A (RDS Proxy) helps manage database connections efficiently, especially for bursty workloads, but it does not offload query execution or isolate heavy read traffic. Option B is invalid because RDS Multi-AZ does not support spreading a single DB instance across three AZs, and even if it did, it would not reduce read contention. Option D increases instance resources but does not solve the root cause; reporting queries would still compete with production traffic and would also increase cost unnecessarily.

Therefore, C is the optimal solution because it isolates reporting workloads, scales read capacity, improves application responsiveness, and aligns with AWS best practices for high-performance database architectures.

The correct recommendation is to useAWS Schema Conversion Tool AWS SCTtogether withAWS DMSand run afull load plus CDCmigration so Oracle and Aurora PostgreSQL stay synchronized during the staged application cutover. AWS prescriptive guidance for Oracle-to-Aurora PostgreSQL migration explicitly uses AWS SCT and AWS DMS for this pattern. Because the source workload has a high number of reads and writes, amemory-optimized replication instanceis the stronger fit for heavy replication activity. DataSync is not the service used for relational database migration. Selecting only the largest tables would not satisfy the requirement to keep all application data synchronized across the whole migration window.

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

Amazon CloudFront is a global content delivery network (CDN) that caches and distributes content to users with low latency. By setting the existing ALB as the origin, CloudFront can cache dynamic and static content closer to users worldwide, improving performance and reducing the load on the application servers. This is the most cost-optimized and AWS-recommended way to globally serve dynamic content for web applications.

Reference Extract:

" CloudFront accelerates delivery of both static and dynamic content, reducing latency and offloading origin resources by caching content at edge locations. "

Source: AWS Certified Solutions Architect – Official Study Guide, CloudFront and Global Application section.

The best answer is to enableS3 Block Public Access at the account leveland back it with theAWS Config s3-account-level-public-access-blocks ruleplus automated remediation. AWS states that S3 Block Public Access can be applied at the account level and overrides public bucket policies and ACLs so you can centrally prevent public access across the account. AWS Config provides a managed rule specifically for checking those account-level settings, and AWS Systems Manager includes an automation runbook to remediate drift. This is stronger and more scalable than relying on detection tools alone, because it both prevents exposure and automatically restores compliance if settings change. (AWS Documentation)

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

Lambda supports mounting an Amazon EFS file system inside your function to store larger dependencies beyond the 250 MB layer quota.

EFS automatically encrypts data in transit using TLS.

“You can configure your Lambda function to mount an Amazon EFS file system, enabling your function to access large amounts of data or large dependencies.”

“Amazon EFS automatically encrypts all data at rest and in transit.”

— Lambda with Amazon EFS

This is the least operational overhead approach.

IAM Access Analyzer analyzes permissions granted using policies to determine what resources are shared with an external entity, and helps identify excessive permissions or least privilege violations across all accounts in an AWS Organization. It is specifically designed for reviewing and refining IAM permissions with minimal administrative effort.

AWS Documentation Extract:

“IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. You can also use Access Analyzer policy checks to refine permissions and implement least privilege.”

(Source: IAM Access Analyzer documentation)

A: Network Access Analyzer is for VPC network access analysis, not IAM permissions.

B: CloudWatch alarms are not suitable for detailed permission analysis.

D: Amazon Inspector is for security vulnerability assessment, not IAM policy review.

Amazon ECS on AWS Fargate: AWS Fargate is a serverless compute engine for containers that works with Amazon ECS. It allows you to run containers without managing servers or clusters.

Amazon EFS: Amazon Elastic File System (EFS) provides a simple, scalable, fully managed elastic NFS file system for use with AWS Cloud services and on-premises resources. It can be mounted to ECS tasks running on Fargate, allowing containers to access a shared file system with standard file system semantics, including OS-level permissions.

AWS Secrets Manager is the recommended service for storing database credentials and performing automated rotation. Any Lambda function version or alias can fetch the latest secret value at runtime, ensuring no outdated credentials exist in deployed versions.

Environment variables (Option C) are static per version. Embedding credentials in code (Option B) is insecure and requires redeployment. Parameter Store (Option D) supports rotation but requires more configuration and is not as seamless as Secrets Manager for database credential rotation.

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

The correct answer isAbecause the application is aglobal Voice over IPworkload that needslow latency,high availability, andautomated failover across AWS Regions.AWS Global Acceleratoris specifically designed to improve the availability and performance of global applications by routing user traffic over the AWS global network to the optimal healthy endpoint. It usesstatic Anycast IP addresses, which means users connect through fixed IP addresses that do not depend on client-side DNS or IP address caching behavior.

This is especially valuable for latency-sensitive applications such as Voice over IP, where rapid routing decisions and fast failover are critical. Global Accelerator continuously monitors endpoint health and can automatically direct traffic to healthy endpoints in another AWS Region if a failure occurs. This supports the requirement for cross-Region failover with minimal disruption.

Option B is incorrect becauseRoute 53 geolocation routingdirects traffic based on user location, but DNS-based routing can be affected by client-side caching and does not provide the same performance acceleration or fast failover behavior as Global Accelerator. Option C is incorrect becauseAmazon CloudFrontis primarily a content delivery network for HTTP and similar content distribution scenarios, not the preferred service for real-time Voice over IP traffic. Option D is incorrect because anApplication Load Balancerdoes not by itself provide global routing or multi-Region failover.

AWS best practices for global, latency-sensitive applications recommendAWS Global Acceleratorwhen the goal is to improve performance, use the AWS backbone network, and provide health-based failover without depending on DNS cache expiration. Therefore,AWS Global Accelerator with health checksis the best solution.

To securely access AWS services like S3 and Secrets Manager from a private VPC without using public IPs, interface VPC endpoints are required. These endpoints are accessible via private IP addresses. For the application to reach these endpoints, appropriate routes must be configured in the route table.

AWS best practice is to use IAM roles with instance profiles for EC2 instances so that applications obtain temporary credentials automatically and do not need to store access keys.

To honor the principle of least privilege, each microservice should have an IAM role that grants only the specific permissions it needs.

Therefore, creating individual IAM roles per microservice and attaching them via instance profiles (Option D) both minimizes long-term credential management and applies least privilege cleanly.

Why others are not correct:

A: Using IAM users with access keys in code is insecure and high-overhead (key rotation, secret management).

B: A single broad role violates least privilege because every microservice gets more permissions than it needs.

C: Separate accounts per microservice is extreme over-segmentation and significantly increases operational complexity.

Workload Discovery on AWS is a tool that automatically discovers AWS resources across multiple accounts and Regions and builds visual architecture diagrams that show resource relationships. It is specifically designed to help teams understand and document existing workloads with minimal manual effort.

This service provides multi-account visibility, relationship mapping, and exportable diagrams, which directly satisfies the need to “build and map the relationship details of the various workloads” with the least operational overhead.

Systems Manager Inventory (Option A) focuses on collecting configuration and inventory data (primarily for instances and some resources) and does not generate architecture diagrams or full relationship views.

Step Functions (Option B) and X-Ray (Option D) would require custom collection and manual diagramming and are not purpose-built for environment discovery and mapping.

AWS Step Functions provides a low-code, fully managed workflow service with a visual interface to orchestrate AWS Glue jobs in sequence. Step Functions integrates natively with AWS Glue and can be triggered by Amazon EventBridge based on events or schedules.

AWS Documentation Extract:

“AWS Step Functions makes it easy to coordinate multiple AWS services into serverless workflows so you can build and update apps quickly. Step Functions provides visual workflows and integrates with AWS Glue for ETL orchestration.”

(Source: AWS Step Functions documentation)

A: Manual scripting and dashboards do not provide a low-code or integrated visual workflow.

C: QuickSight is for BI, not workflow visualization.

D: ECS adds unnecessary complexity.

AWS Spot best practices recommend diversifying capacity across multiple instance types and Availability Zones and using the capacity-optimized (price-capacity-optimized) allocation strategy to choose pools with the deepest capacity for higher availability. Adding a small On-Demand base in the Auto Scaling group maintains steady, uninterrupted baseline processing while keeping costs low and absorbing Spot interruptions. Option C (lowest price) increases interruption risk. Capacity Reservations (B) target On-Demand capacity guarantees and add cost, not needed for Spot-based elasticity. Option E is redundant; diversification is already achieved with (D). This combination maximizes resiliency of Spot workloads while preserving strong cost efficiency and aligns with AWS guidance for fault-tolerant, stateless applications on Spot.

To serve a static website hosted in Amazon S3 over HTTPS, you must use Amazon CloudFront because S3 does not natively support HTTPS for static website endpoints.

Steps to meet HTTPS requirement:

B. Create a CloudFront distribution and configure the S3 bucket as the origin. This enables global edge caching and performance optimization.

D. Attach an SSL/TLS certificate (typically from AWS Certificate Manager) to the CloudFront distribution to handle HTTPS connections.

S3 buckets used as static website hosts only support HTTP directly. While S3 supports HTTPS for REST API access, it does not support HTTPS on static website endpoints.

This setup aligns with security best practices and supports the Secure and Operational Excellence pillars of the AWS Well-Architected Framework.

???? References:

Hosting a static website using Amazon S3 and CloudFront

CloudFront + HTTPS with ACM

The critical requirement is immediate processing upon customer submission, with a typical compute duration of about 10 seconds. This is an ideal fit for a synchronous, request-driven, serverless pattern: API Gateway + AWS Lambda. API Gateway provides a managed HTTPS front door for the application, handles request validation/throttling if needed, and integrates directly with Lambda. Lambda is designed for short-lived computations, scales automatically with request volume, and can complete 10-second tasks well within typical Lambda execution limits.

Option A therefore meets the requirement with low latency and minimal operational overhead. When a customer submits data, API Gateway invokes the Lambda function immediately, and the function returns the calculated premium response. This preserves an interactive user experience and avoids provisioning or managing servers. It also handles bursts gracefully because Lambda concurrency can scale quickly, and API Gateway can absorb high request rates.

Option B is unsuitable because launching a Spot instance per upload introduces significant startup latency (instance launch time) and is not reliable due to Spot interruptions. Option C and D are not “immediate”: Transfer Family is for file transfers, and scheduled EKS jobs or Batch jobs introduce queuing and scheduling delays. While Batch can be event-driven, it is typically used for longer-running or batch-oriented workloads and still has job-start overhead compared to Lambda.

Therefore, A best matches the requirements for immediate execution, scalability, and low operational burden while maintaining responsive performance for customers.

Protecting an application from layer 7 (application layer) DDoS attacks is best achieved by using AWS WAF (Web Application Firewall), which provides customizable protection against common web exploits including DDoS attacks at the application layer. AWS WAF supports managed rule groups maintained by AWS, which offer robust, tested protections against OWASP top 10 vulnerabilities and common attack patterns without requiring extensive manual rule creation.

While AWS Shield Standard provides basic network-layer DDoS protection automatically at no additional charge, it does not offer application-layer filtering capabilities. Therefore, option A alone is insufficient.

Option B, involving only custom rules, requires significant operational overhead and expertise, whereas AWS managed rules offer a turnkey solution with ongoing updates from AWS security teams.

Option D, using CloudFront in front of the ALB, can provide additional protection benefits such as caching and geographic restrictions, but the question specifically asks for protecting against layer 7 DDoS on the ALB directly. CloudFront plus WAF is a valid enhanced solution, but the direct and recommended answer in AWS official documents is to use AWS WAF managed rules directly with ALB for application-level protection.

The correct answers areA and D. The requirement is to replace third-party middleware with an AWS-native solution that supportsasynchronous communication,exactly-once delivery, and theleast infrastructure management.Amazon SQS FIFO queuesare the best messaging component because FIFO queues are designed for workloads that requireordered processingandexactly-once message deliverysemantics. That makes optionDthe correct messaging choice.

For the compute layer,AWS Lambdaprovides the least infrastructure management because it is a fully managed serverless compute service. Lambda removes the need to manage virtual machines, operating systems, or cluster infrastructure. It integrates naturally with queue-based asynchronous architectures and can be invoked to process messages from SQS while scaling automatically based on queue depth and workload demand. That makes optionAthe best choice for minimizing operational burden.

Option B is incorrect because EC2 instances would require the company to manage instance provisioning, patching, scaling, and availability. Option C is incorrect becauseAmazon SNSis a pub/sub messaging service and does not provide exactly-once delivery guarantees likeSQS FIFO. Option E is incorrect becauseAmazon EKSintroduces Kubernetes management overhead and is not the lowest-management compute option.

AWS best practices recommend using managed messaging and serverless compute to reduce undifferentiated operational work. For a migration that requires asynchronous processing with exactly-once delivery and minimal infrastructure management, the most appropriate architecture isAWS Lambda functionswithAmazon SQS FIFO queues.

Amazon EFS integrates natively with Lambda, supports shared, persistent storage, and allows independent updates without redeploying functions. EBS and /tmp are not supported for this use case; FSx is unnecessary.

Amazon CloudWatch Container Insightsis designed for monitoring containerized environments like EKS. It provides native support for collecting and visualizing metrics and logs in a centralized location through CloudWatch dashboards, offering the most operationally efficient solution.

Option A:Using the CloudWatch agent provides basic metrics but lacks the specific insights required for containerized applications.

Option B:Kinesis Data Streams and Firehose add unnecessary complexity for this use case.

Option C:CloudTrail is for auditing API activity and is not designed for application metrics and log aggregation.

AWS Documentation References:

Amazon CloudWatch Container Insights

A mix of On-Demand Instances and Spot Instances is the best cost-optimized option when the company wants lower cost but does not want long-term commitments. On-Demand Instances provide baseline reliability and require no upfront payment or term commitment. Spot Instances can significantly reduce compute cost for flexible portions of the Auto Scaling group, as long as the application can tolerate replacement capacity when Spot capacity is interrupted. Reserved Instances require a commitment, so options B and D violate the requirement. Dedicated Instances are generally used for compliance or isolation requirements and do not optimize cost for a scalable web application. Auto Scaling groups can use multiple purchasing options to balance availability and cost.

A warm pool is an Auto Scaling feature that keeps instances in a pre-initialized state so they can quickly join the active group when scaling is required. This reduces the time needed for instance bootstrapping and makes new capacity available almost instantly. Option A only increases capacity limits but does not address slow boot times. Option C merely extends grace periods without solving the delay. Option D forces overprovisioning, which is wasteful and not aligned with cost optimization. Using a warm pool (B) directly addresses the problem by reducing response time to scaling events.

Amazon SQS is the AWS-recommended service for handling decoupled, scalable, ordered, durable message ingestion with potentially large workloads. It supports payloads up to 256 KB directly and up to several MB using S3-backed large-payload extensions.

Lambda functions can process messages from SQS with automatic scaling. ECS with the Fargate launch type provides a serverless container platform for the frontend, scaling based on demand without managing servers.

SNS (Options B and D) is not a queue, does not provide durable message buffering, and is not appropriate for variable, bursty workloads that may exceed backend throughput. Lambda@Edge (Options A and D) is unsuitable for backend order processing because it runs at CloudFront edge locations with strict limitations.

Amazon Route 53 Multivalue Answer Routing: This routing policy allows Route 53 to return multiple values, such as IP addresses, in response to DNS queries. This can distribute traffic across multiple resources and includes health checks to ensure traffic is only routed to healthy instances.

Health Checks:

Configure health checks for each Region to monitor the health of the website instances.

Route 53 will only include healthy instances in the DNS responses, ensuring that traffic is not routed to an unhealthy Region.

Load Distribution and Disaster Recovery:

Multivalue answer routing helps balance the load between instances in different Regions.

If instances in one Region become unhealthy, Route 53 will route traffic to the healthy instances in the other Region.

Operational Simplicity: This solution does not require complex configurations or additional resources, making it a simple yet effective way to distribute traffic and ensure high availability.

For applications requiring high network throughput and low latency between EC2 instances, AWS recommends using a Cluster Placement Group:

Cluster Placement Group: Packs instances close together inside an Availability Zone, enabling workloads to achieve the low-latency network performance necessary for tightly-coupled node-to-node communication.

Enhanced Networking: Selecting instance types that support enhanced networking provides higher bandwidth, higher packet-per-second (PPS) performance, and consistently lower inter-instance latencies.

By combining a Cluster Placement Group with enhanced networking-enabled instance types, the company can meet the stringent performance requirements of its real-time industrial application.

Because the workload follows apredictable business-hours schedule, the lowest-overhead solution is to usescheduled scalingwith EC2 Auto Scaling. AWS documentation states that scheduled actions let you scale an Auto Scaling group at specific times or on recurring schedules by changing desired, minimum, and maximum capacity. That directly matches a workload that needs instances during business hours and not at night. Manual start and stop actions add operational work, Spot Instances risk interruptions during business hours, and sizing for maximum load with Reserved Instances would overpay for idle time. Scheduled scaling automates the exact time-based pattern the question describes.

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

To allocate costs based on team ownership, AWS recommends tagging resources using cost allocation tags. Activating the “owner” tag as a cost allocation tag allows AWS Cost Explorer to categorize and group spending. Additionally, filtering for Amazon ECS services enables the visibility into service-specific usage. This approach is both scalable and operationally efficient.

To build a distributed, serverless, event-driven workflow with minimal operational overhead, AWS Step Functions orchestrating AWS Lambda is the best fit. Step Functions provides a managed state machine service that coordinates multiple steps, handles retries and error handling patterns, and maintains execution state without requiring the company to run orchestration servers. Lambda provides serverless compute for each workflow task, scaling automatically with demand and eliminating server management.

Option D directly matches “performing different aspects of the workflow” because Step Functions is specifically designed to model multi-step business processes and coordinate activities across services. It also aligns with “minimize operational overhead” because both Step Functions and Lambda are managed services: there are no instances to patch, no cluster management, and scaling is handled by the platform.

Option B contradicts the serverless goal by deploying the application on EC2 instances, increasing operational overhead (capacity management, patching, scaling, and availability concerns). Option C mixes eventing with scheduling: EventBridge can route events, but invoking Lambda “on a schedule” is not the same as orchestrating a multi-step workflow with branching, waiting, retries, compensation, and state tracking. EventBridge is excellent as an event bus, but Step Functions is the purpose-built workflow orchestrator. Option A is a mismatch because AWS Glue is primarily an ETL/data integration service; while it can run jobs and triggers, it is not the general workflow orchestrator for arbitrary application steps, and using it to invoke Lambda for a broad workflow is less direct and typically less operationally clean than a Step Functions state machine.

Therefore, D is the most aligned solution for serverless, distributed workflow orchestration with low operational burden.

For steady, predictable EC2 usage with potential changes in instance families over time, AWS recommends Savings Plans. Compute Savings Plans “apply to any EC2 instance regardless of region, instance family, operating system, or tenancy,” and also apply to AWS Fargate and AWS Lambda, delivering the most flexibility over a multi-year horizon. A 3-year term provides the highest discount among Savings Plans for long-lived workloads. EC2 Instance Savings Plans are limited to a chosen instance family in a region; as needs evolve (e.g., size or family changes), discounts may not fully apply. Spot Instances are not appropriate for long, interruption-sensitive jobs because Spot capacity can be reclaimed with short notice. Therefore, a Compute Savings Plan (3-year) best matches cost optimization with flexibility for growth and changes.

Comprehensive and Detailed 250 to 300 words of Explanation (AWS documentation-based, no links):

The requirements are straightforward: expose the Lambda microservice through an HTTPS endpoint and authenticate calls using IAM. Lambda function URLs are a built-in feature that provides a dedicated HTTPS endpoint for a Lambda function without requiring API Gateway, ALB, or CloudFront. When configured with the authentication type AWS_IAM, the endpoint requires requests to be signed with AWS Signature Version 4 and authorized by IAM policies. This directly satisfies the “must use IAM to authenticate calls” requirement with the least architectural complexity.

Option A can also secure an endpoint with IAM, but it proposes using a Lambda authorizer, which is typically used for custom authorizers (JWT/OAuth/Cognito/external identity). For IAM authentication in API Gateway, you generally use IAM authorization on the method, not an authorizer function. Also, API Gateway REST APIs introduce additional service configuration and per-request costs when a simpler managed option exists that meets the requirements.

Options C and D are not appropriate. Lambda@Edge and CloudFront Functions run at CloudFront edge locations with different programming and deployment models; they are designed for CDN request/response manipulation, not as the primary mechanism to expose a regional Lambda microservice endpoint with IAM authentication. CloudFront Functions in particular is for lightweight JavaScript at the edge and does not provide a native “AWS_IAM authentication type” for invoking an origin Lambda as a microservice endpoint.

Therefore, B is the cleanest and most secure fit: a native HTTPS endpoint backed by Lambda, protected with IAM-based SigV4 authentication.

The requirement is an event-driven pub/sub system that guarantees ordered delivery of events.

Amazon SNS FIFO topics provide the publish-subscribe model along with FIFO (First-In-First-Out) delivery and exactly-once message processing, ensuring ordered delivery to multiple subscribers.

Option A, EventBridge, provides event buses but does not guarantee event ordering across multiple subscribers. Option C (SNS standard topics) provides pub/sub but without ordering guarantees. Option D (SQS FIFO queues) guarantees order but are point-to-point queues, not pub/sub.

Thus, Amazon SNS FIFO topics meet the requirements for ordered pub/sub messaging.

The correct security-group design is to allow inbound database access from the EC2 instances’ security group rather than from individual IP addresses. AWS security groups can reference another security group as the source, which is the scalable and recommended approach for application-to-database communication in dynamic environments such as Auto Scaling groups. That way, newly launched instances automatically inherit access without requiring IP-based rule updates. Option A is brittle because private IPs change as instances scale. Option C is not how security-group rules are defined, and option D reverses the traffic direction. Therefore, allowing the database security group to accept traffic from the web-servers security group is the right architecture.

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

Workload Discovery on AWS automatically scans AWS accounts and Regions, identifies deployed resources, and generates relationship-aware architecture diagrams. This provides a complete workload map with minimal operational effort.

Systems Manager Inventory (Option A) collects instance metadata but does not build multi-account architecture diagrams.

Step Functions (Option B) and X-Ray (Option D) require manual diagramming and do not meet the operational-efficiency requirement.

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

AWS Transfer Family (SFTP) allows clients to use standard SFTP clients and SSH keys without changes. By enabling service-managed users, clients can continue uploading files with their existing tools.

The service delivers the files directly into S3, reducing latency between upload and processing. This removes the need for EC2, custom scripts, and periodic transfers. It fully meets the requirement for a managed solution with minimal disruption to client processes.

Amazon S3 Glacier Flexible Retrieval is a low-cost archival storage class that supports retrieval of data within minutes (expedited access ~1–5 minutes), making it ideal for audit scenarios where occasional, quick access to archived data is required. In contrast, Glacier Deep Archive takes hours to retrieve.

Amazon EFS is a “fully managed, elastic, shared file system” that provides NFSv4 access across many EC2 instances and AZs, ideal for lift-and-shift of Linux NFS workloads. AWS DataSync “automates moving data between on-premises NFS servers and Amazon EFS,” performing incremental, parallel transfers with encryption and integrity checks, enabling cutover with minimal disruption. FSx for Lustre (A) targets HPC and S3-backed workloads, not general NFS shares. FSx for Windows (D) exposes SMB, not NFS. S3 (C) is object storage and not directly NFS-accessible by multiple EC2 hosts. EFS + DataSync satisfies NFS compatibility, multi-client access, and low-touch migration while remaining cost-effective for a 200-GB dataset.

AWS best practices strongly recommend enabling MFA on the root user, but they also emphasize planning for MFA device loss. AWS allows the configuration of multiple MFA devices for the root user, which provides redundancy and ensures continued access in disaster scenarios. Option B directly addresses the requirement by enabling a backup authentication method without weakening security controls.

Adding multiple MFA devices ensures that if one device is lost, damaged, or unavailable, the organization can still authenticate securely using the secondary device. This approach maintains strong security while eliminating the risk of permanent root account lockout. It also avoids time-consuming recovery processes that require contacting AWS Support and proving account ownership.

Option A is not sufficient because IAM administrator accounts do not replace root access and cannot perform certain root-only actions. Options C and D are not feasible because new administrator accounts or policy changes cannot be made if root access is already lost.

Therefore, B is the correct and AWS-recommended solution to ensure uninterrupted, secure access to the root account while maintaining MFA protection.

Amazon FSx for Lustre is a high-performance file system optimized for fast processing of workloads such as machine learning, high-performance computing (HPC), and video processing. It integrates natively with Amazon S3, allowing you to:

Access S3 Data: FSx for Lustre can be linked to an S3 bucket, presenting S3 objects as files in the file system.

High Performance: It provides sub-millisecond latencies, high throughput, and millions of IOPS, which are ideal for ML workloads.Amazon Web Services, Inc.

Minimal Operational Overhead: Being a fully managed service, it reduces the complexity of setting up and managing high-performance file systems.

The company wants to move from an on-premises Docker environment to fully managed AWS services with persistent storage. The best fit is:

Amazon ECS with AWS Fargate launch type: This is a serverless container orchestration solution where AWS manages the underlying infrastructure, removing the need to manage EC2 or Kubernetes nodes.

Amazon EFS (Elastic File System): This is a fully managed, scalable, and shared file system for use with ECS tasks. It supports persistent storage for containers, replacing the local volumes used on-premises.

This combination (ECS + Fargate + EFS) is fully managed and requires no manual server maintenance.

Option A uses EKS with self-managed nodes, which is not fully managed.

Option C (DynamoDB) is for structured key-value storage, not for persistent file storage.

Option D uses ECS with EC2 launch type, which is not serverless and requires managing instances.

???? Reference:

Using Amazon ECS with AWS Fargate

Mounting EFS volumes in ECS tasks

Analysis:

The solution must handle variable sales volumes, preserve transaction information, and store data in an Amazon Aurora database with minimal operational overhead. UsingAPI Gateway, AWS Lambda, and SQSis the best option because it provides scalability, reliability, and resilience.

Why Option A is Correct:

API Gateway: Serves as an entry point for transaction data in a serverless, scalable manner.

AWS Lambda: Processes the transactions and sends them to Amazon SQS for queuing.

Amazon SQS: Buffers the transaction data, ensuring durability and resilience against spikes in transaction volume.

Second Lambda Function: Processes messages from the SQS queue and updates the Aurora database, decoupling the workflow for better scalability.

Dead-Letter Queue (DLQ): Ensures failed transactions are logged for later debugging or reprocessing.

Why Other Options Are Not Ideal:

Option B:

Using an ALB with ECS on EC2 introduces operational overhead, such as managing EC2 instances and scaling ECS tasks.Not cost-effective.

Option C:

EKS is highly operationally intensive and requires Kubernetes cluster management, which is unnecessary for this use case.Too complex.

Option D:

Amazon Data Firehose and DMS are not designed for real-time transactional workflows. They are better suited for data analytics pipelines.Not suitable.

AWS References:

Amazon API Gateway:AWS Documentation - API Gateway

AWS Lambda:AWS Documentation - Lambda

Amazon SQS:AWS Documentation - SQS

Amazon Aurora:AWS Documentation - Aurora

The requirement to “have access to the operating system” means the compute layer must be Amazon EC2 (or containers on EC2). Managed runtimes such as Lambda and Fargate do not provide OS-level access.

The requirement for a “low-latency NoSQL database” maps directly to Amazon DynamoDB, which is a fully managed NoSQL key-value and document database that provides single-digit millisecond latency at any scale.

Because the application runs in a private subnet, AWS best practice is to access DynamoDB privately via a VPC endpoint (gateway endpoint for DynamoDB). This avoids traversing the public internet and simplifies security.

An instance profile (EC2 role) is the recommended method to grant EC2 instances permission to access DynamoDB without hardcoding credentials.

Why the other options are not correct:

B: Lambda does not provide OS access, which violates the security requirement.

C: Fargate does not provide OS access, and Aurora PostgreSQL is a relational database, not NoSQL.

D: S3 + Athena is an analytics pattern, not a low-latency NoSQL database solution; query latency is much higher and not suitable for OLTP-style app storage.

For application access to AWS services from ECS tasks, the correct identity is the ECS task role. AWS separates the task execution role, which is mainly for pulling images and sending logs, from the task role, which is used by the application code running inside the container. Because the application itself needs to read from S3, the least-effort and most secure design is to grant the necessary S3 permissions directly to the task role. Using IAM users and access keys would introduce unnecessary credential management and reduce security. Therefore, assigning the required S3 permissions to the task role is the proper AWS best-practice solution.

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

Amazon SQS with a 2-day retention ensures the data lives just as long as needed. EventBridge Pipes allow direct integration between event producers and consumers, with optional filtering and transformation. AWS Step Functions supports manual approval steps, which fits the workflow requirement perfectly.

State Machine Testing with Logs:

Changing the log level to ALL enables capturing detailed request and response data. This helps verify HTTP headers, body, and responses.

Incorrect Options Analysis:

Option A and B: The TestState API is not a valid option for Step Functions.

Option C: A data flow simulator does not exist for AWS Step Functions.

AWS Global Accelerator is a service that improves global application availability and performance using the AWS global network. It supports both TCP and UDP protocols and provides optimized routing and lower latency for real-time applications such as VoIP, regardless of where the user is located globally.

AWS Documentation Extract:

" AWS Global Accelerator uses the AWS global network to optimize the path to your application endpoints, improving performance for TCP and UDP traffic, such as VoIP. "

(Source: AWS Global Accelerator documentation)

B: CloudFront accelerates HTTP/S content, not TCP/UDP.

C: Route 53 geoproximity routing is for DNS-based routing, not for traffic acceleration.

D: Network Load Balancers support TCP/UDP, but do not address global latency or provide acceleration.

AWS Outposts brings native AWS services (including Amazon EMR) on-premises, ideal when data residency or latency constraints require local processing.

You benefit from AWS’s managed services while meeting the requirement to keep data processing local.

Amazon Aurora PostgreSQL with Aurora Global Database is the strongest fit because it supports low-latency reads in secondary Regions and provides fast disaster recovery for a globally available database architecture. Migrating from PostgreSQL on EC2 to Aurora PostgreSQL reduces database management overhead and improves resilience compared with self-managed EC2. Aurora Global Database is designed for cross-Region replication with very low replication lag and fast secondary Region promotion, which supports the required RTO and RPO of less than 5 minutes. AWS Backup restoration is too slow for this recovery objective. Elastic Disaster Recovery protects the EC2 instance but does not address query latency as effectively. RDS cross-Region read replicas with manual promotion are less suitable for strict RTO/RPO targets.

Amazon S3 Standard-IA: This storage class is designed for data that is accessed less frequently but requires rapid access when needed. It offers lower storage costs compared to S3 Standard while still providing high availability and durability.

Access Patterns: Since the files are frequently accessed in the first 30 days and rarely accessed afterward, transitioning them to S3 Standard-IA after 30 days aligns with their access patterns and reduces storage costs significantly.

Lifecycle Policy: Implementing a lifecycle policy to transition the files to S3 Standard-IA ensures automatic management of the data lifecycle, moving files to a lower-cost storage class without manual intervention. Deleting the files after 4 years further optimizes costs by removing data that is no longer needed.

Amazon CloudFront is a content delivery network (CDN) service that caches copies of your content at edge locations around the world. This helps improve performance by serving content from the edge nearest to the user. However, when the content in Amazon S3 (your origin) is updated, those updates may not immediately reflect on the website if they are cached at the CloudFront edge locations.

The issue described in the question suggests that the CI/CD pipeline is functioning correctly, and updates are being deployed to S3. However, since CloudFront caches this content, the edge locations may still be serving outdated content, causing the updates to not be reflected on the website.

To resolve this issue, you need to invalidate the CloudFront cache. By invalidating the cache, CloudFront will remove the outdated content and retrieve the latest version from the S3 origin.

AWS documentation on this process:

CloudFront cache invalidation allows you to clear items from the cache so that CloudFront retrieves the latest version from the origin. You can create invalidation requests via the AWS Management Console, AWS CLI, or SDKs.

AWS CloudFront Documentation

Why the other options are incorrect:

A. Add an Application Load Balancer: ALBs are used to distribute incoming application traffic and are not relevant to caching or serving content from CloudFront.

B. Add Amazon ElastiCache for Redis or Memcached: This would help in caching database queries but has no relation to static website content hosted on CloudFront and S3.

D. Use AWS Certificate Manager (ACM): ACM is used for managing SSL/TLS certificates and is unrelated to the issue of content not being updated on CloudFront.

To run RDS instances only during business hours with the least operational overhead, you can useAmazon EventBridgeto schedule events that invokeAWS Lambda functions. The Lambda functions can be configured to start and stop the RDS instances based on the specified schedule (business hours). EventBridge rules allow you to define recurring events easily, and Lambda functions provide a serverless way to manage RDS instance start and stop operations, reducing administrative overhead.

Option A: While CloudWatch alarms could be used, they are more suited for monitoring, and using Lambda with EventBridge is simpler.

Option B (Trusted Advisor): Trusted Advisor is not ideal for scheduling tasks.

Option C (Systems Manager): Systems Manager could also work, but EventBridge and Lambda offer a more streamlined and lower-overhead solution.

AWS References:

Amazon EventBridge Scheduler

AWS Lambda

Using API Gateway and Lambda enables serverless handling of form submissions with minimal cost and infrastructure. When coupled with Amazon SNS, it allows instant email notifications without running servers, making it ideal for low-traffic workloads.

This question centers on improving scalability and global access performance.

Auto Scaling groups enable EC2 instances to scale dynamically in response to demand, ensuring availability during peak hours without manual intervention. Amazon RDS read replicas offload read traffic, improving read throughput and reducing latency on the primary database instance. Deploying Amazon CloudFront with S3 as origin accelerates delivery of static transaction documents globally by caching content at edge locations, reducing latency for users worldwide.

Option B focuses on vertical scaling (larger instances) and caching with ElastiCache, but it does not address global content delivery optimally. AWS Global Accelerator accelerates network traffic but is better suited for accelerating TCP and UDP traffic; CloudFront is generally preferred for HTTP content delivery.

Option C migrates workloads to Lambda and Aurora global databases, which is an advanced and potentially costly redesign that may not be necessary. Option D suggests moving to ECS and multi-AZ RDS but does not address global content delivery efficiently.

Therefore, option A uses proven scalability and caching best practices aligned with AWS Well-Architected Framework pillars for performance and operational excellence.

The most effective and AWS-recommended way to mitigate unwanted traffic at the edge is to use AWS WAF integrated with CloudFront. Option D allows the architect to block or throttle malicious traffic before it reaches the ALB or EC2 instances.

Rate-based rules automatically block IP addresses that exceed a defined request threshold, making them ideal for mitigating abusive traffic patterns. This reduces load on backend resources and improves performance for legitimate users.

Options A, B, and C are less effective or introduce unnecessary cost and complexity. Shield does not provide granular rate control, Auto Scaling increases cost, and NACLs are difficult to manage dynamically.

Therefore, D is the correct and most secure solution.

The problem is contention between two very different workloads that currently share one target group and one scaling boundary. The correct fix is to useALB path-based routingso /reports and /generateToken go toseparate target groups, each backed by its own Auto Scaling group. AWS ALB listener rules support path-based routing, which lets different paths scale independently and isolates the latency-sensitive /generateToken path from the CPU-heavy /reports workload. Making the instances larger does not remove the contention boundary, and CloudFront is not the right answer for two dynamic uncached paths. Therefore, splitting the paths into independent target groups and scaling units is the best architecture.

DAX does not support enabling encryption at rest on an existing cluster. To use encryption at rest, you must create a new DAX cluster with encryption enabled at creation time and migrate workloads accordingly.

When operating in disconnected or limited-connectivity environments, such as ships at sea, AWS recommends using AWS Snowball Edge devices to host local compute and storage workloads. Snowball Edge supports Amazon EC2 instances and AWS IoT Greengrass, and can run Amazon EKS Anywhere for local Kubernetes cluster deployments.

From AWS Documentation:

“You can use AWS Snowball Edge devices to run compute-intensive applications in remote or disconnected locations. Snowball Edge devices support running Amazon EC2 instances and Amazon EKS Anywhere clusters.”

(Source: AWS Snow Family – Developer Guide)

Why A is correct:

Snowball Edge provides local compute and storage even without internet connectivity.

Multiple Snowball Edge devices can be clustered together for high availability and failover.

Fully self-contained environment suitable for ships or field operations.

Why the others are incorrect:

B, C, D require network connectivity to AWS Regions or Zones (Local Zone, Outposts, Wavelength), which is not available at sea. These options cannot operate fully disconnected.

AWSDirect Connectis the best solution for establishing a consistent, low-latency connection from an on-premises data center to AWS without using the public internet. Direct Connect offers dedicated, high-throughput, and low-latency network connections, which are ideal for performance-sensitive applications like a trading platform that processes high volumes of market data and stock trades.

Direct Connect provides a private connection to your AWS VPC, ensuring that data doesn ' t traverse the public internet, which enhances both security and performance consistency.

AWS References:

AWS Direct Connectprovides a dedicated network connection to AWS services with consistent, low-latency performance.

Best Practices for High Performance on AWSfor performance-sensitive workloads like trading platforms.

Why the other options are incorrect:

A. AWS Client VPN: While this offers secure connectivity, it ' s over the public internet and is not designed for the low-latency, high-performance needs of a trading platform.

C. AWS PrivateLink: PrivateLink is used for connecting VPCs and services within AWS, but it is not designed for connecting on-premises data centers to AWS.

D. AWS Site-to-Site VPN: Although this provides secure connectivity, it uses the public internet, which can introduce latency and doesn ' t meet the low-latency requirements of the use case.

Amazon Route 53 supports failover routing policies, which use health checks to route DNS queries to a secondary Region only if the primary endpoint fails. This design ensures only one Region is active for traffic at any given time. This is the recommended architecture for active-passive, multi-Region DR strategies.

AWS Documentation Extract:

“Failover routing lets you route traffic to a primary resource, such as a web server in one Region, and a secondary resource in another Region. If the primary fails, Route 53 can route traffic to the secondary resource automatically.”

(Source: Amazon Route 53 documentation, Routing Policy Types)

A, D: These options do not configure DNS failover for external users.

C: Geolocation routing is for regional distribution, not DR failover.

The least-privilege design is to create an IAM policy that explicitly lists the full ARNs of only the S3 buckets the application must access, then attach that policy to the ECS task role. The ECS task role provides AWS permissions directly to the application container, which is the correct identity boundary for ECS workloads. Attaching permissions to the instance role is broader because all tasks on the container instance could potentially inherit access through the EC2 host role. A wildcard ARN is not least privilege because it can unintentionally match extra buckets. Tag-based access can be useful in some ABAC designs, but the requirement is a specific group of buckets in one account and Region; explicit ARNs provide clearer least-privilege access.

EC2 Auto Scaling warm pools allow you to pre-initialize instances, reducing the delay in scale-out events. This results in significantly faster response times during demand surges while remaining cost-effective compared to always running at peak capacity.

Amazon SQS is a fully managed message queuing service that reliably decouples and scales microservices, distributed systems, and serverless applications. By using SQS, microservices can communicate asynchronously, handle bursts of traffic, and avoid data loss by buffering messages until they are processed. Deploying the services on ECS with AWS Fargate further reduces operational overhead by removing the need to manage servers, allowing independent scaling of each microservice.

Reference Extract:

" Amazon SQS decouples application components and enables message durability and scaling. AWS Fargate removes the need to manage infrastructure, supporting independent scaling and minimal operational overhead. "

Source: AWS Certified Solutions Architect – Official Study Guide, Microservices and Messaging section.

Amazon EFS provides a shared, elastic, low-latency file system that can be mounted concurrently by many EC2 instances across multiple Availability Zones, delivering strong read-after-write consistency so all instances see updates almost immediately. This is the standard pattern for CMS-style workloads that require shared, up-to-date assets with minimal lag. Syncing local copies from S3 (C) introduces polling windows and eventual consistency delays; hourly sync is not near-real time. Copying from a “newest instance” (A) is brittle and not scalable. EBS volumes/snapshots (D) are single-instance, single-AZ block devices and not designed for multi-writer sharing across instances/AZs. EFS’s multi-AZ design and POSIX semantics provide the simplest, most reliable solution with the least operational overhead.

To automatically identify sensitive data in Amazon S3 and monitor access patterns for suspicious activities:

Amazon Macie uses machine learning and pattern matching to discover and protect sensitive data in S3. It provides visibility into data security risks and enables automated protection against those risks.

Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect AWS accounts and workloads. It analyzes events from AWS CloudTrail, VPC Flow Logs, and DNS logs.

By enabling both services, the company can automate the discovery of sensitive data and continuously monitor access patterns for potential security threats.

To track costs associated with different teams within a single AWS account, the company should implement user-defined cost allocation tags.

Tagging Resources with CostCenter: Assign the CostCenter tag to all resources, specifying the appropriate value for each team. This practice enables the organization to categorize and track AWS costs effectively.

Activating the CostCenter Tag: After tagging resources, activate the CostCenter tag in the AWS Billing and Cost Management console. Activation is necessary for the tags to appear in cost allocation reports and AWS Cost Explorer.

By following these steps, the company can generate detailed billing reports that break down costs by team, facilitating better cost management and accountability.

API Gatewayresource policiesare the native way to control who can invoke a REST API, including allowing access from specified AWS accounts. AWS documentation says resource policies can be attached to an API to control whether specified principals can invoke it, and it explicitly lists users from a specified AWS account as a supported use case. Private APIs are callable through interface VPC endpoints, but the primary authorization control for which external accounts may invoke the API is the API’s resource policy. Endpoint policies can add controls on the VPC endpoint side, but the clean cross-account access control for the API itself is the resource policy.

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

To decouple distributed workloads and improve scalability and resiliency, Amazon SQS should be used as a reliable job queue. The compute nodes (workers) can poll the SQS queue for tasks, and EC2 Auto Scaling can dynamically scale instances based on the ApproximateNumberOfMessages metric.

From AWS Documentation:

“Amazon SQS enables you to decouple application components, allowing each part to scale independently. You can scale EC2 instances automatically based on the number of messages in the queue.”

(Source: Amazon SQS Developer Guide – Scaling Consumers with Auto Scaling)

Why B is correct:

Eliminates the single point of failure (the primary coordinator).

Enables event-driven scaling based on queue depth.

Provides durability and resiliency since messages are stored redundantly.

Fully managed and integrates seamlessly with Auto Scaling policies.

Why other options are incorrect:

A: Scheduled scaling does not respond to variable workloads.

C & D: Misuse of CloudTrail/EventBridge; not intended for workload coordination.

To meet the requirement of deleting objects older than 3 years while retaining certain data, this solution leverages serverless technologies to minimize operational overhead.

S3 Inventory: S3 Inventory provides a flat file that lists all the objects in an S3 bucket and their metadata, which can be configured to include data such as the last modified date. This inventory can be generated daily or weekly.

AWS Lambda Function: A Lambda function can be created to process the S3 Inventory report, filtering out the objects that need to be retained and identifying those that should be deleted.

S3 Batch Operations: S3 Batch Operations can execute tasks such as object deletion at scale. By invoking the Lambda function through S3 Batch Operations, you can automate the process of deleting the identified objects, ensuring that the solution is serverless and requires minimal operational management.

Why Not Other Options?:

Option A (AWS CLI script on EC2): Running a script on an EC2 instance adds unnecessary operational overhead and is not serverless.

Option B (AWS Batch): AWS Batch is designed for running large-scale batch computing workloads, which is overkill for this scenario.

Option C (AWS Glue + script): AWS Glue is more suited for ETL tasks, and this approach would add unnecessary complexity compared to the serverless Lambda solution.

AWS References:

Amazon S3 Inventory- Information on how to set up and use S3 Inventory.

S3 Batch Operations- Documentation on how to perform bulk operations on S3 objects using S3 Batch Operations.

Option Bis the correct solution because:

AWS Security Token Service (STS)allows the web application to request temporary security credentials that grant access to AWS resources. These temporary credentials are secure and short-lived, reducing the risk of misuse.

Using STS and IAM roles ensures scalability by enabling the application to dynamically assume roles with the required permissions for each AWS service.

Option A:Assigning IAM roles directly to instances is less flexible and would grant the same permissions to all applications on the instance, which is not ideal for a multi-service web application.Option C:AWS IAM Identity Center is used for managing single sign-on (SSO) for workforce users and is not designed for granting programmatic access to web applications.Option D:Storing long-term access keys, even in AWS Systems Manager Parameter Store, is less secure and does not scale well compared to temporary credentials from STS.

AWS Documentation References:

AWS Security Token Service (STS)

IAM Roles for Temporary Credentials

Amazon FSx for ONTAP supports both NFS and SMB protocols and includes automated tiering between SSD and capacity pool storage, optimizing cost and performance. It is ideal for mixed operating systems and varied access patterns with minimal administrative overhead.

Amazon ECS with Application Auto Scaling, an Application Load Balancer, and CloudFront is the strongest architecture because it supports scale, high availability, and lower operational overhead while allowing the company to reuse the existing application code through containerization. The ALB distributes traffic across ECS tasks and supports health checks. ECS Service Auto Scaling automatically adjusts running tasks based on demand, allowing the application to handle millions of requests. CloudFront improves global delivery by caching content and routing users through edge locations. A self-managed Kubernetes cluster in one Availability Zone is not highly available and creates unnecessary management work. API Gateway and Lambda would require application redesign. Keeping the origin on premises does not meet the migration goal.

Regulatory compliance often requires immutability, meaning data cannot be altered or deleted by any user, including administrators, during a retention period. Amazon S3 Object Lock in compliance mode is specifically designed for this requirement.

Option B enforces a write-once-read-many (WORM) model. Once compliance mode is enabled and a retention period is set, no one—including root users—can delete or overwrite the objects until the retention expires. This provides the strongest level of protection and satisfies strict regulatory standards.

Option A (governance mode) allows privileged users to override the lock, which may not satisfy regulatory mandates. Option C does not prevent deletion or modification before retention expiration. Option D addresses storage cost, not immutability.

Therefore, B is the correct solution for regulatory-grade data protection.

Amazon DynamoDB provides single-digit millisecond performance at any scale and is fully managed to handle millions of catalog records. It is ideal for structured catalog data such as product metadata and scales seamlessly during high-traffic events like sales. Amazon S3 is optimized for storing unstructured large objects such as videos and manuals, with virtually unlimited scalability and high durability. Option A (RDS) would not handle massive scale or traffic spikes as efficiently. Option C overloads DynamoDB by forcing it to store large binary data, which is not its purpose. Option D (DocumentDB) is suitable for JSON-like documents but not optimal for storing large media files and would add operational complexity. Therefore, option B represents the best separation of structured and unstructured data storage.

For globally distributed consumers of REST APIs, API Gateway edge-optimized endpoints “route requests to the nearest CloudFront edge location, which then forwards them to your API in the [home] Region,” reducing latency for users worldwide and scaling automatically for unknown or spiky traffic. By contrast, Regional endpoints are intended for clients within the same or nearby Region and do not provide global edge acceleration. AWS Lambda provides automatic scaling for serverless backends; latency can be further reduced by right-sizing memory (which also increases CPU) and, when needed, enabling provisioned concurrency to keep functions initialized and eliminate cold starts for critical paths. Using NLBs across Regions is not serverless and adds operational complexity without CloudFront edge acceleration. Therefore, combining API Gateway edge-optimized REST APIs with Lambda meets the requirements of minimal global latency and unknown initial traffic.

The requirements are high availability, scalability for traffic spikes, and least administrative overhead. Option C matches established AWS reference patterns: use an Application Load Balancer + Auto Scaling group for the web tier and a managed database service with Multi-AZ for the database tier.

For the web application, placing EC2 instances in an Auto Scaling group across multiple Availability Zones allows the fleet to scale out automatically during the promotional event and to scale in afterward, preserving performance while controlling cost. The Application Load Balancer distributes requests across instances and AZs and removes unhealthy instances from rotation, improving availability.

For the database, Amazon RDS Multi-AZ is the simplest managed HA solution for relational engines, including SQL Server. Multi-AZ provides synchronous replication to a standby instance in another Availability Zone and supports automatic failover. This reduces administrative effort because AWS handles replication, failover orchestration, backups, and underlying infrastructure maintenance within service capabilities. It also ensures database availability during instance or AZ-level disruptions.

Option A is problematic because RDS for SQL Server does not use read replicas as the primary HA mechanism the way Aurora does, and focusing on replicas does not directly address HA in the simplest supported form. Option B and D rely on self-managed SQL Server on EC2, which requires significant operational overhead (patching, backups, replication setup, failover testing, monitoring, and recovery). Option B also suggests multi-Region replication, which adds complexity and is not required to meet “highly available and scalable” for a single-event scale scenario.

Therefore, C provides scalable compute with managed load balancing and managed database high availability, meeting the requirements with the least operational burden.

This solution offers the most scalable and cost-effective approach with minimal changes to the existing web portal and no code modifications.

Amazon EC2 On-Demand Instances in an Auto Scaling Group: Running the web portal on EC2 On-Demand instances ensures 100% uptime and scalability. The Auto Scaling group will maintain the desired number of instances, automatically scaling up or down as needed, ensuring high availability for the employee web portal.

AWS Lambda for Document Extraction: Lambda is a serverless compute service that allows you to run code in response to events without provisioning or managing servers. By using Lambda to run the document extraction program, you can trigger the function whenever an employee uploads a document. This approach is cost-effective since you only pay for the compute time used by the Lambda function.

No Code Changes Required: This solution integrates with the existing infrastructure with minimal implementation effort and does not require any modifications to the web portal ' s code.

Why Not Other Options?:

Option B (Spot Instances): Spot Instances are not suitable for workloads requiring 100% uptime, as they can be terminated by AWS with short notice.

Option C (Savings Plan): A Savings Plan could reduce costs but does not address the requirement for running the document extraction program efficiently or without code changes.

Option D (S3 with API Gateway and Lambda): This would require significant changes to the existing web portal setup, including moving the portal to S3 and reconfiguring its architecture, which contradicts the requirement of minimal implementation effort and no code changes.

AWS References:

Amazon EC2 Auto Scaling- Information on how to use Auto Scaling for EC2 instances.

AWS Lambda- Overview of AWS Lambda and its use cases.

To manage EC2 instances with AWS Systems Manager (SSM), the EC2 instance must be configured as a managed instance by attaching an IAM role that has the AmazonSSMManagedInstanceCore managed policy.

This policy allows:

SSM agent to register the instance with SSM

Perform actions like patching, automation, session management, inventory collection, etc.

Access to SSM endpoints (via internet or VPC endpoint if needed)

Since the EC2 instance already has an IAM role, the least operational overhead option is to attach the required policy to the existing role (Option C). No need to create new IAM roles or users, which simplifies management and adheres to the principle of least privilege.

Patching can then be automated via SSM Patch Manager, ensuring consistency, compliance, and operational efficiency.

???? References:

SSM Managed Instance Setup

AmazonSSMManagedInstanceCore Policy

Patching EC2 with SSM

To securely publish messages to an encrypted Amazon SNS topic, the following steps are required:

A. Resource policy for SNS topic:Ensures that the Lambda function is explicitly allowed to publish messages to the topic.

C. Resource policy for KMS key:Provides the necessary permissions to use the customer-managed key for encryption.

F. Lambda execution role:Grants the Lambda function the necessary IAM permissions to use the encryption key.

Other options:

Bis invalid because using SSE-KMS does not eliminate the need for resource policies.

Doverlaps with A, but specifying the ARN in the topic policy is covered by creating the resource policy.

Eis unrelated as API Gateway is not required for this setup.

AWS Documentation Reference:

Amazon SNS and KMS Permissions

Explanation (AWS Docs):

You cannot “place” DynamoDB inside a VPC. Instead, you use a VPC endpoint.

A Gateway VPC Endpoint for DynamoDB enables private connectivity between your VPC and DynamoDB without traversing the public internet.

“Use a gateway VPC endpoint to privately connect your VPC to DynamoDB without requiring an internet gateway or NAT.”

— Gateway VPC Endpoints

Comprehensive and Detailed Explanation (paraphrased from AWS Solutions Architect guidance):

Amazon Route 53 latency-based routing is specifically designed to route users to the endpoint that provides the lowest latency, based on actual latency measurements between AWS Regions and users’ networks. This directly supports the goal of optimizing load times (performance).

For non-AWS endpoints (like an on-premises data center), Route 53 lets you create a latency routing record and associate it with the AWS Region that is closest to that endpoint. In this case, the on-premises data center is near us-west-1, so you associate that latency record with the us-west-1 Region.

Users for whom the eu-central-1 Region has lower latency will be routed to the AWS website in eu-central-1.

Users for whom the us-west-1–associated endpoint has lower latency will be routed to the on-premises website.

This matches AWS best practices for high-performance, low-latency architectures when you have multiple endpoints in different geographic locations, including a mix of AWS and on-premises resources.

Why the other options are not correct:

Option A (Failover routing):

Failover routing is designed for high availability and disaster recovery (active–passive), not for optimizing latency.

All traffic goes to the primary endpoint (eu-central-1) unless it is unhealthy. That does not choose the lowest-latency endpoint for each user, so it does not meet the “optimize load times as much as possible” requirement.

Option B (IP-based routing):

IP-based / geo-based policies are about directing users based on location information (IP/geo), not measured latency.

You would have to manually decide which IP ranges get which endpoint, which does not guarantee that each user goes to the lowest-latency endpoint. It’s less precise and less dynamic than latency-based routing.

Option D (Weighted routing):

Weighted routing splits traffic according to fixed weights (e.g., 50/50), regardless of user location or latency.

This is useful for testing, blue/green deployment, or gradual traffic shifting, but not for performance optimization per user.

Therefore, the only option that directly aligns with AWS guidance for performance optimization and latency-based traffic steering across Regions and on-premises endpoints is:

✅ C. Create a DNS record with a latency-based routing policy… associate the on-premises endpoint with us-west-1.

UsingAD ConnectorwithAWS IAM Identity Center(formerly AWS Single Sign-On) allows the company to leverage its existingon-premises Active Directoryfor centralized identity management and access control. AD Connector acts as a proxy to the on-premises AD withoutrequiring additional infrastructure or complex setup. This solution integrates seamlessly with AWS, allowing the development team to use their existing AD credentials to access AWS resources across multiple accounts managed by AWS Organizations. The permissions for AWS resources can be managed centrally through IAM Identity Center by configuring permission sets.

This solution provides:

Least operational overhead: AD Connector is fully managed, and IAM Identity Center allows centralized management of permissions across accounts.

Secure access: The solution complies with security policies by using existing AD authentication mechanisms.

Option A (AWS Managed AD): Setting up a fully managed AWS AD and establishing a trust is more complex and involves additional operational overhead.

Option B (IAM Users): Manually managing IAM users and permissions is less scalable and increases operational complexity.

Option D (Cognito): Amazon Cognito is more suited for user-facing applications rather than internal identity management for AWS resources.

AWS References:

AD Connector with IAM Identity Center

AWS IAM Identity Center

AWS DataSync is the best fit because it is a managed service designed for repeated data movement between supported storage systems, includingAmazon S3andAmazon EFS. AWS documents that DataSync tasks can be configured to transferonly data that has changedby using theCHANGEDtransfer mode, which matches the overwrite-if-changed requirement. That removes the need to build custom synchronization code with Lambda or EC2. DataSync also has native support for S3 locations and EFS locations, so it directly covers both destinations in the question. Option A is therefore the lowest-overhead and most maintainable solution.

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

To improve read performance for a MySQL-based RDS database under load, you can:

Use Read Replicas: Amazon RDS supports MySQL read replicas, which help offload read operations from the primary database, improving performance during high traffic.

Use ElastiCache (Memcached): Adding an in-memory cache layer using Amazon ElastiCache reduces the load on the RDS instance by serving frequent queries directly from memory, especially when data is not updated often.

Option A (AWS WAF) is for web security, not database performance. Option D relates to storage optimization, not query latency. Option E would require re-architecting from relational to NoSQL, which is unnecessary and disruptive.

S3 One Zone-IA:

Suitable for infrequently accessed data that doesn ' t require multiple Availability Zone resilience.

Cost-effective for storing user-uploaded images that are only used for AI model training twice a year.

S3 Standard:

Ideal for frequently accessed data with high durability and availability.

Store premium user-generated AI images here to ensure they are readily available for download at any time.

S3 Standard-IA:

Cost-effective storage for data that is accessed less frequently but still requires rapid retrieval.

Store non-premium user-generated AI images here, as these images are only downloaded once every 6 hours, making it a good balance between cost and accessibility.

Cost-Effectiveness: This solution optimizes storage costs by categorizing data based on access patterns and durability requirements, ensuring that each type of data is stored in the most cost-effective manner.

The key requirement is to meet an RTO of less than 4 hours while using as few resources as possible during normal operations. A backup-and-restore style DR approach using AMIs in a secondary Region aligns with that goal, and AWS CloudFormation is the most operationally efficient way to automate rebuilding the environment. AWS disaster recovery guidance describes backup-and-restore as the lowest-cost pattern during steady state because compute resources are not running in the recovery Region until needed. CloudFormation is preferable to custom scripts because it gives repeatable infrastructure deployment with less custom operational code. Keeping instances active in another Region or AZ would consume more resources during normal operations than necessary.

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

AWS Lambda supports functions up to 10 GB of memory and 15 minutes execution time. Each invocation here requires only 1 GB of memory and finishes in 30 seconds, making it an ideal fit for Lambda. Lambda is cost-effective for event-driven, short-duration workloads and requires no infrastructure management. AWS Glue and EMR are better suited for large-scale ETL or distributed processing, which is unnecessary and more costly for this workload.

AWS Documentation Extract:

“AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. You pay only for the compute time you consume. Lambda supports up to 10 GB memory and 15 minutes per invocation.”

(Source: AWS Lambda documentation)

B, D: AWS Glue is intended for ETL on larger datasets or batch jobs, usually with higher operational overhead and cost.

C: EMR is for large-scale distributed processing and is not cost-effective for single, fast, memory-bound jobs.

Amazon DynamoDB supports both TTL (Time to Live) for automatic deletion and Point-in-Time Recovery (PITR) for backup and restore of table data. It ' s ideal for frequently updated data with short retention requirements and minimal operational overhead.

TTL attribute ensures expired items are automatically removed.

PITR enables recovery from accidental deletes or application errors.

AWS Global Accelerator: This service provides a global fixed entry point to your applications and optimizes the path to your application through the AWS global network, reducing latency and improving performance.

Accelerated TCP Connections:

Global Accelerator uses the AWS global network to route traffic to the nearest edge location, improving the performance and reliability of your live streams.

It provides static IP addresses that act as a fixed entry point to your application, simplifying DNS management.

High-Quality Streams:

By leveraging Global Accelerator, reporters can send live streams with the highest quality and low latency.

This service automatically reroutes traffic to the nearest available AWS Region, ensuring consistent performance even during traffic spikes or failures.

Operational Efficiency: Using Global Accelerator simplifies the network setup and provides an optimized path for live streams without the need for complex configurations, making it an efficient solution for real-time streaming applications.

Amazon RDS does not support enabling encryption at rest on an existing unencrypted DB instance. To encrypt an existing RDS instance’s data at rest, the recommended method is to:

Take a snapshot of the unencrypted DB instance.

Create an encrypted copy of the snapshot using AWS KMS. This encrypted snapshot contains the existing data encrypted at rest.

Restore a new DB instance from the encrypted snapshot. This new instance will have encryption at rest enabled.

Additionally, to manage encryption keys securely, companies can use customer managed keys (CMKs) in AWS Key Management Service (KMS). CMKs provide greater control over key management policies, rotation, and usage permissions compared to default AWS managed keys. Using a CMK allows customization of access control and auditability.

Option A is incorrect because you cannot enable encryption directly on a snapshot; you must create an encrypted copy. Option C is invalid because encryption cannot be enabled by modifying an existing instance’s configuration. Option D refers to the default AWS managed key, which is less flexible than customer managed keys.

CloudFront Signed URLs: These URLs allow you to provide limited access to content that is being served through an Amazon CloudFront distribution. Signed URLs can be generated to grant time-limited access to premium customers.

Content Restriction:

By using CloudFront signed URLs, you can control access to your media streams and file content stored in S3.

These URLs can be customized with an expiration time, ensuring that access is only available for a specific period, which is useful for scenarios like movie rentals or music downloads.

Security and Flexibility:

Signed URLs ensure that only authenticated users (premium customers) can access the restricted content.

This approach integrates seamlessly with CloudFront and S3, providing an efficient way to manage access controls without additional overhead.

Operational Efficiency: Using CloudFront signed URLs leverages AWS managed services to handle the complexity of access control, reducing the need for custom implementation and maintenance.

This solution addresses the scalability needs of the workload while preventing failed processing attempts due to resource constraints.

Amazon S3 event notificationscan be used to trigger a message to an SQS queue whenever a new video is uploaded.

The existing Auto Scaling group of EC2 instances can poll the SQS queue, ensuring that the EC2 instances only process videos when there is a job in the queue.

SQS decouplesthe video upload and processing steps, allowing the system to handle sudden spikes in video uploads without overloading EC2 instances.

The use ofAuto Scalingensures that the EC2 instances can scale in or out based on the demand, maintaining cost efficiency while avoiding processing failures due to insufficient resources.

AWS References:

S3 Event Notificationsdetails how to configure notifications for S3 events.

Amazon SQSis a fully managed message queuing service that decouples components of the system.

Auto Scaling EC2explains how to manage automatic scaling of EC2 instances based on demand.

Why the other options are incorrect:

A. AWS Lambda functions: While Lambda can handle some workloads, video processing is often resource-intensive and long-running, making EC2 a more suitable solution.

B. Using SNS with Lambda: Similar to A, Lambda is not ideal for large-scale video processing due to its time and memory limitations.

D. AWS Step Functions: While a valid orchestration solution, this introduces more complexity and overhead compared to the simpler SQS-based solution.

Amazon EFS requires a mount target in each Availability Zone where EC2 instances access the file system. This is because each mount target provides an elastic network interface in the subnet and AZ, reducing network latency by allowing EC2 instances to communicate locally with the EFS mount target. Creating a mount target in each AZ optimizes file system access performance and availability. Instances mount the EFS file system via the mount target in their respective AZ, which provides the lowest possible latency and avoids cross-AZ traffic.

Option A, with only a single mount target in the VPC, will cause cross-AZ traffic for instances in other AZs, increasing latency and potentially incurring data transfer costs. Option B is incomplete and introduces complexity with sharing directories across instances. Option C is invalid because mount targets are per AZ and per subnet, not per instance.

This solution meets the company ' s requirements with minimal administrative overhead and ensures security and ease of management.

AWS AppConfig: AWS AppConfig is a service designed to manage application configuration in a secure and validated way. It allows you to deploy configurations safely and quickly without affecting the application ' s performance or availability.

AWS Secrets Manager: AWS Secrets Manager is specifically designed to manage, retrieve, and rotate credentials for databases and other services. It integrates seamlessly with AWS services like Amazon RDS, making it an ideal solution for securely storing and retrieving database credentials. Secrets Manager also provides automatic rotation of credentials, reducing the operational burden.

Why Not Other Options?:

Option B (AWS Lambda + Parameter Store): While AWS Lambda can be used for managing configurations and AWS Systems Manager Parameter Store can store credentials, this approach involves more manual setup and does not offer the same level of integrated management and security as AppConfig and Secrets Manager.

Option C (Encrypted S3 Configuration File): Storing configuration and credentials in S3 files involves more manual management and security considerations, increasing the administrative overhead.

Option D (AppConfig + RDS for credentials): RDS is not designed for storing application credentials; it ' s better suited for managing database instances and their configurations.

AWS References:

AWS AppConfig- Describes how to use AWS AppConfig for managing application configurations.

AWS Secrets Manager- Provides details on securely storing and retrieving credentials using AWS Secrets Manager.

The problem is scale-out latency: when traffic spikes, new instances take time to launch, initialize, and pass health checks. This can temporarily degrade user experience even if Auto Scaling eventually adds enough capacity. The goal is to improve responsiveness to sudden spikes cost-effectively.

A key Auto Scaling feature for this situation is an EC2 Auto Scaling warm pool. A warm pool maintains a set of pre-initialized instances (stopped or running, depending on configuration) that Auto Scaling can rapidly transition into service. This reduces the time needed for instance launch and initialization, enabling faster scale-out during unexpected surges.

Option B is best because it supports the application’s peak needs by ensuring Auto Scaling can scale up to the required maximum capacity and keeps warm capacity ready. While a warm pool has some cost (especially if instances are kept running), it is typically more cost-effective than permanently running peak capacity all the time. It improves user experience by minimizing cold start delays during spikes.

Option A is counterproductive: lowering minimum capacity increases the likelihood of scale-out delays. Option C is illogical as written (“increase maximum to meet normal demand”); maximum should reflect peak potential, and a warm pool without sufficient max headroom will not solve the spike problem. Option D uses scheduled scaling, but the spike is unexpected, and increasing instance sizes increases cost and does not address launch delay; it may also reduce horizontal scaling flexibility.

Therefore, B is the most cost-effective way to improve scale-out performance and protect user experience during unexpected bursts.

The correct answer isDbecause the company needsNFS supportfor its on-premises environment and wants to back up files intoAmazon S3in themost cost-effectiveway.AWS Storage Gateway File Gatewayis the AWS service designed to present a file interface usingNFS(and SMB) while storing the files as objects in Amazon S3. This allows the company to keep using NFS-based workflows without redesigning the backup process.

The company also wants toarchive the backup files after 5 daysand is willing to waita few daysto retrieve archived data for disaster recovery. That retrieval tolerance aligns well withAmazon S3 Glacier Deep Archive, which is the lowest-cost S3 archival storage class for long-term retention when fast retrieval is not required. By applying anS3 Lifecycle ruleto transition files to Glacier Deep Archive after 5 days, the company can minimize storage cost while still retaining the backups durably in S3.

Option A is incorrect becauseS3 Standard-IAis cheaper than Standard for infrequent access, but it is not archival storage and is more expensive than Glacier Deep Archive for long-term backup retention. Option B is incorrect becauseVolume Gatewayprovides block storage interfaces, not NFS file access. Option C is incorrect becauseTape Gatewayis intended for virtual tape backup workflows, not direct NFS file storage access.

AWS best practices recommendFile Gatewaywhen on-premises applications need file-based access to Amazon S3, andS3 Glacier Deep Archivewhen the lowest-cost archival tier is acceptable. Therefore,File Gateway with a lifecycle transition to S3 Glacier Deep Archiveis the best solution.

S3 Express One Zone is designed for latency-sensitive workloads that need high request rates and very fast access to objects within a single Availability Zone. It uses S3 directory buckets and maintains S3 API compatibility, which directly matches the requirement to improve performance without moving away from the S3 API model. The media objects are updated frequently and require consistent low latency, so S3 One Zone-IA is not appropriate because it is intended for infrequently accessed data. S3 Transfer Acceleration improves long-distance upload and download performance but does not provide single-AZ, low-latency object access for active editing. S3 table buckets are built for tabular analytics, not frequently updated media object workloads.

AWS Elastic Disaster Recovery (AWS DRS) enables fast, reliable, and cost-effective disaster recovery. It replicates on-premises machines to AWS using continuous block-level replication. It supports automated testing and failover, meeting aggressive RTO targets such as 15 minutes.

Amazon S3 Bucket Keys reduce the cost of AWS KMS API requests by generating a data key at the bucket level instead of individually calling KMS for every object read or written. This approach is particularly effective when workloads, such as ML pipelines, involve reading large numbers of encrypted objects. Switching to AWS managed keys (A) does not reduce the frequency of API calls. Removing encryption (B) would violate compliance/security requirements. Using CloudHSM (C) adds cost and operational burden. Therefore, the correct solution is D — enabling S3 Bucket Keys with SSE-KMS, which significantly reduces decryption costs while maintaining secure encryption.

The correct answer isAbecause the application processes videos for5–30 minutes, must runmultiple jobs in parallel, and should have theleast operational overhead.Amazon ECS with AWS Fargateis a managed container solution that removes the need to provision and manage EC2 instances while still supporting longer-running parallel jobs. UsingAmazon SQS standard queuesdecouples the upload event from processing and provides a scalable buffer for incoming work.

With this design, Amazon S3 sends object-created notifications to the SQS queue whenever users upload videos. ECS services or tasks on Fargate can then consume messages from the queue and process videos independently. Auto scaling based onSQS queue depthensures the system increases task count when more videos arrive and decreases capacity when demand drops. This provides elasticity and efficient parallel processing with minimal infrastructure management.

Option B is incorrect because EC2-based scaling introduces more operational overhead than Fargate. Option C is incorrect because AWS Lambda has a maximum execution duration and is not appropriate for jobs that can run up to 30 minutes. Option D is also incorrect for the same reason; Lambda is not the best fit for this processing duration, and SNS does not provide the same durable queued work pattern as SQS for controlled parallel processing.

AWS best practices recommend usingevent-driven queues with containerized workersfor medium-duration processing jobs that need concurrency and minimal management. Therefore,S3 + SQS + ECS on Fargate with queue-based scalingis the best solution.

AWS Transit Gateway is purpose-built for large-scale, hub-and-spoke network architectures. It simplifies connectivity between multiple VPCs and on-premises environments, which is ideal for managing hundreds of VPCs.

“AWS Transit Gateway enables you to connect your VPCs and on-premises networks through a central hub. This simplifies your network and puts an end to complex peering relationships.”

— Transit Gateway Documentation

Features:

Scales to thousands of VPCs.

Integrates with AWS Direct Connect via Direct Connect Gateway.

Centralized routing control.

Incorrect Options:

A: VPC endpoints are for private access to AWS services—not VPC-to-VPC connectivity.

C: Route 53 is DNS, not a network transport layer.

D: Secrets Manager is for secret storage, not networking.

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. By creating a Config rule, you can automatically check whether your Amazon EBS volumes are encrypted and flag those that are not, with minimal cost and configuration effort.

AWS Config Rule: AWS Config provides managed rules that you can use to automatically check the compliance of your resources against predefined or custom criteria. In this case, you wouldcreate a rule to evaluate EBS volumes and determine if they are encrypted. If a volume is not encrypted, the rule will flag it, allowing you to take corrective action.

Operational Overhead: This approach significantly reduces operational overhead because once the rule is in place, it continuously monitors your EBS volumes for compliance, and there’s no need for manual checks or custom scripting.

Why Not Other Options?:

Option A (Lambda with API calls and EventBridge): While this can work, it involves writing and maintaining custom code, which increases operational overhead compared to using a managed AWS Config rule.

Option B (API calls on Fargate): Running API calls on Fargate is more complex and costly compared to using AWS Config, which provides a simpler, managed solution.

Option C (IAM policy with Cost Explorer): This option does not directly enforce encryption compliance and involves manual intervention, making it less efficient and more prone to errors.

AWS References:

AWS Config Rules- Overview of AWS Config rules and how they can be used to evaluate resource configurations.

Amazon EBS Encryption- Information on how to manage and enforce encryption for EBS volumes.

To improve availability and fault tolerance of an Amazon RDS instance, the recommended approach is to configure a Multi-AZ deployment.

Multi-AZ deployments for RDS automatically replicate data to a standby instance in a different Availability Zone (AZ).

If a failure occurs in the primary AZ (due to hardware, network, or power), RDS will automatically failover to the standby instance with minimal downtime, without administrative intervention.

This is an AWS-managed feature and does not require application modification.

It does not provide scalability or load balancing; it ' s designed for high availability and resiliency.

Options A, B, and D are incorrect:

A refers to cross-Region, which is used for disaster recovery, not high availability.

B and D with SQS do not address high availability directly for the RDS instance; queues help decouple systems but do not make a database more resilient.

???? Reference:

Amazon RDS Multi-AZ Deployments

Amazon S3 is the most cost-effective option for archiving data. Using AWS DMS to migrate to S3 in Apache Parquet format provides an optimized columnar format for analytics. By storing in S3 Glacier Flexible Retrieval, costs are minimized while maintaining compliance with retention. When queries are required, Athena can run SQL queries directly on archived data in S3 without provisioning infrastructure. Options A and B rely on maintaining RDS or EC2 instances, which increases cost and operational overhead. Option C requires full restores to EC2 before running queries, which is slow and inefficient. Therefore, D provides the lowest operational overhead and direct query capability with Athena.

AWS Glue jobs are designed for extract, transform, and load (ETL) operations, which are perfect for transforming clinical trial data. AWS Glue integrates with AWS Key Management Service (KMS), allowing for customer-specific encryption keys, fulfilling the encryption requirement with minimal operational effort. Client-side encryption with AWS KMS ensures that the data is encrypted before it is sent to S3, aligning with the security needs specified in the scenario.

Key aspects:

AWS Glue: This managed ETL service simplifies data transformation, reduces operational overhead, and integrates seamlessly with KMS.

CSE-KMS: Client-side encryption with KMS ensures that the data is encrypted with customer-specific keys before it is processed or stored in S3, offering robust security​​.

Minimal Operational Overhead: Compared to managing an EMR cluster, AWS Glue automates much of the process, making it a lower-effort solution.

AWS Documentation: According to the AWS Well-Architected Framework, encryption with AWS KMS offers strong security controls that meet the needs of industries requiring high levels of confidentiality​​.

Key Requirements:

Host the frontend on AWS as a static website.

Protect the application from common web vulnerabilities.

Minimal operational overhead.

Analysis of Options:

Option A:

Hosting the frontend on EC2 with an ALB introduces unnecessary complexity for serving static content.

AWS WAF rules can protect the ALB, but managing EC2 instances adds operational overhead.

Incorrect Approach:High operational complexity for a simple static website.

Option B:

Amazon CloudFront:Acts as a global CDN, reducing latency and protecting against DDoS attacks.

Multiple Origins:Allows static content to be served from S3 while routing API traffic to the on-premises backend.

AWS WAF:Integrates with CloudFront to provide web application protection.

Correct Approach:Offers low operational overhead with optimal security and performance.

Option C:

Using NLB and Network Firewall is unnecessary for a static website. This approach increases cost and complexity without addressing the frontend requirements effectively.

Incorrect Approach:Over-engineered solution.

Option D:

Hosting the frontend on S3 and using API Gateway is a viable option, but managing AWS WAF rules separately for both the S3 bucket and the REST API increases complexity.

Incorrect Approach:Less efficient than using CloudFront with multiple origins.

AWS Solution Architect References:

Amazon CloudFront Overview

AWS WAF with CloudFront

Incremental Exports: Exporting DynamoDB data directly to Amazon S3 provides an automated, serverless way to make data available for analytics without operational overhead.

Analytics-Friendly Storage: Amazon S3 supports long-term analytics workloads and can integrate with tools like Athena or QuickSight.

DynamoDB Export to S3 Documentation

Amazon Macieis purpose-built for detecting PII in S3.

Option Auses EventBridge to filter SensitiveData findings and notify via SNS, meeting the requirements.

Options B and Dinvolve GuardDuty, which is not designed for PII detection.

Option Cuses SQS, which is less suitable for immediate notifications.

Option Ais the simplest solution, using DynamoDB Streams and Lambda for real-time ingestion into S3.

Options B, C, and Dadd unnecessary complexity with Data Firehose or Kinesis.

This is a classic fanout pattern. AWS documentation states that Amazon SNS can fan out messages to multiple subscribers, including Amazon SQS queues. AWS also notes that using SQS with SNS gives each subscriber its own durable queue, which buffers events independently and allows consumers to process at their own pace. That directly satisfies the need for every consumer to receive each order event, to absorb bursts, and to let new consumers be added without changing the producer. A single SQS queue would distribute messages across consumers instead of delivering every event to every consumer. Direct EventBridge targets do not provide the same durable per-consumer buffering described in the question. SNS plus one SQS queue per consumer is the most flexible and resilient design.

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

Among the listed choices, option B is the best overall fit because it avoids long-term access keys by using an IAM role on the EC2 instances and uses CloudTrail data events to audit object-level S3 access. CloudTrail data events are the AWS-native way to log object-level activity such as GetObject and PutObject. Option D improves network restriction by using an S3 gateway endpoint, but VPC Flow Logs do not provide object-level S3 audit logs, so it does not fully satisfy the auditing requirement. Options A and C both rely on long-term access keys, which violates the security requirement. Therefore, B is the strongest answer from the choices provided because it meets the no-long-term-keys requirement and the object-access audit requirement.

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

Option Ais the best solution as it leveragesAWS Lambdafor serverless, scalable, and highly available processing and enrichment of clickstream data. Lambda can process the data in real-time, join it with the Aurora database data, and write the enriched results to Amazon S3. FromS3,Amazon Redshift Spectrumcan directly query the enriched data without needing to load the data into Redshift, enabling cost efficiency and high availability.

Why Other Options Are Incorrect:

Option B:EC2 Spot Instances are not guaranteed to be highly available, as Spot Instances can be interrupted at any time. This does not align with the requirement for high availability.

Option C:While ECS with AWS Fargate provides scalability, using EC2 for the COPY command introduces operational overhead and compromises high availability.

Option D:Kinesis Data Firehose and Athena are suitable for querying raw data, but they do not directly support enriching the data by joining with Aurora. This solution fails to meet the requirement for data enrichment.

Key AWS Features Used:

AWS Lambda:Real-time serverless processing with integration capabilities for Aurora and S3.

Amazon S3:Cost-effective storage for enriched data.

Amazon Redshift Spectrum:Direct querying of data stored in S3 without loading it into Redshift.

AWS Documentation References:

AWS Lambda Function Overview

Amazon Redshift Spectrum

Processing Streaming Data with Kinesis Data Streams

Using an Application Load Balancer (ALB) allows for integration with AWS WAF to inspect all incoming traffic. Running the application on Amazon ECS provides a scalable and managed container orchestration service. Utilizing Amazon Aurora Serverless for the PostgreSQL database offers automatic scaling based on application demand, which is cost-effective for workloads with variable traffic patterns, such as higher traffic on weekdays and lower traffic on weekends.

AWS Secrets Manager is the best fit because it is built specifically to store, manage, and rotate secrets such as database credentials. AWS documentation states that Secrets Manager supports automatic rotation for supported secret types and reduces the need for custom credential-rotation code. KMS encrypts keys and data but is not itself a secret-rotation store. Parameter Store can hold secure strings, but Secrets Manager is the AWS service purpose-built for secret lifecycle management and scheduled rotation. Because the question asks for the least development effort, using Secrets Manager with automatic rotation is the most direct and operationally efficient solution.

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

For encryption in transit, AWS Certificate Manager ACM is the correct service because it provisions and manages TLS certificates for HTTPS connections. For encryption at rest, AWS KMS is the right service because it manages encryption keys used by services such as Amazon EBS. AWS documentation and whitepapers consistently position ACM for certificate-based transport encryption and KMS for at-rest encryption key management across AWS services. GuardDuty and Shield are security detection and DDoS protection services, not encryption services. Secrets Manager stores and rotates secrets, but it is not the service used to encrypt all application data at rest or TLS sessions in transit.

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

Dead-letter queues (DLQs) with Amazon SQS allow Lambda functions to offload failed events for later inspection or retry. Using retry logic with exponential backoff ensures resilience and compliance with best practices for fault-tolerant serverless architectures. This guarantees no data is lost due to transient errors.

The correct answer isCbecause the existing application usesNFS storagefor an image cache that isa few terabytes in size, and the company wants themost cost-effective cloud alternative.Amazon EFS One Zoneis a managed file storage service that supports theNFS protocol, which allows the application to continue using a familiar file-based interface with minimal architectural change. Because this is acache, not primary durable data, storing it in aOne Zonefile system is a cost-optimized choice compared with a Regional EFS deployment.

Amazon EFS is designed for shared file storage and can scale to multiple terabytes automatically. It avoids the operational overhead of managing EC2 instances and local disks for cache storage. It is also better aligned than object storage for workloads that already expect direct NFS semantics. The application can mount the EFS file system and use it as the cache backend without redesigning around object APIs or in-memory caching models.

Option A is incorrect becauseElastiCache Memcachedis an in-memory cache and is typically much more expensive for multi-terabyte cache data than file storage. Option B is incorrect because using EC2 instance store volumes creates significant management overhead and the cache would be lost whenever instances are terminated or replaced. Option D is incorrect becauseAmazon S3 Express One Zoneis object storage, not NFS storage, and would require application redesign and additional metadata management in DynamoDB.

AWS storage guidance recommends matching file-based workloads to managed file services. For a largeNFS-based cache,Amazon EFS One Zoneis the most cost-effective and operationally simple solution.

Comprehensive and Detailed Step-by-Step Explanation:

The requirement is toprevent data deletion by any user, including administrators, for 7 years while allowing automatic deletion afterward.

S3 Object Lock in Compliance Mode (Correct Choice - C)

Compliance mode ensures that even the root user cannot delete or modify the objects during the retention period.

After 7 years, the S3 Lifecycle policy automatically deletes the objects.

This meets bothimmutability and automatic deletionrequirements.

Governance Mode (Option B - Incorrect)

Governance mode prevents deletion,but administrators can override it.

The requirement explicitly states thateven administrators must not be able to delete the data.

S3 Bucket Policy (Option A - Incorrect)

An S3 bucket policy candeny deletes, but policies can be modified at any time by administrators.

It does not enforce strict retention like Object Lock.

S3 Batch Operations Job (Option D - Incorrect)

A legal hold does not have an automatic expiration.

Legal holds must be manually removed, which is not efficient.

Why Option C is Correct:

S3 Object Lock in Compliance Mode prevents deletion by all users, including administrators.

The S3 Lifecycle policy deletes the data automatically after 7 years, reducing operational overhead.

Provisioned Concurrency:

AWS Lambda’s provisioned concurrency ensures that a predefined number of execution environments are pre-warmed and ready to handle requests, reducing latency during traffic spikes.

This solution optimizes costs during low-traffic periods when combined with AWS Application Auto Scaling to dynamically adjust the provisioned concurrency based ondemand.

Incorrect Options Analysis:

Option B: Switching to EC2 would increase complexity and cost for a serverless application.

Option C: A fixed concurrency level may result in over-provisioning during low-traffic periods, leading to higher costs.

Option D: Periodically warming functions does not effectively handle sudden spikes in traffic.

Aurora Global Database is designed for low-latency cross-Region reads and disaster recovery for relational data.

Amazon S3 Cross-Region Replication (CRR) automatically replicates unstructured data to another Region, ensuring high availability and resilience.

“Aurora Global Database replicates your data with typical latency of less than 1 second to secondary AWS Regions.”

“Amazon S3 Cross-Region Replication automatically replicates every object uploaded to your bucket to a destination bucket in another AWS Region.”

— Aurora Global Database

— S3 Cross-Region Replication

This combination meets the multi-Region, high availability, fault-tolerant requirement for both relational and unstructured data.

Option A:The ALB must accept HTTPS traffic from the public internet. Allowing inbound traffic on port 443 from 0.0.0.0/0 enables this functionality.

Option C:The ALB must forward HTTPS traffic to the web application servers on port 443. Outbound traffic for port 443 must be allowed for this communication.

Option E:The ALB must perform health checks on the web application servers over HTTPS on port 8443. Outbound traffic for port 8443 must be allowed for this purpose.

Option B:Allowing all outbound traffic is overly permissive and does not align with the specific requirements.

Option D and F:Inbound traffic to the ALB from the web application instances is unnecessary because the flow of traffic is from the ALB to the web application instances, not vice versa.

AWS Documentation References:

Application Load Balancer Security Groups

Health Checks for ALBs

Amazon Neptune is a fully managed graph database service optimized for storing and navigating complex many-to-many relationships like social graphs or network topologies.

It supports Gremlin and openCypher queries that allow efficient traversal of connections even multiple levels deep. SQL JOINs (Athena or RDS) are inefficient for deep relationship queries due to exponential complexity.

QuickSight is used for data visualization, not graph traversal.

AWS documents that Lambda@Edge can customize CloudFront behavior at the edge and that CloudFront can change the origin domain name based on the viewer-country header. AWS also documents that CloudFront can route to origins based on request headers and other request characteristics. That makes CloudFront with Lambda@Edge the best fit for selecting the Region-specific S3 origin closest to users in Asia and Europe. ALB is not the right service for S3-origin geolocation routing, and plain CloudFront cache behaviors alone do not perform this origin selection logic by viewer location without the edge customization. Therefore, Lambda@Edge plus CloudFront multi-origin selection is the correct design.

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

AWS Lambda is not suitable for long-running jobs that can take up to 20 minutes, as Lambda has a maximum execution duration of 15 minutes.

Amazon ECS with AWS Fargate allows you to run containers without managing EC2 instances, providing a scalable and highly available environment. You can scale Fargate tasks to handle large and parallel video processing jobs. Amazon Aurora is a highly available, managed relational database. S3 Intelligent-Tiering is cost-effective for storing large video files with variable access patterns.

AWS Documentation Extract:

" AWS Fargate lets you run containers without managing servers or clusters, providing a highly available and scalable compute environment. Fargate is suitable for running data processing workloads that require long-running compute tasks. "

(Source: AWS Fargate documentation, Use Cases)

A: Lambda is not suitable for long-running (over 15 min) or heavy compute jobs.

C: Amazon EMR is optimized for big data analytics, not specific video processing. FSx for Lustre and Kinesis are not best fit for this use case.

D: EKS with EC2 adds operational overhead and RDS in a single AZ is not highly available; Glacier Deep Archive is not suitable for frequently accessed video files.

The requirement is for astructured relational databasewith backups and scalable managed operations. Amazon RDS is the natural fit because it provides a managed relational database platform, and AWS documents that General Purpose SSD is recommended for new storage needs. AWS also documents that automated backups are enabled through the backup retention period parameter. Compared with self-managed EC2 databases, RDS reduces operational burden significantly. Aurora Serverless can be attractive, but for a general-purpose new application, standard RDS with GP SSD and automated backups is the more straightforward cost-conscious choice among the listed answers. Therefore, RDS with GP SSD storage and automated backups is the best match.

When using an SQS queue as an event source for AWS Lambda, the visibility timeout of the SQS queue plays a critical role in preventing duplicate message processing.

" If your Lambda function doesn ' t process the message and delete it from the queue within the visibility timeout period, the message becomes visible again and can be processed again by the same or another function instance. "

— AWS Lambda with SQS

In this scenario, the third-party API may take up to 60 seconds to respond. Since the Lambda function is configured with a 65-second timeout, the visibility timeout of the queue must be greater than or equal to the maximum function execution time to avoid the same message being reprocessed.

Incorrect Options:

A: Memory allocation doesn’t impact duplicate message handling.

B: Timeout is already sufficient; increasing it further does not solve the core issue.

C: Delivery delay controls initial delivery delay, not reprocessing logic.

Aurora blue/green deployments are specifically designed for:

Safely testing schema changes and database upgrades in an isolated environment (green) without impacting production (blue).

Performing a fast, low-downtime switchover once testing is complete and validated.

In this pattern:

The blue environment is the current production database.

The green environment is a synchronized copy used for testing changes.

You apply schema changes to the green environment, run tests, and when ready, perform a managed switchover that minimizes downtime and risk.

Why others are not ideal:

A: A separate staging cluster allows testing but does not provide automated, low-downtime synchronization and switchover.

B: Aurora read replicas are for read scaling; schema changes on replicas are not supported in the way described, and promotion alone doesn’t solve controlled testing and replication of changes.

D: Moving to DynamoDB changes database engines and data models entirely, and does not match the requirement to keep using Aurora MySQL.

TheGateway Load Balancer (GWLB)is specifically designed to route traffic through a security appliance in a hub-and-spoke model, making it the ideal solution for inspecting traffic between multiple AWS accounts. GWLB enables you to simplify, scale, and deploy third-party virtual appliances transparently, and it can work across multiple VPCs or accounts using interface endpoints (Gateway Load Balancer Endpoints).

Key AWS features:

Traffic Inspection: The GWLB allows the centralized security appliance to inspect traffic between different VPCs, making it suitable for inspecting inter-account interactions.

Interface VPC Endpoints: By using interface endpoints in the application accounts, traffic can securely and efficiently be routed to the security appliance in the networking account.

AWS Documentation: The use of GWLB aligns with AWS’s best practices for centralized network security, simplifying architecture and reducing operational complexity​.

This workload is a strong candidate forAWS Batch with EC2 Spot Instancesbecause the jobs can tolerate interruptions and resume after restart. AWS documents that Spot Instances are a cost-saving option for interruption-tolerant workloads, and AWS Batch is built to manage batch jobs efficiently across EC2 capacity. AWS Batch guidance also notes that Spot is well suited when jobs can be retried or resumed, which matches the scenario. On-Demand Capacity Reservations do not optimize cost, and Savings Plans still cost more than Spot for an interruption-tolerant batch pattern. Therefore, AWS Batch with Spot gives the best balance of automation and lower compute cost.

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

AWS WAF allows web applications to protect themselves from common web exploits and vulnerabilities. Using AWS managed rule groups ensures protection against known attack patterns, such as SQL injection and cross-site scripting. Associating AWS WAF with the ALB provides application-layer security and real-time threat mitigation.

Given the large size (180 TB) of the database and the time constraint,AWS Snowball Edge Storage Optimizedis the best solution. Snowball Edge allows for the physical transfer of large datasets to AWS efficiently without relying on slow internet connections.AWS DMSandSCTcan be used to perform ongoing replication of any changes made during the migration, ensuring minimal downtime.

Option B (VPN): Using a 100 Mbps internet connection would take far too long to transfer 180 TB.

Option C (Direct Connect): Establishing a 10 Gbps Direct Connect link might not be feasible within the 2-week timeframe.

Option D (DataSync over internet): With the existing internet connection, DataSync would also take too long.

AWS References:

AWS Snowball Edge

AWS DMS

The most resilient and scalable architecture for handling millions of high-resolution images with frequent updates is to store the binary images in Amazon S3 and store their metadata or reference (geographic code and S3 URL) in Amazon DynamoDB.

From AWS Documentation:

“Store large objects like images in Amazon S3 and use Amazon DynamoDB to store metadata and references. This design pattern is scalable, highly available, and cost-effective.”

(Source: AWS Architecture Blog – Best Practices for Handling Large Objects)

Why B is correct:

Amazon S3 is designed for storing large volumes of binary data (images).

DynamoDB provides low-latency reads/writes using the geographic code as the partition key.

Highly available, serverless, and auto-scaling, suitable for disaster scenarios with bursts of activity.

Reduces pressure on the database layer by separating metadata from image storage.

Why the others are incorrect:

Option A and D: Storing images directly in RDS is expensive, unscalable, and not optimal for binary storage.

Option C: DynamoDB is suitable, but storing actual binary image data in DynamoDB is not best practice due to item size limits (400 KB) and performance concerns.

The company needs a cloud-based storage solution for frequently accessed data with low latency, while retaining their current on-premises infrastructure for some data storage. AWS Storage Gateway ' sVolume Gateway with cached volumesis the most appropriate solution for this scenario.

AWS Storage Gateway - Volume Gateway (Cached Volumes):

Volume Gateway with cached volumesallows you to store frequently accessed data in the AWS Cloud while keeping the most recently accessed data cached locally on-premises. This ensures low-latency access to active data while providing scalability for the rest of the data in the cloud.

The cached volume option stores the primary data in Amazon S3 but caches frequently accessed data locally, ensuring fast access. This configuration is well-suited for applications that require fast access to frequently used data but can tolerate cloud-based storage for the rest.

Since the company is facing limited on-premises storage, cached volumes provide an ideal solution, as they reduce the need for additional on-premises storage infrastructure.

Why Not the Other Options?:

Option A (S3 File Gateway): S3 File Gateway provides a file-based interface (SMB/NFS) for storing data directly in S3. While it is great for file storage, the company’s need for block-level storage with iSCSI targets makes Volume Gateway a better fit.

Option C (Volume Gateway - Stored Volumes): Stored volumes keep all the data on-premises and asynchronously back up to AWS. This would not address the company ' s storage limitations since they would still need substantial on-premises storage.

Option D (Tape Gateway): Tape Gateway is designed for archiving and backup, not for frequently accessed low-latency data.

AWS References:

AWS Storage Gateway - Volume Gateway

Amazon DynamoDB is a serverless, NoSQL database that is fully managed, highly available, and scales automatically. It is ideal for data without a fixed schema and for use cases where fields can vary by user. DynamoDB Streams enables the capture of changes to table items in real time, which is ideal for triggering additional processing or workflows on data modifications.

Reference Extract from AWS Documentation / Study Guide:

" DynamoDB provides a scalable, highly available NoSQL database service for applications requiring flexible schema. DynamoDB Streams captures table activity for processing changes in real time. "

Source: AWS Certified Solutions Architect – Official Study Guide, DynamoDB and Serverless section.

To authenticate users using an on-premises Active Directory Federation Service (AD FS), AWS provides the AWS Directory Service AD Connector. AD Connector is a proxy that connects AWS applications to your on-premises Microsoft Active Directory without requiring complex directory synchronization or the need to set up a separate directory in the cloud.

By integrating AD Connector with the Application Load Balancer (ALB), you can authenticate and authorize users using your existing on-premises credentials. This setup allows the ALB to leverage the authentication capabilities of your on-premises AD FS, providing a seamless and secure user experience.

The requirements include:

Scalability: The solution must scale as video files are uploaded.

Long-running tasks: Processing tasks can take up to 30 minutes. AWS Lambda has a maximum execution time of 15 minutes, which rules out options that involve Lambda performing all the processing.

Serverless and event-driven architecture: Ensures cost-effectiveness and high availability.

Analysis of Options:

Option A:

AWS Lambda has a 15-minute timeout, which cannot support tasks that take up to 30 minutes.

EventBridge Scheduler is unnecessary for monitoring files when native event notifications are available.Not a valid choice.

Option B:

AWS Step Functions and AWS Fargate can handle long-running processes, but Amazon EFS is not the ideal storage for uploaded video files in a serverless architecture.

Processing tasks triggered by EFS events are not a common pattern and may introduce complexities.Not the best practice.

Option C:

Amazon S3 is used for storing uploaded files, which integrates natively with event-driven services like EventBridge and Step Functions.

Amazon S3 event notifications trigger a Step Functions workflow, which can orchestrate Fargate tasks to process large video files, meeting the scalability and execution time requirements.Correct choice.

Option D:

Similar to Option A, AWS Lambda cannot handle long-running processes due to its 15-minute timeout.

Invoking Lambda for processing directly is not feasible for tasks that take up to 30 minutes.Not a valid choice.

AWS References:

Amazon S3 Event Notifications:AWS Documentation - S3 Event Notifications

AWS Step Functions:AWS Documentation - Step Functions

AWS Fargate:AWS Documentation - Fargate

Comparison of Storage Services:AWS Storage Options

By leveragingAmazon S3,Step Functions, andFargate, this solution provides a scalable, efficient, and serverless approach to handling video processing tasks.

The medical reports needreal-time accesseven though they are read only about once a year, which matchesS3 Glacier Instant Retrieval. AWS documents that objects in Glacier Instant Retrieval are immediately available with GET, making it the right archival class when access is infrequent but still must be immediate. The medical images are rarely accessed and can tolerate slower retrieval, soS3 Glacier Deep Archiveis the lowest-cost long-term archival choice. AWS recommends Deep Archive for long-lived data that is accessed less than once a year and can wait hours to days for restore completion. That combination optimizes cost while still meeting the very different retrieval requirements for reports and images. (AWS Documentation)

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

Amazon Managed Streaming for Apache Kafka (Amazon MSK) is a fully managed service that makes it easy to build and run applications that use Apache Kafka to process streaming data. By using Amazon ECS with the AWS Fargate launch type, you can run containers without managing servers or clusters. This combination reduces operational overhead and provides scalability.

The requirement is to provide granular, scalable access to thousands of tables and columns in a data lake across many users and departments, with the least operational overhead.

AWS Lake Formation supports tag-based access control (TBAC) using LF-tags (Lake Formation tags), which allows you to assign tags to tables, columns, and databases. You can then define permissions on resources by specifying tags rather than managing permissions for individual resources. This approach is highly scalable and efficient when dealing with a growing number of tables and columns. By associating IAM roles to departments and granting access based on LF-tags, you dramatically reduce the operational burden as new tables or columns are added; you only need to assign the appropriate tags.

Amazon Athena can directly query data in S3 with Lake Formation providing fine-grained access control.

AWS Documentation Extract:

" With LF-tag-based access control, you can grant permissions to resources based on tags, making it easy to manage access at scale, especially in environments with large and dynamic numbers of resources. "

" LF-tags provide a scalable way to manage permissions for large numbers of resources without having to define permissions individually for each table or column. "

(Source: AWS Lake Formation documentation, Access Control, Tag-Based Access Control)

Other options:

A: Would require managing explicit permissions for each table and column as the environment grows, increasing operational overhead.

B & D: Involve significant duplication of resources (clusters) and do not scale as efficiently as a centralized data lake with tag-based access.

AWS RDS Proxy is a fully managed, highly available database proxy that allows applications to pool and share database connections efficiently.

In serverless architectures like Lambda, rapid invocations can open numerous concurrent connections to Aurora, potentially overwhelming the database and causing “too many connections” errors.

By using Amazon RDS Proxy, the solution:

Pools database connections.

Maintains warm connections that can be reused.

Supports IAM authentication and Secrets Manager integration.

Requires minimal application change and low operational effort.

This directly supports the Performance Efficiency pillar of the AWS Well-Architected Framework, ensuring the application scales without overloading the DB.

???? Reference:

Amazon RDS Proxy Documentation

Lambda + RDS Best Practices

Storage Gateway Volume Gateway (Cached Volumes): This configuration allows you to store your primary data in Amazon S3 while retaining frequently accessed data locally in a cache for low-latency access.

Low-Latency Access: Frequently accessed data is cached locally on-premises, providing low-latency access while the less frequently accessed data is stored cost-effectively in Amazon S3.

Implementation:

Deploy a Storage Gateway appliance on-premises or in a virtual environment.

Configure it as a volume gateway with cached volumes.

Create volumes and configure your applications to use these volumes.

Minimal Infrastructure Changes: This solution integrates seamlessly with existing on-premises infrastructure, requiring minimal changes and reducing dependency on on-premises storage servers.

AWS Fargate with Amazon ECS is a serverless, fully managed compute engine for containers. Fargate eliminates the need to provision or manage servers, and is ideal for periodic, long-running batch jobs. You only pay for the resources consumed during job execution, making it cost-effective for jobs that run infrequently. Lambda is not suitable because the maximum execution time is 15 minutes, but the job can take up to 2 hours.

AWS Documentation Extract:

“AWS Fargate lets you run containers without managing servers or clusters. Fargate is ideal for batch jobs, event-driven processing, and scheduled tasks that require hours of compute.”

(Source: AWS Fargate documentation)

A: Reserved Instances are cost-inefficient for infrequent workloads and require server management.

B: Lambda has a hard limit of 15 minutes per execution, insufficient for this job.

D: ECS on EC2 requires you to manage and provision EC2 instances, increasing cost and management overhead.

Using API Gateway with API keys provides secure access control. Amazon SQS allows asynchronous decoupling between frontend and backend, ensuring that backend processing can scale independently. AWS Lambda reading from SQS ensures scalable, event-driven processing with minimal operational management. This architecture is resilient and decoupled.

The key requirements are asynchronous processing, high availability, burst handling, and strict message ordering. Amazon SQS FIFO queues are specifically designed to guarantee exactly-once processing and ordered message delivery, making them ideal for transactional workflows like ecommerce order processing.

Option B meets all requirements. SQS FIFO preserves the order of messages within a message group and scales automatically to absorb traffic spikes. Integrating SQS FIFO with AWS Lambda enables serverless, event-driven processing with automatic scaling and no infrastructure management. Lambda processes messages as they arrive while maintaining order guarantees.

Option A (SNS) does not guarantee ordering and is designed for fan-out messaging. Option C (SQS standard) scales well but does not preserve order. Option D introduces unnecessary batch infrastructure and increased latency.

Therefore, B is the best solution because it combines ordered delivery, resilience, elasticity, and serverless compute, ensuring reliable and scalable order processing.

The correct answer isDbecause the workload isinterruptible, runs for onlyup to 48 hours each week, and the company wants themost cost-effectivesolution while alsominimizing interruptions. These requirements strongly align withAmazon EC2 Spot Instances. Spot Instances provide significant savings compared with On-Demand pricing and are ideal for batch processing, analytics, and other fault-tolerant workloads that can recover from interruptions.

To minimize the chance of interruption, the best allocation strategy iscapacity-optimized. This strategy places Spot requests into the most available Spot capacity pools, which reduces the likelihood that the running instances will be reclaimed. That is more aligned with the requirement than focusing primarily on the absolute lowest price. By usinginstance type overridesin the Auto Scaling group, the company can specify multiple acceptable instance types across generations and sizes. This improves access to capacity and helps the company adoptnewer generation instancesover time without locking into a single family or type.

Option A is incorrect becauseConvertible Reserved Instancesare not as cost-effective as Spot for an interruptible workload that runs only part of the week, and a 3-year term reduces flexibility. Option B is incorrect becauseStandard Reserved Instancesare better for steady-state workloads and do not support the requirement to move to the latest generation each year as flexibly. Option C is close, butprice-capacity-optimizedbalances cost and capacity; the question prioritizes minimizing interruptions, socapacity-optimizedis the better answer.

AWS cost optimization guidance recommendsSpot Instances with a capacity-focused strategyfor fault-tolerant workloads that need low cost and fewer interruptions.

When on-premises DNS servers need to resolve private DNS names in a VPC, the correct pattern is to create a Route 53 Resolver inbound endpoint. The inbound endpoint allows DNS queries to flow from the on-premises environment into the VPC, where Route 53 can resolve VPC-specific names (such as private hosted zones or private resource records). Outbound endpoints (C) are for sending VPC DNS queries to on-premises, not the reverse. Verified Access (A) is unrelated to DNS resolution. Direct Connect (B) provides network connectivity but does not provide DNS forwarding capabilities. Therefore, option D is the correct design.

Edge-optimized API Gateway endpoints utilize the Amazon CloudFront global network to decrease latency for clients globally. This setup ensures that the request is routed to the closest edge location, significantly reducing response time and improving performance for worldwide users.

Amazon S3 Storage Lens with advanced activity metrics is the most operationally efficient answer because AWS documentation explicitly says you can use S3 Storage Lens advanced metrics to identify “cold” buckets, meaning buckets whose objects are no longer accessed or are accessed only rarely. That is exactly the requirement in the question. This avoids building a custom analytics workflow on top of CloudTrail or CloudWatch metrics. The standard S3 console does not provide the same purpose-built fleet-level analysis for cold-bucket identification. Athena and CloudTrail can be used for access analysis, but they require more setup, data handling, and query maintenance. S3 Storage Lens is the native managed feature for this storage-optimization scenario. (AWS Documentation)

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

Amazon SQS with Amazon ECS on AWS Fargate is the best managed architecture for containerized, loosely coupled message processing. SQS is a fully managed message queue that decouples distributed application components and scales without the operational burden of managing broker infrastructure. SNS can fan out messages to the SQS queue when publish-subscribe behavior is needed. ECS on Fargate runs containers without requiring the company to manage EC2 instances, Kubernetes worker nodes, or server capacity. Amazon MQ is useful when applications need traditional broker compatibility, but it does not provide the same virtually unlimited scaling model as SQS standard queues. EC2 Reserved Instances also violate the goal of fully managed infrastructure.

The application requires independent scaling, ordered asynchronous processing, and relational data storage. Option A provides a microservices-oriented, decoupled architecture using managed services.

Amazon ECS with AWS Fargate enables containerized workloads without server management and allows each component to scale independently. Amazon RDS supports relational data storage for user profiles and content. Amazon SQS ensures reliable, ordered message processing and decouples long-running background tasks, allowing services to evolve independently.

Option B uses SNS, which does not guarantee message ordering. Option C uses DynamoDB, which does not meet the relational data requirement. Option D offers less granular scaling and higher coupling.

Therefore, A best meets scalability, resilience, and modularity requirements.

AWS Lambda SnapStart is designed to improve the cold start performance of Java Lambda functions by initializing the function, taking a snapshot of the execution environment, and then reusing that snapshot for subsequent invocations. However, some code (such as code that generates unique IDs or session-specific data) should run during each invocation, not during the snapshot process. By using a pre-snapshot hook and moving the unique ID generation into the handler, you ensure that non-deterministic or per-invocation code is executed correctly, while the rest of the initialization benefits from SnapStart. This delivers the lowest latency and cost, as you do not need to pay for provisioned concurrency.

AWS Documentation Extract:

" Lambda SnapStart is ideal for Java functions with long cold starts due to heavy initialization. Move non-deterministic code such as unique ID generation to the handler, and use pre-snapshot hooks to customize what gets snapshotted. SnapStart works only for published versions, not $LATEST. "

(Source: AWS Lambda documentation, Using SnapStart for Java Functions)

Other options:

A: SnapStart is not supported for the $LATEST version; must be a published version.

B & C: Provisioned concurrency removes cold starts but is more expensive than SnapStart for most workloads.

C: You must use SnapStart on published versions, but provisioned concurrency is not required for SnapStart and adds cost.

To optimize costs for both Amazon EC2 and AWS Fargate, the best option is a Compute Savings Plan because it offers flexibility across instance families, Regions, and compute options including EC2, AWS Fargate, and AWS Lambda.

Unlike EC2 Instance Savings Plans, which apply only to specific instance families, Compute Savings Plans apply across multiple services.

Since the company does not want to commit to multi-year contracts or large upfront payments, the 1-year No Upfront Compute Savings Plan provides the greatest flexibility with no upfront capital commitment, while still offering cost savings over On-Demand pricing.

This option also aligns with cost-optimization best practices by allowing for scalability and service mix flexibility.

???? Reference:

AWS Compute Savings Plans

AWS Pricing Models

Amazon Aurora Serverless is a fully managed, MySQL-compatible database that automatically scales based on demand and provides high availability. Combining this with EC2 Auto Scaling and an Application Load Balancer achieves both application and database high availability and scalability.

Reference Extract:

" Aurora Serverless automatically starts up, shuts down, and scales capacity based on your application ' s needs, providing a cost-effective, highly available database solution. "

Source: AWS Certified Solutions Architect – Official Study Guide, Aurora Serverless and Scaling section.

Amazon SQS supports Interface VPC endpoints (AWS PrivateLink), enabling private connectivity from your VPC to SQS without using public IPs, traversing the public Internet, or requiring NAT/IGW. You can restrict access by attaching a queue resource policy that allows only the specific VPC endpoint and denies all other principals/paths, enforcing that all traffic stays on the AWS network. SSE-SQS (B) encrypts data at rest but does not influence network pathing. STS temporary credentials (C) handle authentication/authorization, not routing. VPC Flow Logs (D) are monitoring/visibility and do not prevent public egress. Creating an SQS VPC endpoint and tightening the queue policy satisfies the requirement of no public IP usage while maintaining secure, private access from serverless components in VPC subnets.

Amazon EFS offers an Infrequent Access (IA) storage class, which can be managed via EFS lifecycle policies. Frequently accessed files remain in the Standard storage class, while infrequently accessed files are automatically moved to the IA class, significantly reducing storage costs with minimal effort and no application changes.

Reference Extract:

" EFS lifecycle management automatically transitions files that are not accessed for a set period to the EFS Infrequent Access (IA) storage class, reducing storage costs. "

Source: AWS Certified Solutions Architect – Official Study Guide, EFS and Lifecycle Management section.

AWS documentation states that Amazon Macie is the managed service designed to automatically identify and classify sensitive data stored in Amazon S3, including PII and healthcare-related identifiers.

Storing logs in Amazon S3 provides scalable, durable storage, and Amazon Athena can directly query JSON data stored in S3 using SQL.

Amazon Inspector (Option D) is for vulnerability scanning and does not identify sensitive data. DynamoDB with KMS (Option C) cannot detect sensitive information. EBS (Option B) requires custom tooling and does not support serverless SQL querying.

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

AWS Key Management Service (AWS KMS) supports multi-Region keys, which are managed customer master keys that can be replicated to multiple Regions and treated as a single logical key. This allows applications in different Regions to encrypt and decrypt data using equivalent keys while AWS handles key replication, durability, and availability.

KMS is a fully managed key service, so the company does not need to operate hardware or manage low-level key storage. Tags combined with attribute-based access control (ABAC) let you enforce fine-grained access to keys by using IAM policies and condition keys, giving centralized and flexible access control with low operational overhead.

CloudHSM (Options C and D) requires managing HSM clusters, scaling, backups, and manual key operations, which significantly increases operational burden. Importing key material in KMS (Option B) adds lifecycle complexity and is unnecessary when native multi-Region keys exist.

An Application Load Balancer supports path- and host-based routing, which makes it ideal for routing requests based on subdomains. EC2 Auto Scaling ensures that the number of instances adjusts dynamically based on traffic, which helps manage cost and performance during predictable peak hours.

For bursty and seasonal workloads, AWS recommends serverless architectures using Amazon API Gateway + AWS Lambda:

API Gateway exposes a fully managed, scalable API endpoint.

Lambda provides automatic scaling based on request volume, with no need to provision or manage servers.

This is ideal for workloads with variable or seasonal demand, such as end-of-year tax computation bursts.

This combination minimizes operational overhead (no OS patching, no capacity planning) while scaling seamlessly to meet peak demand.

Options A, C, and D rely on EC2 instances. They require capacity planning, scaling configuration, and ongoing management. They do not scale as effortlessly as Lambda for unpredictable or highly seasonal workloads.

Enabling Multi-AZ deployment for an Amazon RDS DB instance is the simplest and most effective way to improve database availability and eliminate a single point of failure. Multi-AZ deployments provide automatic failover to a standby instance in case of a failure of the primary instance. This approach is managed by AWS and only requires a modification to the existing instance, with minimal manual intervention or downtime, thus providing the least implementation effort.

Reference Extract from AWS Documentation / Study Guide:

" With Multi-AZ deployments, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). In case of a failure of the primary DB Instance, Amazon RDS automatically fails over to the standby so that database operations can resume quickly. "

Source: AWS Certified Solutions Architect – Official Study Guide, RDS High Availability section.

To meet the requirements for tagging and preventing instance creation or deletion without proper tags, the company can use a combination of AWS Organizations tag policies and service control policies (SCPs).

Tag Policies: These enforce specific tag values across resources. Creating a tag policy with required values (e.g., sensitive, non-sensitive) and attaching it to the appropriate organizational unit (OU) ensures consistency in tagging.

SCPs: SCPs can be used to enforce compliance by preventing instance creation without a tag and preventing tag deletion. These policies control actions at the account level across the organization.

Key AWS features:

Tag Policieshelp standardize tags across accounts, andSCPsenforce governance by restricting actions that violate the policies.

AWS Documentation: AWS best practices recommend using tag policies and SCPs to enforce compliance across multiple accounts within AWS Organizations​.

To achieve a 60-second RTO, pre-warming the DR environment (including running EC2 instances and Route 53 health checks) is essential. Active/passive failover using Route 53 with health checks ensures fast redirection when the primary Region becomes unavailable. S3 cross-region replication ensures document availability.

Option Ais the most automated and cost-efficient solution for exporting data to S3 for analytics.

Option Binvolves manual setup of Streams to S3.

Options C and Dintroduce complexity with EMR.

A Stored Volume Gateway stores the entire dataset locally on-premises while asynchronously and securely backing up the data to AWS. This meets the requirement for full local access and automatic transfer to AWS.

Cached Volume Gateway (Option C) keeps only frequently accessed data locally; the full dataset is stored in AWS, not on-premises.

Snowball and Snowball Edge (Options A and B) are migration tools, not ongoing backup solutions.

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

EBS Encryption:

Default EBS Encryption: Can be enabled for new EBS volumes.

Use of AWS KMS: Specify AWS KMS keys to handle encryption and decryption of data transparently.

Amazon RDS Encryption:

RDS Encryption: Encrypts the underlying storage for RDS instances using AWS KMS.

Configuration: Enable encryption when creating the RDS instance or modify an existing instance to enable encryption.

Least Amount of Changes:

Both EBS and RDS support seamless encryption with AWS KMS, requiring minimal changes to the existing infrastructure.

Enables compliance with regulatory requirements without modifying the application.

Operational Efficiency: Using AWS KMS for both EBS and RDS ensures a consistent, managed approach to encryption, simplifying key management and enhancing security.

Using S3 event notifications to trigger AWS Lambda for file processing is a cost-effective and serverless solution. Lambda scales automatically with upload volume, and processing each file takes less than 5 seconds, fitting within Lambda ' s execution time.

Option A:AWS AppSync is designed for GraphQL APIs and is not suitable for file processing.

Option C:Kinesis is overkill and more expensive for this use case.

Option D:Running an EC2 instance incurs ongoing costs and is less flexible compared to Lambda.

AWS Documentation References:

Amazon S3 Event Notifications

AWS Lambda Overview

A Network Load Balancer (NLB) supports IP address-based targets, which allows the use of both EC2 and on-premises endpoints. It also supports a static IP address or Elastic IP, which meets the requirement for a fixed IP address needed by some users.

NLB offers high performance, low latency, and minimal operational overhead. Application Load Balancer only supports instance or Lambda targets, not IP addresses outside the VPC. Route 53 Resolver is for DNS, and API Gateway is for HTTP-based APIs, not web applications.

Amazon S3 uses gateway VPC endpoints, which enable private, secure access to S3 without traversing the internet, compatible with IPv6.

Amazon DynamoDB uses interface VPC endpoints (powered by AWS PrivateLink) for private connectivity within the VPC.

Therefore, for secure private communication without public internet, the correct solution is to implement a gateway VPC endpoint for S3 and an interface VPC endpoint for DynamoDB.

Option B is incorrect because S3 does not support interface endpoints; Option C is incorrect because DynamoDB does not support gateway endpoints. Option D reverses the correct endpoint types.

To grant cross-account access to an Amazon S3 bucket, you can use a bucket policy that specifies the AWS account ID of the account you want to grant access to. This method allows Account B to access the S3 bucket in Account A without the need for additional services or configurations.

Amazon GuardDuty includes RDS Protection that “monitors and profiles access to your Amazon Aurora and Amazon RDS databases” to detect threats such as suspicious login attempts, brute-force activity, and anomalous authentication patterns. GuardDuty can be enabled organization-wide in AWS Organizations with a delegated administrator to centralize findings for all member accounts, minimizing operational overhead. Findings include context like source IP, user, and DB instance, and integrate with Amazon EventBridge for alerting and automated response. SCPs (A) enforce or deny API permissions but do not provide detection/analytics. Exporting general logs (C) requires building and maintaining custom parsing/analytics pipelines. CloudTrail (D) records AWS control-plane API calls and does not log database-level login attempts. Therefore, enabling GuardDuty RDS Protection across the org provides the most operationally efficient, managed detection of abnormal failed and incomplete login attempts.

AmazonSES (Simple Email Service)allows for the automatic ingestion of incoming emails. By setting up email receiving in SES and creating a rule set with a receipt rule, you can configure SES to invoke anAWS Lambda functionwhenever an email is received. The Lambda function can then process the email body and attachments, saving any attachments to an Amazon S3 bucket. This solution is highly scalable, cost-effective, and provides near real-time processing of emails with minimal operational overhead.

Option B (Content filtering): This only filters emails based on content and does not provide the functionality to save attachments to S3.

Option C (S3 Event Notifications): While SES can store emails in S3, SES with Lambda offers more flexibility for processing attachments in real-time.

Option D (EventBridge rule): EventBridge cannot directly listen for incoming emails, making this solution incorrect.

AWS References:

Receiving Email with Amazon SES

Invoking Lambda from SES

AWS Backup offers centralized management, scheduling, and retention of backups for supported AWS services including Amazon DynamoDB. It enables compliance retention with minimal management.

From AWS Documentation:

“AWS Backup provides centralized backup management across AWS services, including DynamoDB. You can define backup plans, schedules, and retention policies to meet business or regulatory requirements.”

(Source: AWS Backup Developer Guide – Backing up DynamoDB Tables)

Why B is correct:

Automatically manages backup scheduling and retention (7 years).

Centralized compliance monitoring via AWS Backup Audit Manager.

Fully managed and requires no custom automation.

Why others are incorrect:

A: PITR is for continuous restore within 35 days, not long-term compliance retention.

C & D: Manual or Lambda-based backups require custom management and increase operational complexity.

This solution is the most scalable and efficient way to handle large volumes of survey data while automating sentiment analysis:

API Gateway and SQS: The survey results are sent to API Gateway, which forwards the data to an SQS queue. SQS can handle large volumes of messages and ensures that messages are not lost.

AWS Lambda: Lambda is triggered by polling the SQS queue, where it processes the survey data.

Amazon Comprehend: Comprehend is used for sentiment analysis, providing insights into customer satisfaction.

DynamoDB with TTL: Results are stored in DynamoDB with aTime to Live (TTL)attribute set to expire after 365 days, automatically removing old data and reducing storage costs.

Option B (EC2 API): Running an API on EC2 requires more maintenance and scalability management compared to API Gateway.

Option C (S3 and Rekognition): Amazon Rekognition is for image and video analysis, not sentiment analysis.

Option D (Amazon Lex): Amazon Lex is used for building conversational interfaces, not sentiment analysis.

AWS References:

Amazon Comprehend for Sentiment Analysis

Amazon SQS

DynamoDB TTL

For the migration of data from an on-premises Oracle database to Amazon Aurora PostgreSQL, this solution effectively handles schema conversion, data migration, and ongoing data replication.

AWS Schema Conversion Tool (SCT): SCT is used to convert the Oracle database schema to a format compatible with Aurora PostgreSQL. This tool automatically converts the database schema and code objects, like stored procedures, to the target database engine.

AWS Database Migration Service (DMS): DMS is employed to perform the data migration. It supports both full-load migrations (for initial data transfer) and continuous replication of ongoing changes (Change Data Capture, or CDC). This ensures that any updates to the Oracle database during the migration are captured and applied to the Aurora PostgreSQL database, minimizing downtime.

Why Not Other Options?:

Option A (SCT + DMS full-load only): This option does not capture ongoing changes, which is crucial for a live database migration to ensure data consistency.

Option B (DataSync + S3): AWS DataSync is more suited for file transfers rather than database migrations, and it doesn’t support ongoing change replication.

Option D (Snowball + S3): Snowball is typically used for large-scale data transfers that don’t require continuous synchronization, making it less suitable for this scenario where ongoing changes must be captured.

AWS References:

AWS Schema Conversion Tool- Guidance on using SCT for database schema conversions.

AWS Database Migration Service- Detailed documentation on using DMS for data migrations and ongoing replication.

Amazon RDS Proxy helps manage thousands of concurrent database connections by pooling and reusing them efficiently. It is especially useful for serverless applications like AWS Lambda that can open numerous connections quickly, potentially overwhelming the database. Using RDS Proxy reduces connection management overhead and improves fault tolerance.

The requirement has three key elements: high availability with automatic recovery, separation of transactional and analytical workloads, and acceptable reporting lag up to 4 hours. The clean AWS-native pattern for isolating heavy read/reporting traffic from transactional writes in RDS for MySQL is to use read replicas and direct reporting queries to the replica endpoint(s).

Option C meets these requirements well. The primary RDS for MySQL instance handles transactional traffic (reads/writes). One or more RDS read replicas asynchronously replicate data from the primary. Because replication is asynchronous, some lag is expected; the requirement explicitly tolerates up to a 4-hour lag, which fits the read replica model. Directing batch reporting and analytical queries to a replica prevents those expensive queries from consuming CPU, memory, and I/O on the primary, thereby protecting interactive user performance. Deploying replicas across multiple Availability Zones also improves availability of the reporting tier and reduces the risk that an AZ issue prevents reporting access.

Option A is incorrect because a standard Multi-AZ DB instance uses a synchronous standby that is not readable and is intended for failover, not for serving analytical queries. Option B describes a Multi-AZ DB cluster deployment, which does provide readable standbys in some RDS engines; however, for the classic RDS MySQL exam pattern, the most direct and widely used method to isolate analytics is read replicas. Option D creates a nightly snapshot-based read-only copy; this increases operational complexity, can result in stale data for most of the day, and introduces provisioning delays, which is unnecessary when replicas provide continuous near-real-time copies.

Therefore, C is the best fit because it provides HA for the primary, isolates reporting reads to replicas, and meets the allowed replication lag requirement.

Amazon DynamoDB supports Time to Live (TTL), which automatically and asynchronously deletes expired items based on a timestamp attribute. TTL is ideal for automatic data expiration with very low operational overhead.

In this scenario:

When a user requests deletion, the system can calculate an expiration timestamp one month in the future.

A Lambda function is used once per request to write or update the item’s TTL attribute to that timestamp (Option C).

DynamoDB TTL then automatically removes the item after the expiration time. Deletion typically occurs within 48 hours of the TTL timestamp, which satisfies the “within one month” requirement.

This approach offloads the actual deletion to DynamoDB and avoids building complex orchestration or periodic cleanup jobs.

Options A, B, and D add unnecessary components (EventBridge, streams, AWS Config, and Lambda-based deletion workflows) on top of TTL or custom logic, increasing operational overhead without providing additional value for the given requirement.

The optimal solution for scalable and resilient hybrid networking is to use AWS Direct Connect with a Direct Connect gateway for secure, low-latency access to AWS, and an AWS Transit Gateway to manage connectivity among hundreds of VPCs.

By associating the Transit Gateway with the Direct Connect gateway, you enable transitive routing between on-premises and all VPCs, while minimizing network complexity and maintaining high performance.

VPC peering does not scale well, and VPNs don’t offer the same performance or consistency.

Amazon DynamoDB supports two read consistency models: eventually consistent reads and strongly consistent reads. By default, DynamoDB uses eventual consistency, which means reads might not immediately reflect the most recent writes. This behavior explains why the application is not always receiving the latest data.

Because latency and performance are acceptable, the problem is not throughput or response time—it is data consistency. Therefore, the correct design change is to enable strongly consistent reads, which guarantee that reads always return the most up-to-date data after a successful write.

Option C is correct because strongly consistent reads ensure that the application sees the latest committed value for an item. This is critical for use cases such as inventory systems, user profiles, or transactional workflows where stale data can cause incorrect behavior.

Option A is invalid because DynamoDB does not support traditional read replicas. Option B does not affect consistency; GSIs are used to query data by alternative keys. Option D would worsen the problem because eventual consistency already causes stale reads.

Therefore, C is the appropriate recommendation to ensure correctness of returned data without changing the table schema or introducing additional complexity.

Why Option C is Correct:

NAT Gateway: Allows private subnets to access the internet for outbound requests while preventing inbound connections.

High Availability: Deploying NAT gateways in both AZs ensures fault tolerance.

Shared Route Table: Simplifies routing configuration for private subnets.

Why Other Options Are Not Ideal:

Option A: Creating separate route tables for each subnet adds unnecessary complexity.

Option B: Internet gateways allow inbound access, violating the requirement to block public IPv4 access.

Option D: Egress-only internet gateways are designed for IPv6, not IPv4.

AWS References:

Amazon VPC NAT Gateway:AWS Documentation - NAT Gateway

A target tracking policy automatically adds or removes EC2 capacity to keep the selected metric close to a defined target. Setting ASGAverageCPUUtilization to 75% causes the Auto Scaling group to scale out before CPU utilization reaches the observed 90% instability threshold. A target of 90% would allow the application to reach the known failure condition before sufficient scaling occurred. Manually increasing minimum capacity only after instability appears is reactive and creates unnecessary administrative work. Scheduled scaling is unsuitable because the question describes occasional utilization increases rather than a predictable daily traffic pattern. Target tracking continuously evaluates demand and manages capacity without requiring operators to determine exact scaling increments or schedules. Therefore, the 75% CPU target provides the required stability with the least ongoing operational overhead.

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

Amazon S3 Access Points simplify managing data access for shared datasets in S3 by allowing the creation of distinct access policies for different applications or users. Each access point has its own policy and can be managed independently. This method avoids overloading a single bucket policy and helps remain within policy size limits.

Option D provides a scalable and operationally efficient solution by offloading individual access controls from a central bucket policy to individually managed access points, which is ideal for environments with many consuming applications.

As the number of VPCs grows, managing individual VPC connections becomes complex and unscalable. AWS Transit Gateway is specifically designed to act as a central hub that connects multiple VPCs and on-premises networks through Direct Connect.

Option B simplifies network architecture by allowing hundreds or thousands of VPCs to connect through a single gateway, reducing routing complexity and operational overhead. Transit Gateway supports scalable routing, centralized inspection, and simplified expansion.

The other options do not address network connectivity or scaling challenges. Therefore, B is the correct solution.

To ensure that log files are immutable and cannot be deleted or overwritten for a specified retention period, Amazon S3 offers Object Lock in Compliance Mode. When enabled:

Compliance Mode: Ensures that a protected object version can ' t be overwritten or deleted by any user, including the root user in your AWS account, for the duration of the retention period. AWS Documentation

S3 Versioning: Must be enabled on the bucket to use Object Lock. This allows multiple versions of an object to be stored, ensuring that previous versions are preserved and protected. Amazon Web Services, Inc.

By enabling S3 Versioning and applying Object Lock in Compliance Mode with a 1-year retention period, the company can meet regulatory requirements to retain log data securely and prevent any modifications or deletions during that time.

The requirement combines two key goals: reduce post-migration database administration/maintenance cost and minimize application rewrites for an existing Microsoft SQL Server application that relies heavily on T-SQL and stored procedures. Amazon Aurora PostgreSQL-Compatible with Babelfish is designed for this exact migration pattern: it helps applications written for SQL Server to run with reduced code changes by providing compatibility for commonly used SQL Server semantics, including T-SQL constructs, procedural logic, and SQL Server-style connectivity patterns (depending on feature usage). Aurora itself is a managed database service that reduces operational overhead compared to self-managed databases by offloading tasks such as provisioning, patching (within service capabilities), backups, and high availability patterns.

Option C (RDS for SQL Server) would indeed minimize rewrites because it keeps the engine the same, but it typically does not optimize operating costs as effectively as migrating off commercial SQL Server licensing/edition costs; it also keeps you on the same engine family, which often carries higher license implications and may not meet the “minimize operating costs” intent as strongly as moving to Aurora PostgreSQL with Babelfish. Option B is not suitable because Redshift Spectrum is for analytics over data in S3, not for running an OLTP ecommerce database with stored procedures. Option D is also a mismatch: EMR is for big data processing frameworks, not a relational OLTP database replacement for SQL Server.

Therefore, A best balances lower ongoing operational cost with reduced refactoring effort by using Aurora’s managed capabilities while leveraging Babelfish to ease SQL Server-to-PostgreSQL migration friction.

Securing the root user account requires setting a strong password and enabling multi-factor authentication (MFA). AWS recommends never sharing the root user credentials, setting up individual IAM users for everyday operations, and always protecting the root user with MFA for maximum security.

Reference Extract:

" AWS recommends securing the root user with a strong password and enabling multi-factor authentication (MFA). Do not use or share root credentials for everyday tasks. "

Source: AWS Certified Solutions Architect – Official Study Guide, IAM and Security Best Practices section.

The requirement is to scan container images for CVEs with the fewest changes to existing ECS workloads. Amazon ECS integrates natively with Amazon Elastic Container Registry (ECR), making ECR the natural place to implement vulnerability scanning without modifying the orchestration platform.

Option A meets the requirement most efficiently. ECR provides built-in vulnerability scanning that can be enabled using scan on push, ensuring that every new image uploaded to the repository is automatically scanned for known CVEs. This capability requires no changes to ECS task definitions beyond referencing ECR images, which is typically already the case. Scan results are maintained by AWS and can be reviewed centrally, providing ongoing security visibility.

Option C introduces a major architectural change by migrating to EKS, which violates the “fewest changes” requirement. Options B and D misuse services: Amazon Macie is designed for sensitive data discovery in S3, not container image vulnerability scanning, and storing images in S3 breaks container-native workflows. Lambda-driven Inspector scans for container images are not required when ECR already provides integrated scanning.

Therefore, A is the optimal solution because it leverages native ECS–ECR integration, requires minimal operational changes, and provides automated CVE scanning aligned with AWS container security best practices.

This workload has two distinct needs: (1) a managed way for external clients to upload files using a familiar managed file transfer protocol, and (2) an automated, low-ops method to run a watermarking step and store the resulting images as objects. AWS Transfer Family provides a fully managed capability to receive files over protocols such as SFTP, while landing those files directly into Amazon S3 as objects. That directly satisfies the requirement that “uploaded images must be stored as objects” with minimal infrastructure management.

To automate watermarking with minimal operational overhead, invoking AWS Lambda is a strong fit. Lambda is serverless and scales automatically with incoming uploads, and it can run the watermarking logic as code without managing servers. Transfer Family supports managed workflows that can orchestrate post-upload actions; using a Transfer Family workflow to invoke a Lambda function provides a clean, managed, event-driven pipeline: clients upload via SFTP → objects land in S3 → workflow triggers watermark processing → output is written back to S3.

Option A adds operational burden by requiring an EC2-based application tier for watermarking, which increases patching and scaling responsibilities. Option B can work (S3 + Batch), but it requires building and operating the upload mechanism (REST APIs) and typically more orchestration than necessary for simple “upload then process” flows; Batch is better when you need large-scale, long-running batch compute rather than lightweight per-object processing. Option D is unsuitable because S3 Glacier Deep Archive is intended for long-term archival with slow retrieval, which conflicts with active workflow processing and watermark automation.

Therefore, C best meets the requirements using managed services end-to-end: Transfer Family for ingestion, S3 for object storage, and Lambda for automated watermarking.

AWS Control Tower provides automatic account governance, centralized logging, CloudTrail aggregation, and integrates directly with AWS Security Hub, which evaluates compliance against FSBP standards. This is the lowest operational overhead AWS-native solution.

Instances in a private subnet cannot directly reach the internet because they do not have public IP addresses and the private subnet route table typically does not send 0.0.0.0/0 traffic to an internet gateway. However, these instances still need outbound-only internet access to download patches and updates while remaining inaccessible from the internet. The standard AWS design to achieve this is a NAT gateway deployed in a public subnet.

Option C is required because a NAT gateway must reside in a public subnet that has a route to the internet gateway. This allows the NAT gateway to forward outbound traffic from private instances to the internet and return responses, without allowing inbound connections initiated from the internet to those instances.

Option A is required because a NAT gateway uses an Elastic IP address to represent its public-facing identity on the internet. Without an Elastic IP, the NAT gateway cannot communicate with internet endpoints. The Elastic IP is associated with the NAT gateway, not with the internet gateway.

Option B is required because the private subnet needs a route for 0.0.0.0/0 (default route) that targets the NAT gateway. This ensures that outbound internet-bound traffic from the private instances is sent to the NAT gateway rather than being dropped.

Option D is incorrect because a NAT gateway in a private subnet would not have a working route to the internet gateway and would not provide internet egress. Option E is incorrect because the public subnet’s default route should point to the internet gateway, not to the NAT gateway. Option F is incorrect because you do not associate Elastic IPs with an internet gateway.

Therefore, A, B, and C correctly implement private subnet outbound internet access while keeping the instances unreachable from the internet.

The best answer isAPI Gateway + SQS + DLQ + Lambdabecause it combines API ingestion with durable queuing and asynchronous processing. AWS guidance for event-driven serverless architectures specifically recommends usingAmazon SQSto decouple components and durably persist messages when downstream processing is slower or bursty. AWS also documents thatdead-letter queueshelp isolate messages that fail processing, which supports the requirement to avoid losing requests. API Gateway can integrate with AWS services, including SQS, to accept requests from mobile and web clients. The ALB options do not provide the same durable buffering, and the SNS option is less appropriate because the key requirement is loose coupling with durable request preservation. Therefore,Bis the strongest design. (AWS Documentation)

Analysis:

The company ' s requirements are to migrate 5 PB of data from physical tapes to AWS within 6 months, preserve the data for 10 years, and ensure cost efficiency.AWS Storage Gateway Tape Gatewayis purpose-built for such use cases, as it seamlessly integrates with backup applications and provides virtual tape storage in Amazon S3 Glacier Deep Archive.

Why Option D is Correct:

Tape Gateway: Enables the migration of physical tapes to virtual tapes. Virtual tapes are stored in Amazon S3 and can later be archived in Amazon S3 Glacier Deep Archive for long-term storage.

Cost Efficiency: Amazon S3 Glacier Deep Archive is the lowest-cost storage class for long-term data preservation.

Operational Simplicity: Tape Gateway integrates with existing on-premises backup software, reducing the need for additional tools or manual processes.

Scalability: Can handle the migration of large datasets, such as 5 PB, within the required timeframe.

Why Other Options Are Not Ideal:

Option A:

AWS DataSync is not designed for reading data directly from physical tapes. Staging the data on local storage adds unnecessary complexity and cost.Not suitable.

Option B:

Using backup applications to write directly to S3 Glacier Deep Archive may not leverage AWS-native services optimally. Tape Gateway simplifies the workflow significantly.Less efficient.

Option C:

Snowball Edge is ideal for environments without high-bandwidth connectivity. However, the company already has a 10 Gbps Direct Connect, making Tape Gateway a better choice.Not cost-effective.

AWS References:

AWS Storage Gateway - Tape Gateway:AWS Documentation - Tape Gateway

Amazon S3 Glacier Deep Archive:AWS Documentation - Glacier Deep Archive

Using a Lambda function as part of the Kinesis Data Firehose pipeline allows for real-time detection and masking of PII before data is written to S3. This ensures that PII is never stored in its raw form in the data lake.

Option B:Amazon Macie can scan and classify data but does not provide in-line PII masking for data ingestion.

Option C:Server-side encryption secures data but does not mask PII.

Option D:CloudHSM is unnecessary for PII masking and adds complexity without addressing the requirements.

AWS Documentation References:

Using Lambda with Kinesis Data Firehose

The lowest-overhead answer isAPI Gateway with direct AWS service integration to DynamoDB PutItem. DynamoDB’s API includes a native PutItem action for writing an item to a table, and API Gateway supports direct AWS service integrations, which lets the web application send requests through an API layer without developers touching DynamoDB directly. This approach is scalable, reusable, and avoids managing Lambda code purely as a pass-through layer. The SQS-based design adds unnecessary queueing for a straightforward write API, and ALB is not the appropriate frontend for invoking DynamoDB actions. Therefore, direct API Gateway service integration is the cleanest design.

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

Detailed Explanation:

A. ECS + API Gateway:Overly complex and costly for an on-demand, intermittent workload.

B. EventBridge + SNS:EventBridge schedules are unnecessary for on-demand generation.

C. EKS + API Gateway:Overkill for this use case, with high operational overhead.

D. Lambda + SES:Most cost-effective and efficient solution for generating and emailing reports on demand.

Creating aVPC endpointfor S3 and configuring abucket policyto allow access only from the endpoint ensures that only EC2 instances within the VPC can access the S3 bucket. This solutionimproves security by restricting access at the network level without the need for public internet access.

Option A (IAM policies): IAM policies alone cannot restrict access based on the network location.

Option B and D (Encryption): Encryption secures data at rest but does not restrict network access to the bucket.

AWS References:

Amazon S3 VPC Endpoints

Throughput Optimized HDD (st1) is the correct and most cost-effective EBS choice because the workload reads and processes large log files sequentially. AWS defines st1 volumes as low-cost magnetic storage designed for frequently accessed, throughput-intensive workloads, including log processing. This workload does not require high random IOPS or ultra-low latency, so gp3 and io1 would be more expensive than necessary. Cold HDD (sc1) is cheaper but intended for less frequently accessed data, so it is not appropriate for an active log-processing application. Because the company wants minimal architectural change from SAN-based block storage, an EBS volume preserves the block-storage model while meeting the sequential throughput requirement.

Amazon S3 is the right durable storage service for photos, and a lifecycle transition toS3 Intelligent-Tieringis cost-effective when older objects are accessed infrequently but should remain readily available. AWS documentation explains that S3 Intelligent-Tiering automatically moves objects based on access patterns and can be used with lifecycle transitions. This keeps management overhead low while optimizing ongoing storage cost. EFS, DynamoDB, and FSx for Lustre are not appropriate long-term photo object stores for this pattern. Because the company does not want to delete older photos and wants a durable, scalable retrieval solution, S3 plus Intelligent-Tiering is the best answer.

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

AWS guidance for global, highly available, low-latency applications using a relational database recommends:

Amazon CloudFront with Amazon S3 for static content to cache data at edge locations globally and minimize latency for static assets.

A regional application tier deployed close to users using managed container services such as Amazon ECS on AWS Fargate, which removes the need to manage servers and scales automatically, reducing operational overhead.

A relational database tier using Amazon Aurora global database, which is purpose-built for globally distributed applications. Aurora global database provides a primary cluster in one Region with low-latency read replicas in secondary Regions and fast cross-Region replication, enabling low-latency reads and high availability for global users.

Option A uses only a single Region, which does not meet the “global users with low latency” requirement.

Option C uses RDS and DMS-based replication, which requires more management and does not provide Aurora’s integrated global database features.

Option D replaces the relational database with DynamoDB, which violates the requirement that the application interacts with a relational database.

Amazon S3 Glacier Flexible Retrieval is designed for long-lived, infrequently accessed data where retrieval times of minutes to hours are acceptable. It offers very low storage cost per GB while still supporting faster retrieval than archival tiers that can take many hours or days.

The requirement states that data is rarely accessed and must be retrievable within 12 hours. Glacier Flexible Retrieval meets this retrieval-time requirement and is more cost-effective per GB than Standard and Infrequent Access storage classes for long-term, rarely accessed data.

S3 Standard, S3 Standard-IA, and S3 One Zone-IA are optimized for more frequent or lower-latency access and have higher storage cost per GB compared to Glacier Flexible Retrieval.

Amazon EMR is the strongest fit here because AWS describes EMR as a service for processing, analyzing, transforming, and moving large amounts of data, and EMR supports running parallel steps for distributed processing. The question explicitly wantsparallel processingof large semistructured data in S3, which matches EMR well. AWS also documents a supported pattern forloading data from Amazon EMR to Amazon Redshift, and Redshift supports querying semistructured data, which makes EMR plus Redshift a natural enrichment workflow. Athena and Glue can be useful in some analytics patterns, but the requirement for parallel high-volume processing points most directly to EMR.

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

For network-level database access control, AWS recommends usingsecurity groups, which are stateful and can restrict inbound access to a specific on-premises IP address. For credential storage and automatic rotation,AWS Secrets Manageris the correct managed service. AWS documentation states that Secrets Manager helps protect access to applications and services by managing secrets and rotating them automatically for supported databases. KMS is a key-management service, not a secret store for database passwords. Network ACLs are stateless and are less appropriate than security groups for this requirement. Therefore, A combines the correct network control with the correct secret-rotation service. (docs.aws.amazon.com)

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

The problem is that documents are stored on instance-local storage, so once the site scales horizontally, users may land on an instance that does not have the requested file. Amazon EFS is the best fit because AWS documents that EFS provides shared file storage with concurrent access from multiple EC2 instances and is accessible from all Availability Zones in the Region. That lets every web server read the same document set without changing to an object-storage pattern. The cron-based answers introduce delay and inconsistency, and S3 would require a bigger application-path change than the shared file system approach. For the least disruptive and most reliable restoration of access across multiple EC2 instances, mounting a single EFS file system on all instances is the right solution.

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

AWSSecrets Managercan integrate directly with Amazon RDS for automatic and seamless password rotation. Secrets Manager handles the complexity of password management, including generating strong passwords and rotating them at a defined interval (e.g., every 30 days). It also automatically updates the connection information for RDS, minimizing operational overhead.

Option A (Lambda with EventBridge): While possible, this requires custom coding and operational management of Lambda, which introduces additional complexity.

Option B (Manual password change): Using the modify-db-instance command requires manual intervention and is not automated, leading to more operational effort.

Option D (Parameter Store): Systems Manager Parameter Store is less specialized for password management than Secrets Manager and does not have built-in automated rotation for RDS credentials.

AWS References:

AWS Secrets Manager Rotation for RDS

AWS Compute Optimizerprovides detailed recommendations for optimizingAmazon EBS volumes, including insights into underutilized volumes, inefficient configurations, and potential cost savings. It analyzes usage patterns and provides recommendations based on historical data, making it the ideal tool for this use case.

Option A (Amazon Inspector): Amazon Inspector is for security assessments, not for cost optimization.

Option B (Systems Manager): Systems Manager does not specifically provide EBS optimization recommendations.

Option C (CloudWatch): CloudWatch metrics help monitor usage but do not offer optimization recommendations like Compute Optimizer.

AWS References:

AWS Compute Optimizer

AWS Batch supports Windows-based jobs and automates provisioning and scaling of compute environments. Paired with AWS Fargate, it removes the need to manage infrastructure. This solution requires the least operational overhead and is cloud-native, providing flexibility and scalability.