Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company is building a real-time data processing pipeline for an ecommerce application. The application generates a high volume of clickstream data that must be ingested, processed, and visualized in near real time. The company needs a solution that supports SQL f...
When evaluating the best option for a real-time data processing pipeline with SQL support for data processing and Jupyter notebooks for interactive analysis, we need to consider the following key factors:
1. Real-time Data Ingestion: The system needs to handle a high volume of clickstream data in near real-time, so the ingestion mechanism should be robust and capable of handling streaming data efficiently.
2. Data Processing: The data needs to be processed with SQL support, meaning it should be possible to write SQL queries for transformation and analysis. Also, support for Jupyter notebooks for interactive analysis is a key requirement.
3. Visualization: Since the data needs to be visualized in near real-time, the solution should integrate easily with a visualization tool that provides real-time updates and interactive capabilities.
4. Ease of Use: The solution should be user-friendly and should allow for smooth integration between ingestion, processing, and visualization.
Let's analyze the options:
Option A: Use Amazon Data Firehose to ingest the data. Create an AWS Lambda function to process the data. Store the processed data in Amazon S3. Use Amazon QuickSight to visualize the data.
Data Ingestion: Amazon Data Firehose is a fully managed service for ingesting streaming data, which works well for high-volume data. However, it is not ideal for handling complex stream processing.
Data Processing: AWS Lambda is an excellent choice for lightweight, event-driven processing, but it lacks SQL support for complex transformations, which is a key requirement in this scenario. Lambda functions are generally more suited to simple processing tasks.
Visualization: Amazon QuickSight can be used for visualization, but it doesn't provide as much interactivity or real-time analytics as required for a dynamic, live data pipeline.
Drawback: The lack of SQL support for data processing and the limited interactivity in QuickSight makes this solution less optimal for real-time, SQL-based analysis and interactive work.
Option B: Use Amazon Kinesis Data Streams to ingest the data. Use Amazon Data Firehose to transform the data. Use Amazon Athena to process the data. Use Amazon QuickSight to visualize the data.
Data Ingestion: Amazon Kinesis Data Streams can handle the real-time ingestion of large volumes of clickstream data, making it a good choice for this scenario.
Data Processing: Amazon Athena supports SQL-based querying over data stored in Amazon S3. However, Athena is designed for batch processing rather than real-time processing. While it can handle SQL queries efficiently, it may not be the best option for real-time processing of streaming data.
Visualization: QuickSight can be used for visualization, but similar to Option A, it is not as suited for interactive, real-time analysis compared to other solutions.
Drawback: While Athena supports SQL, its batch-oriented nature is not ideal for near real-tim...
Author: StarlightBear · Last updated Jul 27, 2026
A medical company needs to store clinical data. The data includes personally identifiable information (PII) and protected health information (PHI).
An ML engineer needs to implement a solution to ensure that the...
Key Considerations for Selecting the Solution:
Data Privacy: PII and PHI must be protected and not used during model training.
Automation: The solution should ensure data masking or encryption is done automatically without requiring manual intervention.
Integration with ML Models: The solution should integrate seamlessly with ML model training workflows.
Scalability: The solution must scale as the volume of data increases.
Compliance: The solution must comply with regulations like HIPAA, which govern the use of PII and PHI in healthcare.
---
Option A: Store the clinical data in Amazon S3 buckets. Use AWS Glue DataBrew to mask the PII and PHI before the data is used for model training.
Advantages:
AWS Glue DataBrew is a fully managed service for data preparation, making it easy to clean and transform data before use.
DataBrew supports masking of PII and PHI, ensuring that these sensitive data types do not get exposed in the model training process.
Amazon S3 is scalable and can store large amounts of data.
Drawbacks:
While AWS Glue DataBrew can mask PII and PHI, it is an additional layer of data preparation and might introduce complexity in terms of workflow management.
It could require manual intervention in the setup process to configure the data transformation and masking logic.
Scenario:
This solution is appropriate when there is a need for comprehensive, scalable data storage and masking of both PII and PHI.
Option B: Upload the clinical data to an Amazon Redshift database. Use built-in SQL stored procedures to automatically classify and mask the PII and PHI before the data is used for model training.
Advantages:
Amazon Redshift is a highly scalable data warehouse solution, suitable for storing large datasets.
SQL stored procedures can be used to automatically classify and mask PII/PHI before training.
Drawbacks:
Redshift is more suited for structured data rather than the unstructured data typically found in clinical data.
Masking sensitive data directly within SQL stored procedures can be complex and error-prone, leading to potential issues with compliance and privacy.
It doesn't provide as granular control as some other options like DataBrew or Comprehend when dealing with text-heavy datasets.
Scenario:
This solution is ideal if the data is already structured and stored within Redshift, and there's a need to manage large-scale data warehouses.
Option C: Use Amazon Comprehend to detect a...
Author: ShadowWolf101 · Last updated Jul 27, 2026
A company wants to ingest customer payment data into the company's data lake in Amazon S3. The company receives payment data every minute on average. The company wants to analyze the payment data in real time. Then the company wants to ingest the da...
To determine the most operationally efficient solution, let’s evaluate each option based on key factors like data ingestion speed, scalability, ease of integration with Amazon S3 (the data lake), real-time analysis, and simplicity of operation.
A) Use Amazon Kinesis Data Streams to ingest data. Use AWS Lambda to analyze the data in real time.
- Data Ingestion: Amazon Kinesis Data Streams can handle real-time streaming data with low-latency ingestion, making it suitable for continuously ingesting payment data every minute.
- Real-time Analysis: AWS Lambda can trigger functions on each event in the stream, allowing you to process and analyze the data in real time.
- Operational Efficiency: This approach requires you to manage both the stream and the Lambda functions, which can lead to operational complexity, especially as the amount of data grows and the number of Lambda invocations increases.
- Use Case: This is a good solution for real-time analytics, but it requires more effort in managing Lambda functions and stream scaling.
B) Use AWS Glue to ingest data. Use Amazon Kinesis Data Analytics to analyze the data in real time.
- Data Ingestion: AWS Glue is primarily used for batch processing and ETL (extract, transform, load) jobs. It’s not the best fit for real-time ingestion, as it typically operates on scheduled runs rather than continuous streaming data.
- Real-time Analysis: Amazon Kinesis Data Analytics is designed for real-time stream processing, but it expects data to come from streaming sources (like Kinesis Data Streams or Kinesis Data Firehose). Using AWS Glue for ingestion makes it less suitable for real-time analytics.
- Operational Efficiency: While AWS Glue is powerful for batch data processing, it’s not ideal for real-time ingestion, and using it in this scenario introduces unnecessary complexity and delays.
- Use Case: This solution is not a good fit for real-time data ingestion and analysis.
C) Use Amazon Kinesis Data Firehose to ingest data. Use Amazon Kinesis Data Analytics to analyze the data in real time.
- Data Ingestion: Kinesis Data Firehose is designed for easy, scalable, real-time data ingestion and can automatically deliver data to Amazon S3. This matches the requirement of ingesting data into the data lake (S3) and is highly efficient.
- Real-time Analysis: Kinesis Data Analytics allows real-time analysis of streaming data. It integrates directly with Kinesis Data Firehose, providing a seamless ...
Author: Elijah · Last updated Jul 12, 2026
A company runs a website that uses a content management system (CMS) on Amazon EC2. The CMS runs on a single EC2 instance and uses an Amazon Aurora MySQL Multi-AZ DB instance for the data tier. Website images are stored on an Amazon Elastic Block Store (Amazon EBS) volume that is mounted inside the EC2 instance.
...
Key Factors for Improving Performance and Resilience:
1. Scalability: To ensure the website can handle varying traffic loads and scale automatically as needed.
2. Availability and Fault Tolerance: To minimize downtime and ensure the website remains available even in the event of instance or infrastructure failures.
3. Performance Optimization: To ensure fast access to content, such as images, and improve load times.
4. Operational Efficiency: To reduce management overhead and improve the overall resilience of the application.
A) Move the website images into an Amazon S3 bucket that is mounted on every EC2 instance.
- Scalability and Performance: Amazon S3 provides highly scalable, durable storage for large amounts of data. Storing images in S3 can significantly improve performance by offloading the static content from the EC2 instance. S3 is designed for high availability, which can improve the resilience of the website.
- Mounting to EC2 Instances: However, S3 is an object storage service and is not directly "mounted" like a file system. Although you can use tools like S3FS to mount it, it’s not ideal for high-performance file system operations. Directly serving static content via S3 with CloudFront is generally more efficient than mounting S3 on EC2.
- Rejected Reasoning: Mounting S3 is not a standard or optimal approach for high-performance applications that need low-latency file access.
B) Share the website images by using an NFS share from the primary EC2 instance. Mount this share on the other EC2 instances.
- Scalability and Availability: NFS (Network File System) relies on a single instance for the file share, creating a potential single point of failure. In case the primary EC2 instance goes down, all other instances that rely on the NFS share will lose access to the images.
- Performance Issues: NFS can introduce bottlenecks and performance issues, especially as the number of instances increases. It does not scale well compared to solutions like Amazon EFS or S3.
- Rejected Reasoning: This option introduces a potential single point of failure and is not as scalable or resilient as other solutions, especially in distributed environments.
C) Move the website images onto an Amazon Elastic File System (Amazon EFS) file system that is mounted on every EC2 instance.
- Scalability and Availability: Amazon EFS provides scalable, shared file storage that can be mounted on multiple EC2 instances. It is highly available, supports concurrent access from multiple EC2 instances, and automatically scales as the application grows.
- Performance: EFS is designed for use cases that require shared storage with low-latency access. It integrates well with EC2 and provides a highly durable, scalable solution for static content storage like images.
- Resilience: EFS automatically handles failover and replication, making it more resilient than using NFS from a single EC2 instance.
- Selected Reasoning: This option provides shared storage with ex...
Author: Olivia · Last updated Jul 12, 2026
A company runs an infrastructure monitoring service. The company is building a new feature that will enable the service to monitor data in customer AWS accounts. The new feature will call AWS APIs in customer accounts to describe Amazon EC2 instances and read Amaz...
Key Factors for Secure Access:
1. Least Privilege: Ensure the company only has the necessary permissions to access specific resources in the customer accounts (i.e., EC2 instances and CloudWatch metrics).
2. Temporary Credentials: It's important to minimize the security risk by using temporary credentials instead of permanent access keys.
3. Ease of Integration: The solution should be easy to integrate into the company’s service without requiring excessive management overhead.
4. Scalability and Maintenance: The solution should scale easily as the company adds more customers and needs to access more AWS accounts.
A) Ensure that the customers create an IAM role in their account with read-only EC2 and CloudWatch permissions and a trust policy to the company’s account.
- IAM Role and Trust Policy: This option suggests creating a role in the customer's account with appropriate permissions (read-only access to EC2 and CloudWatch). The trust policy allows the company’s AWS account to assume this role.
- Security: Using an IAM role with a trust policy ensures that only the company’s account can assume the role, which adheres to the principle of least privilege. Temporary credentials are granted when assuming the role, minimizing the risk of long-term access key exposure.
- Ease of Integration: This solution is easy to implement, as it involves setting up an IAM role in the customer's account and allowing the company’s account to assume it. The company would call the `AssumeRole` API to retrieve temporary credentials.
- Scalability and Maintenance: This approach scales well and is secure since temporary credentials are automatically rotated, reducing the risk of compromised access.
Why this is selected: This option offers a secure, scalable, and manageable way to access customer accounts by using IAM roles with temporary credentials. It aligns well with AWS best practices for cross-account access.
B) Create a serverless API that implements a token vending machine to provide temporary AWS credentials for a role with read-only EC2 and CloudWatch permissions.
- Token Vending Machine: While providing temporary credentials via a token vending machine can work, this solution adds complexity. You would need to manage the vending machine service, ensure it securely generates credentials, and implement appropriate expiration and validation for those credentials.
- Operational Overhead: Managing an API for issuing temporary credentials adds additional operational complexity and may not be as simple as using AWS-native features like IAM roles with trust policies.
- Security Risks: If the token vending machine is not implemented securely, it could introduce vulnerabilities, especially with regards to how tokens are managed and transmitted.
- Rejected Reasoning: While this...
Author: Vivaan · Last updated Jul 12, 2026
A company needs to connect several VPCs in the us-east-1 Region that span hundreds of AWS accounts. The company's networking team has its own AWS account to manage the cloud netwo...
Key Factors for Operational Efficiency:
1. Scalability: The solution should easily scale to accommodate hundreds of VPCs across multiple accounts without requiring significant manual configuration.
2. Centralized Management: The solution should allow for centralized management of the network, reducing the complexity of managing connections individually.
3. Automation and Maintenance: The solution should minimize the ongoing operational effort, especially as new VPCs are added.
4. Cost and Performance: The solution should be cost-effective while maintaining good performance for inter-VPC communication.
A) Set up VPC peering connections between each VPC. Update each associated subnets route table.
- Scalability Issues: VPC peering requires a separate connection between each pair of VPCs. With hundreds of VPCs, this leads to a significant number of peering connections and route table updates. Specifically, the number of peering connections grows quadratically (O(n^2)), making it highly impractical for a large-scale environment.
- Operational Overhead: Managing hundreds of peering connections and route tables would become difficult and error-prone. Each new VPC added would require multiple manual configurations.
- Rejected Reasoning: While this approach might work for a small number of VPCs, it is not operationally efficient or scalable for a large number of VPCs across multiple accounts.
B) Configure a NAT gateway and an internet gateway in each VPC to connect each VPC through the internet.
- Inefficiency and Complexity: Using NAT gateways and internet gateways for inter-VPC communication is not a recommended approach because it would route traffic through the internet, increasing latency and operational complexity. Managing multiple NAT gateways and internet gateways is inefficient, especially when dealing with cross-account traffic.
- Security Risks: Exposing VPC traffic to the internet increases the security risks as the VPCs would be communicating over public networks.
- Rejected Reasoning: This approach is not secure, efficient, or scalable for inter-VPC communication, especially in a multi-account, large-scale environment.
C) Create an AWS Transit Gateway in the networking team’s AWS account. Configure static routes from each VPC.
- Scalability and Centralized Management: AWS Transit Gateway (TGW) is specifically designed for scenarios like this, where multiple VPCs nee...
Author: ShadowWolf101 · Last updated Jul 12, 2026
A company has Amazon EC2 instances that run nightly batch jobs to process data. The EC2 instances run in an Auto Scaling group that uses On-Demand billing. If a job fails on one instance, another instance will reprocess the job. The batch jobs run between 12:00 AM and 06:00 ...
Key Factors in Choosing the Most Cost-Effective Solution:
1. Cost-Effectiveness: The solution should minimize costs while still meeting the requirements of the batch job, including reliability and scalability.
2. Instance Availability: The batch jobs run during specific times (12:00 AM to 06:00 AM), so the solution should ensure that instances are available during this window, with minimal interruptions.
3. Scalability and Reliability: The solution must ensure that enough instances are available to process the batch jobs even if a job fails, which might require additional capacity.
4. Flexibility in Scaling: The solution should be able to automatically adjust the number of EC2 instances needed based on the job requirements.
A) Purchase a 1-year Savings Plan for Amazon EC2 that covers the instance family of the Auto Scaling group that the batch job uses.
- Cost Savings: A Savings Plan offers significant savings (compared to On-Demand) in exchange for a commitment to a certain amount of usage over a 1- or 3-year period.
- Flexibility: A Savings Plan provides flexibility in instance types, sizes, and regions, which can be helpful if the company decides to change instance types or other parameters.
- Usage Pattern: Since the batch jobs run only for a limited time each day (12:00 AM to 06:00 AM), this solution might not be as cost-effective as it locks the company into a commitment to pay for EC2 usage during a fixed term, which may not fully match the batch job's usage pattern.
- Rejected Reasoning: Although it provides savings, it may not be as flexible or optimized for this type of intermittent workload (daily batch jobs) because the company only needs instances during a specific window.
B) Purchase a 1-year Reserved Instance for the specific instance type and operating system of the instances in the Auto Scaling group that the batch job uses.
- Cost Savings: Reserved Instances provide cost savings by committing to a specific instance type for a long duration (1 year or more).
- Limitations on Flexibility: Reserved Instances are not as flexible as Savings Plans and are tied to specific instance types, sizes, and operating systems, which may be less optimal if the company needs to scale out dynamically based on demand.
- Usage Pattern: The batch job runs only during a specific time window each day, which means the company would still be paying for instance capacity that isn't always in use.
- Rejected Reasoning: Reserved Instances are best for predictable, long-term workloads. The batch job’s intermittent usage pattern doesn't fully align with the commitment required for Reserved Instances, making this option less cost-efficient.
C) Create...
Author: Emma · Last updated Jul 12, 2026
A social media company is building a feature for its website. The feature will give users the ability to upload photos. The company expects significant increases in demand during large events and must ensure that the website can handle...
To determine the most scalable solution for the social media company’s photo upload feature, we need to assess each option based on scalability, handling large amounts of traffic, and minimizing operational overhead. Let's evaluate each option:
A) Upload files from the user's browser to the application servers. Transfer the files to an Amazon S3 bucket.
- This approach involves the user first uploading files to the application servers, which then forward the files to Amazon S3.
- Scalability concerns: The application servers become a bottleneck because they must handle both the user traffic and the file uploads, requiring significant compute and network resources. Scaling the servers to handle high traffic during large events can be costly and complex.
- Operational overhead: The application servers need to process each upload, which requires maintaining and scaling those servers under heavy load.
- Rejection reason: This is not the most scalable option because it adds complexity and a central point of failure (the application servers).
B) Provision an AWS Storage Gateway file gateway. Upload files directly from the user's browser to the file gateway.
- AWS Storage Gateway is typically used to integrate on-premises environments with AWS cloud storage. The File Gateway component allows file-based access to Amazon S3 and is more suited for hybrid cloud scenarios.
- Scalability concerns: File Gateway isn’t designed to handle high levels of direct user traffic in web applications; it serves as a bridge between on-premises environments and S3, not a cloud-native solution for file uploads from a website.
- Operational overhead: This solution is more complex and not ideal for web-scale uploads.
- Rejection reason: It introduces unnecessary complexity and is not built for web-scale file uploads.
C) Generate Amazon S3 presigned URLs in the application. Upload files directly from the user's browser into an S3 bucket.
- Presigned URLs are a powerful AWS feature where t...
Author: Abigail · Last updated Jul 12, 2026
A company has a web application for travel ticketing. The application is based on a database that runs in a single data center in North America. The company wants to expand the application to serve a global user base. The company needs to deploy the application to multiple AWS Regions. Average latency must be less than 1 second on updates to the reservation database.
The company wants to have separate deployments of its web platform across multiple...
To determine the best solution for the company's web application that needs to be deployed across multiple AWS Regions with a globally consistent primary reservation database and low latency, we need to evaluate the different options.
A) Convert the application to use Amazon DynamoDB. Use a global table for the center reservation table. Use the correct Regional endpoint in each Regional deployment.
- Scalability & Global Consistency: Amazon DynamoDB is a fully managed NoSQL database that supports global tables for multi-region, fully replicated tables. It provides fast reads and writes and handles the consistency across regions, which ensures that data is available across multiple AWS regions with low latency.
- Latency: DynamoDB Global Tables can be set up to synchronize changes in less than 1 second, making it suitable for the company’s latency requirement.
- Rejection reason: The company already has a relational database for the application (assumed from the context of "reservation database"), and converting to a NoSQL solution may require significant application changes. It may not be the most suitable option if the company relies heavily on relational features (like complex joins, ACID transactions, etc.) which DynamoDB does not support as effectively as a relational database.
B) Migrate the database to an Amazon Aurora MySQL database. Deploy Aurora Read Replicas in each Region. Use the correct Regional endpoint in each Regional deployment for access to the database.
- Scalability & Global Consistency: Aurora provides high performance and scalability, and Aurora Global Databases can be used to replicate data between regions with low latency. However, Aurora Global Databases are specifically designed for cross-region replication with minimal latency (under 1 second). This solution ensures a globally consistent primary database with Aurora acting as the single source of truth.
- Latency: Aurora Global Databases are designed for low-latency cross-region replication, making them a good fit for the requirement of updates to the reservation database being completed in less than 1 second.
- Reason for selection: This solution is ideal because Aurora Global Databases provide a globally consistent database while supporting low-latency replication. Each region can have a read replica, and writes are centralized in the primary region, meeting the company's requirement for a single primary database with low latency.
C) Migrate the database to an Amazon RDS for MySQL database. Deploy MySQL read replica...
Author: Scarlett · Last updated Jul 12, 2026
A company has migrated multiple Microsoft Windows Server workloads to Amazon EC2 instances that run in the us-west-1 Region. The company manually backs up the workloads to create an image as needed.
In the event of a natural disaster in the us-west-1 Region, the company wants to recover workloads quickly in the us-west-2 Region. The company wants no more than 24 hours of data loss on the EC2 insta...
The company's goal is to automate backups of EC2 instances, ensuring minimal data loss (no more than 24 hours) and enabling a quick recovery in the event of a disaster in the us-west-1 Region, while also minimizing administrative effort. Let's evaluate each of the proposed solutions based on these criteria:
A) Create an Amazon EC2-backed Amazon Machine Image (AMI) lifecycle policy to create a backup based on tags. Schedule the backup to run twice daily. Copy the image on demand.
- Scalability & Automation: An AMI lifecycle policy helps automate the creation of backups based on tags, but it requires manual intervention to copy the AMI to another region (i.e., "copy the image on demand"). This introduces manual overhead and doesn't fully automate the backup process, especially for the disaster recovery aspect.
- Recovery and Data Loss: This solution would not provide an automated mechanism for copying the AMIs to another region as part of the disaster recovery process. While backups are automated, the process of copying to another region still requires manual steps, which doesn't meet the requirement for minimizing data loss and ensuring fast recovery in the event of a disaster.
- Rejection reason: It requires manual intervention for copying the image to another region and does not meet the requirement for minimizing data loss.
B) Create an Amazon EC2-backed Amazon Machine Image (AMI) lifecycle policy to create a backup based on tags. Schedule the backup to run twice daily. Configure the copy to the us-west-2 Region.
- Scalability & Automation: This solution allows AMI backups to be automated, scheduled twice daily, and automatically copied to us-west-2. This meets the requirement for disaster recovery in another region, and the backup is automated without manual intervention.
- Recovery and Data Loss: By automatically copying the AMI to us-west-2, this solution reduces the risk of data loss and allows for a faster recovery in the event of a disaster in us-west-1. The backup frequency of twice daily is within the 24-hour data loss limit.
- Reason for selection: This option provides the least administrative effort because it fully automates the backup and cross-region copy process, ensuring minimal data loss and quick recovery.
C) Create backup vaults in us-west-1 and in us-west-2 by using AWS Backup. Create a backup plan for the EC2 instances based on tag values. Create an AWS Lambda function to run as a scheduled job to copy the backup data to us-west-2.
- Scalability & Automation: While AWS Backup can automate the backup process, this solution requires the creation of a custom Lambda function to handle the copy of backup data between regions. This adds significant administrative overhead and complexity, as custom Lambda functions would need to be written, tested, and maintained.
- Recovery and Data Lo...
Author: Ahmed97 · Last updated Jul 12, 2026
A company operates a two-tier application for image processing. The application uses two Availability Zones, each with one public subnet and one private subnet. An Application Load Balancer (ALB) for the web tier uses the public subnets. Amazon EC2 instances for the application tier use the private subnets.
Users report that the application is running more slowly than expected. A security audit of the web server log files shows that the application is receiving millions of illegitimate requests from a small numbe...
The company is experiencing performance issues due to millions of illegitimate requests from specific IP addresses. The goal is to quickly mitigate the impact of these malicious requests while further investigation into a more permanent solution is underway. Let's evaluate the different options based on their effectiveness in resolving this issue.
A) Modify the inbound security group for the web tier. Add a deny rule for the IP addresses that are consuming resources.
- Effectiveness: Security groups are stateful and control traffic to EC2 instances at the instance level. However, security groups do not support explicit deny rules; they only allow you to define allowed traffic. This means you cannot directly deny access based on specific IP addresses in a security group.
- Rejection reason: Since security groups only allow specifying "allow" rules and not "deny" rules, this option will not be effective for blocking the illegitimate IPs.
B) Modify the network ACL for the web tier subnets. Add an inbound deny rule for the IP addresses that are consuming resources.
- Effectiveness: Network ACLs are stateless and operate at the subnet level, controlling traffic entering or leaving a subnet. Unlike security groups, network ACLs support both "allow" and "deny" rules, and they work at a broader level (subnet). By adding a deny rule for the offending IPs, traffic from these IPs can be blocked before it even reaches the web servers.
- Advantage: This is an effective and quick solution because it will prevent the malicious requests from reaching the ALB, improving the overall performance of the web tier.
- Reason for selection: This option is effective in immediately blocking unwanted traffic from the specific IP addr...
Author: Oscar · Last updated Jul 12, 2026
A global marketing company has applications that run in the ap-southeast-2 Region and the eu-west-1 Region. Applications that run in a VPC in eu-west-1 need to communicate securely with databases that...
In this case, the company needs to allow secure communication between applications running in the eu-west-1 region and databases in ap-southeast-2 region. Let's evaluate the different options and determine which one best meets the requirements for secure and efficient communication across regions.
A) Create a VPC peering connection between the eu-west-1 VPC and the ap-southeast-2 VPC. Create an inbound rule in the eu-west-1 application security group that allows traffic from the database server IP addresses in the ap-southeast-2 security group.
- Effectiveness: VPC peering allows direct communication between VPCs, and creating security group rules based on IP addresses can control access. However, VPC peering doesn't directly allow referencing security groups across regions. Also, security group rules generally need to be configured based on security group IDs, not IP addresses when dealing with cross-region traffic.
- Rejection reason: The approach of allowing traffic based on IP addresses is not ideal for cross-region communications, and VPC peering between regions requires security group referencing, not IP-based access.
B) Configure a VPC peering connection between the ap-southeast-2 VPC and the eu-west-1 VPC. Update the subnet route tables. Create an inbound rule in the ap-southeast-2 database security group that references the security group ID of the application servers in eu-west-1.
- Effectiveness: This solution correctly configures a VPC peering connection and enables communication between regions. It also sets up security group rules to allow traffic based on the security group ID of the application servers. This is a more secure and scalable solution because it uses security group IDs, ensuring that traffic is allowed only from the intended application servers.
- Reason for selection: The use of security group IDs for cross-region access is a best practice in AWS, as it provides an additional layer of security by tightly controlling which entities can communicate across th...
Author: BlazingPhoenix22 · Last updated Jul 12, 2026
A company is developing software that uses a PostgreSQL database schema. The company needs to configure multiple development environments and databases for the company's developers. On average, each development environment is used f...
To determine the most cost-effective solution, let's analyze each of the options based on key factors such as resource utilization, cost-efficiency, and use-case relevance. The main goal is to ensure the most cost-effective use of resources for the development environments and PostgreSQL databases.
Option A: Configure each development environment with its own Amazon Aurora PostgreSQL database
- Overview: Amazon Aurora is a fully managed database service that is compatible with PostgreSQL. Aurora is designed for high availability, scalability, and performance. However, it is typically more expensive than other database solutions because of its performance optimizations.
- Cost Analysis: Aurora is generally priced higher than RDS for PostgreSQL and does not offer the same level of cost efficiency for smaller, less intensive development environments. Given that the development environments are not likely to be used full-time, this option might lead to unnecessary overprovisioning of resources.
- Conclusion: While Aurora offers great performance and scalability, it's more suited for production workloads requiring high availability, which is not necessary for most development environments.
Option B: Configure each development environment with its own Amazon RDS for PostgreSQL Single-AZ DB instances
- Overview: Amazon RDS for PostgreSQL is a fully managed database service with the option for Single-AZ (Availability Zone) deployments. This option is cheaper than Amazon Aurora because it is a simpler, less complex service, without automatic failover to multiple AZs (which might be unnecessary for development environments).
- Cost Analysis: For a development environment that is only used for half of the day, Single-AZ instances can be cost-effective, especially when combined with options like instance size scaling, reserved instances, or stopping instances during non-working hours. This solution gives developers a dedicated database with better cost efficiency compared to Aurora.
- Conclusion: This option is a solid choice for development environments as it provides enough resources while being more affordable than Aurora.
Option C...
Author: StarlightBear · Last updated Jul 12, 2026
A company uses AWS Organizations with resources tagged by account. The company also uses AWS Backup to back up its AWS infrastructure resources. The company needs to back up all AWS resources.
...
To meet the company's need for backing up all AWS resources with the least operational overhead, we need a solution that automates resource identification and backup, reducing the need for manual intervention and minimizing ongoing management. Let’s analyze each of the options:
Option A: Use AWS Config to identify all untagged resources. Tag the identified resources programmatically. Use tags in the backup plan.
- Overview: AWS Config is a service that provides a detailed inventory of AWS resources and can track changes. It can also identify resources that lack tags. Once resources are identified, AWS Config can trigger automated actions (such as tagging those resources).
- Cost and Operational Efficiency: Using AWS Config to track and tag resources programmatically ensures that all resources, whether tagged or not, are identified. Then, these tags can be used in the AWS Backup plan, allowing the backup process to be automatically applied to the correct resources. This approach minimizes manual intervention and automates resource tagging, streamlining backup management.
- Conclusion: This option offers the least operational overhead as it leverages AWS Config to track resources, uses automation to tag them, and then integrates with AWS Backup to ensure the backup plan targets all necessary resources.
Option B: Use AWS Config to identify all resources that are not running. Add those resources to the backup vault.
- Overview: This option relies on AWS Config to identify resources that are not running and then adds them to the backup vault.
- Cost and Operational Efficiency: This solution is less effective for the given scenario because not all resources that need to be backed up are necessarily "running" at the time. Some resources, like databases or storage volumes, may be in a stopped or idle state but still need to be backed up. Thus, relying on the "not running" condition will not guarantee comprehensive backup coverage.
- Conclusion: This approach introduces unnecessary complexity, and it might miss ke...
Author: Nia · Last updated Jul 12, 2026
A social media company wants to allow its users to upload images in an application that is hosted in the AWS Cloud. The company needs a solution that automatically resizes the images so that the images can be displayed on multiple device types. The application experiences unpredictable traffic patterns throughout the day. The c...
To determine the best solution for the social media company's requirements, we need to evaluate each option based on scalability, availability, cost-effectiveness, and the ability to handle unpredictable traffic patterns efficiently. Let's review each option:
Option A: Create a static website hosted in Amazon S3 that invokes AWS Lambda functions to resize the images and store the images in an Amazon S3 bucket.
- Overview: This solution involves hosting a static website in Amazon S3 and using AWS Lambda functions to resize images before storing them back in an S3 bucket. Lambda can be triggered by events such as an S3 upload.
- Scalability: AWS Lambda scales automatically in response to the number of requests, making it ideal for unpredictable traffic patterns. Since Lambda functions are stateless, they can handle large numbers of requests simultaneously without worrying about server management.
- Availability: Amazon S3 and AWS Lambda are highly available and fault-tolerant by design, ensuring that the solution can scale up or down as needed while minimizing downtime.
- Cost: The cost is based on the number of Lambda executions and the amount of data processed, making it cost-effective, especially for unpredictable traffic.
- Conclusion: This is an optimal solution as it minimizes operational overhead, scales automatically to meet demand, and ensures high availability. It also avoids the complexity of managing servers or containers.
Option B: Create a static website hosted in Amazon CloudFront that invokes AWS Step Functions to resize the images and store the images in an Amazon RDS database.
- Overview: This option involves using Amazon CloudFront for CDN distribution, AWS Step Functions to orchestrate image resizing, and Amazon RDS to store resized images.
- Scalability: While CloudFront provides high availability for distributing content globally, AWS Step Functions and RDS are not ideal for the purpose of image resizing and storage. RDS (a relational database) is typically not used to store images directly. Storing images in RDS would add unnecessary complexity and could be inefficient compared to using Amazon S3.
- Availability: Step Functions and RDS are highly available, but this option introduces unnecessary components (RDS and Step Functions) for an image resizing task.
- Cost: AWS Step Functions can incur higher costs due to its state management overhead, and RDS is more expensive than Amazon S3 for simple object storage tasks.
- Conclusion: This solution is overly complex and not cost-effective for resizing and storing images. RDS is not the right tool for storing images, and Step Functions introduces unnecessary complexity.
Option C: Create a dynamic website hosted on a web server that runs on an Amazon EC2 instance. Configure a process that runs on the EC2 instance to resize the images and store the ...
Author: Zara · Last updated Jul 12, 2026
A company is running a microservices application on Amazon EC2 instances. The company wants to migrate the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster for scalability. The company must configure the Amazon EKS control plane with endpoint private access set to true and endpoint public access set to false to maintain security compliance. The company must also put the data plane...
To solve the issue where the node cannot join the Amazon EKS cluster, we need to understand the requirements and possible causes of the error notifications. The company is running the Amazon EKS control plane with endpoint private access set to true and endpoint public access set to false. Additionally, the data plane is in private subnets. Given this configuration, there are a few key points to address:
1. Private access to the EKS control plane: The EKS control plane is not accessible via the public internet but is available only within the VPC using private endpoints.
2. Nodes in private subnets: The worker nodes (data plane) reside in private subnets and need to access the control plane for Kubernetes API communications.
Now, let’s analyze the options based on these factors:
Option A: Grant the required permission in AWS Identity and Access Management (IAM) to the AmazonEKSNodeRole IAM role.
- Overview: This option suggests granting IAM permissions to the `AmazonEKSNodeRole`. While the node role needs the proper IAM permissions to interact with EKS resources (e.g., for pulling images from Amazon ECR, interacting with the EKS API, and assuming roles), the issue described is more likely related to network access rather than IAM permissions.
- Conclusion: This is unlikely to be the cause of the problem since IAM permissions alone won’t resolve network-related issues that are preventing the nodes from joining the cluster.
Option B: Create interface VPC endpoints to allow nodes to access the control plane.
- Overview: Since the control plane is configured with private endpoint access and public access is disabled, nodes in private subnets must use VPC endpoints to access the control plane. Interface VPC endpoints allow private communication to AWS services like EKS without the need for internet access.
- Network Access: When the EKS control plane endpoint is private, the nodes in the private subnet need to be able to communicate with the control plane over private network paths. By creating VPC interface endpoints for the EKS API (using the service name `com.amazonaws.us-west-2.eks` or similar for your region), you ensure that the nodes can communicate securely with the control plane.
...
Author: Sofia · Last updated Jul 12, 2026
A company is migrating an on-premises application to AWS. The company wants to use Amazon Redshift as a solution.
Which use cases are su...
Amazon Redshift is a powerful data warehousing solution designed for complex analytics workloads that require large-scale data storage, fast querying, and integration with other AWS services. Let’s analyze the options to determine which use cases are suitable for Amazon Redshift.
Option A: Supporting data APIs to access data with traditional, containerized, and event-driven applications
- Overview: Amazon Redshift is primarily used for performing large-scale data analytics and querying rather than providing a real-time data API to be accessed by event-driven or containerized applications.
- Rejection: While Redshift can be accessed by various applications (including containerized ones), it is not primarily designed to support data APIs for real-time application access. Instead, services like Amazon RDS or Amazon DynamoDB are better suited for these real-time, transactional use cases.
- Conclusion: Not a suitable use case for Redshift. It is not designed to support data APIs in real-time for applications.
Option B: Supporting client-side and server-side encryption
- Overview: Amazon Redshift supports both client-side and server-side encryption to protect data at rest and in transit. Server-side encryption can be enabled automatically when creating an Amazon Redshift cluster to ensure data security.
- Rejection: This is more of a feature of Redshift rather than a specific use case. While encryption is critical for securing data, it is not a use case that drives the adoption of Amazon Redshift itself. This is a fundamental security capability that any enterprise data platform would require, not a specific use case that fits the context of migration.
- Conclusion: This is not a valid use case, but rather a feature that exists within the platform. Encryption should always be considered in security-focused applications, but it does not specifically define a suitable scenario for Amazon Redshift.
Option C: Building analytics workloads during specified hours and when the application is not active
- Overview: Amazon Redshift is well-suited for running large-scale analytics workloads, especially for non-real-time use cases such as data warehousing and batch processing. Many organizations use Redshift for analytics during off-hours when application demand is low to optimize cost and performance.
- Rejection: This is a valid use case. Redshift is often used for analytics workloads during off-peak hours to minimize cost, especially when you have large data volumes and want to optimize resource usage.
- Conclusion: This is a suitable use case for Amazon Redshift, as it is designed to handle analytics workloads during non-peak times, leveraging its capabilities to handle large data sets efficiently.
...
Author: Carlos Garcia · Last updated Jul 12, 2026
A company provides an API interface to customers so the customers can retrieve their financial information. =D0=95he company expects a larger number of requests during peak usage times of the year.
The company requires the API to respond consistently with low latency to ensure customer satisfaction. The co...
To evaluate the best solution for meeting the company's requirements with the least operational overhead, we need to consider key factors such as performance, scalability, cost-efficiency, and management effort.
A) Use an Application Load Balancer and Amazon Elastic Container Service (Amazon ECS)
- ECS offers good scalability and container orchestration, but it requires significant setup and management, especially when scaling for peak usage times. You need to manage the underlying EC2 instances or Fargate tasks, which adds operational overhead. Additionally, ECS doesn't offer the same level of automatic scaling and management as serverless options.
- Operational Overhead: High due to manual configuration, monitoring, and scaling of containers.
- When to use: This option could be appropriate if you have specific containerized workloads or microservices that need to be managed closely.
B) Use Amazon API Gateway and AWS Lambda functions with provisioned concurrency
- Provisioned concurrency for Lambda ensures that a specific number of instances of your Lambda function are pre-warmed and available, reducing cold start times and providing consistent performance during peak traffic.
- Operational Overhead: Lower than ECS because you don't need to manage underlying servers or containers. AWS takes care of scaling and availability, and provisioning concurrency can help meet latency requirements.
- When to use: Ideal for a scalable, serverless architecture where you want automatic scaling without needing to manage infrastructure.
C) Use an Application Load Balancer and an Amazon Elastic Kubernetes Service (Amazon EKS) cluster
- EKS requires more effort to set up and manage compared to ECS, especially when scaling for peak loads....
Author: Aarav · Last updated Jul 12, 2026
A company wants to send all AWS Systems Manager Session Manager logs to an Amazon S3 bucket for archival purposes.
Which solution will...
To find the most operationally efficient solution for sending AWS Systems Manager Session Manager logs to an S3 bucket for archival purposes, we need to evaluate each option based on ease of setup, automation, scalability, and ongoing management.
A) Enable S3 logging in the Systems Manager console. Choose an S3 bucket to send the session data to.
- Pros: This is a very straightforward and simple solution. AWS Systems Manager has a built-in feature to directly send session logs to an S3 bucket. This requires minimal configuration and offers direct integration.
- Cons: Limited customization options for log processing. It may not provide as much flexibility for advanced use cases (e.g., filtering, transformation, or additional routing of logs).
- When to use: Ideal for simple log archival scenarios with minimal operational overhead and no need for complex log management.
B) Install the Amazon CloudWatch agent. Push all logs to a CloudWatch log group. Export the logs to an S3 bucket from the group for archival purposes.
- Pros: CloudWatch offers better log management features, such as filtering, searching, and monitoring. You can export logs to S3 for archival.
- Cons: This solution introduces additional complexity, as you need to configure the CloudWatch agent, create log groups, and manage the export process. It also requires more operational effort to maintain the CloudWatch environment.
- When to use: Suitable if you need more granular control over log processing or if you're already using CloudWatch for centralized log management. However, this approach adds more operational overhead compared to the simpler S3 integration.
C) Create a Systems Manager document to upload all server logs to a central S3 bucket. Use Amazon EventBridge to run the Systems Manager document against all servers that are in the account daily.
- Pros...
Author: Sam · Last updated Jul 12, 2026
An application uses an Amazon RDS MySQL DB instance. The RDS database is becoming low on disk space. A solutions architect wants to increase the disk space without downtime.
...
To find the solution that meets the requirement of increasing disk space for an Amazon RDS MySQL DB instance without downtime and with the least amount of effort, let's evaluate each option.
A) Enable storage autoscaling in RDS
- Pros: Enabling storage autoscaling allows RDS to automatically scale the storage size as needed without any manual intervention or downtime. This solution is seamless, as it automatically handles storage increases when the storage reaches predefined thresholds.
- Cons: Storage autoscaling may not immediately provide the desired increase in disk space if the DB instance is very close to full, but this is a rare issue since autoscaling happens dynamically. Additionally, this solution won't address immediate, manual adjustments if a specific increase is required right away.
- When to use: This is ideal for ongoing use cases where storage demands grow over time. It is the least disruptive and requires minimal effort to implement.
B) Increase the RDS database instance size
- Pros: Increasing the instance size can help provide more resources, including CPU and memory, but this does not specifically address disk space directly. It may indirectly impact performance or allow for more efficient use of disk, but it's not a focused solution for increasing disk space.
- Cons: This option does not guarantee an increase in disk space, as it only scales the compute resources. It may cause a brief downtime due to the instance upgrade, and doesn't directly solve storage constraints.
- When to use: This can be used in scenarios where the application needs more compute power in addition to disk space, but not for increasing storage alone.
C) Change the RDS database instance storage type to Provisioned IOPS
- Pros: Provisioned IOPS provides better performance for disk I...
Author: Olivia · Last updated Jul 12, 2026
A consulting company provides professional services to customers worldwide. The company provides solutions and tools for customers to expedite gathering and analyzing data on AWS. The company needs to centrally manage and deploy a common set of soluti...
To determine which solution is the most suitable for centrally managing and deploying a common set of solutions and tools for customers to use for self-service purposes, let's evaluate each option based on its ability to meet the requirements of central management, ease of deployment, self-service functionality, and the overall use case.
A) Create AWS CloudFormation templates for the customers
- Pros: AWS CloudFormation allows for the creation of infrastructure as code, making it easy to define and deploy resources in a repeatable, automated manner. This could enable customers to use pre-defined templates to deploy solutions and tools.
- Cons: CloudFormation templates are more focused on deploying infrastructure resources rather than providing a self-service portal for customers to interact with a suite of solutions. The lack of a dedicated catalog for customer self-service might limit its usefulness in this scenario.
- When to use: This would be suitable if you need to automate the deployment of resources in a specific and controlled manner but not necessarily for a broad set of self-service tools in a managed catalog.
B) Create AWS Service Catalog products for the customers
- Pros: AWS Service Catalog allows you to create and manage catalogs of IT services that are approved for use on AWS. It provides a self-service portal where customers can launch pre-defined solutions, tools, and resources in a controlled environment. Service Catalog is designed specifically for this purpose—central management and self-service deployment of solutions and tools.
- Cons: While AWS Service Catalog is perfect for this use case, it may require some upfront setup, such as creating products and configuring portfolios. However, this is minimal compared to other more complex solutions.
- When to use: This is the ideal option for managing and deploying a common set of solutions and tools to customers, as it provides a centralized, self-service ...
Author: ElectricLionX · Last updated Jul 12, 2026
A company is designing a new web application that will run on Amazon EC2 Instances. The application will use Amazon DynamoDB for backend data storage. The application traffic will be unpredictable. The company expects that the application read and write throughput to the database will be moderate to high. The company ne...
To meet the requirements of a web application with unpredictable traffic, moderate to high read/write throughput, and the need for cost-effective scalability, let's evaluate each option based on scalability, cost, and operational overhead.
A) Configure DynamoDB with provisioned read and write by using the DynamoDB Standard table class. Set DynamoDB auto scaling to a maximum defined capacity.
- Pros: Provisioned mode with auto-scaling allows you to define baseline read and write capacities while enabling scaling to handle unexpected traffic. This configuration offers flexibility and automatic adjustment to traffic needs.
- Cons: Provisioned capacity can be more expensive if the capacity settings are too high to handle the application's unpredictable nature, leading to overprovisioning. If the maximum defined capacity is set too high, this could result in unnecessary costs during periods of low traffic.
- When to use: This is more suitable for applications with predictable workloads or consistent traffic patterns, where specific capacity can be estimated. For unpredictable traffic, this could lead to inefficiency or higher costs.
B) Configure DynamoDB in on-demand mode by using the DynamoDB Standard table class.
- Pros: On-demand mode automatically adjusts to traffic fluctuations and charges only for actual reads and writes. This is ideal for applications with unpredictable traffic, as it removes the need to manually provision capacity. It ensures you don't overpay during low-traffic periods while accommodating spikes in traffic without manual intervention.
- Cons: On-demand pricing can be more expensive for high-volume workloads compared to provisioned capacity with auto-scaling. However, for unpredictable or highly variable workloads, on-demand mode provides a good balance between performance and cost efficiency without requiring manual intervention.
- When to use: This option is highly suitable for applications where traffic is unpredictable, such as new web applications with varying usage patterns, or those experiencing traffic spikes.
C) Configure DynamoDB with provisioned read and write by using the DynamoDB Standard Infrequent Access (DynamoDB ...
Author: Aarav2020 · Last updated Jul 12, 2026
A retail company has several businesses. The IT team for each business manages its own AWS account. Each team account is part of an organization in AWS Organizations. Each team monitors its product inventory levels in an Amazon DynamoDB table in the team's own AWS account.
The company is deploying a central inventory reporting application into a shared AWS accou...
Let's evaluate each option based on the security, ease of implementation, and AWS best practices for this use case.
Option A: Integrate DynamoDB with AWS Secrets Manager
- Explanation: This option suggests storing the DynamoDB credentials in AWS Secrets Manager, and the application will use the secret to authenticate and access the DynamoDB tables.
- Pros: Secrets Manager helps to securely manage credentials and automatically rotate them. It reduces the complexity of managing secrets within your application and reduces the risks of hardcoding secrets in the application.
- Cons: While Secrets Manager is a good option for managing credentials, it is not the most scalable solution for this case because it would require creating a separate secret for each DynamoDB table in each business account. Additionally, manually rotating secrets and managing access control for each secret could become cumbersome as the number of business accounts grows.
- When can it be used?: This option can be used if there are only a few accounts or a minimal amount of data access required.
Option B: Create IAM users in every business account
- Explanation: This option suggests creating IAM users in each business account with programmatic access, then configuring the application to authenticate using the IAM user's access keys.
- Pros: Simple to implement with a straightforward approach. The application would use specific IAM user credentials to access DynamoDB tables.
- Cons: Storing and rotating IAM user credentials is a major security concern. Hardcoding IAM user access keys in the application is insecure and prone to being exposed. It is also not scalable as managing IAM user access keys manually in each account would become very difficult and prone to errors, especially in a larger, more dynamic environment.
- When can it be used?: It is not ideal for scalable or secure environments, especially for a large organization like the retail company described in the scenario.
Option C: Create IAM roles and assume cross-account roles
- Explanation: This option involves c...
Author: Noah · Last updated Jul 12, 2026
A company runs container applications by using Amazon Elastic Kubernetes Service (Amazon EKS). The company's workload is not consistent throughout the day. The company wants Amazon EKS to scale in and out according to the workload.
Whi...
Let's evaluate the options for automating the scaling of the Amazon EKS cluster with the least operational overhead.
Option A: Use an AWS Lambda function to resize the EKS cluster
- Explanation: This option suggests using an AWS Lambda function to resize the EKS cluster.
- Pros: Lambda can be used to automate tasks, but it requires custom logic to trigger the scaling of EKS, which could increase operational overhead. You'd need to manually define when and how to resize the cluster, monitor the workload, and ensure that Lambda is triggered appropriately.
- Cons: This solution introduces significant complexity and requires ongoing management of Lambda functions, custom scaling logic, and error handling. It doesn't take full advantage of native EKS scaling capabilities, making it a more complex solution with higher operational overhead.
- When can it be used?: This can be used for very specific use cases where custom scaling is needed, but it's not ideal for general EKS scaling purposes.
Option B: Use the Kubernetes Metrics Server to activate horizontal pod autoscaling
- Explanation: The Kubernetes Metrics Server collects resource metrics from nodes and pods, enabling Horizontal Pod Autoscaling (HPA).
- Pros: HPA allows the application to automatically scale the number of pods based on resource utilization, such as CPU or memory. This solution is easy to set up and operates with minimal overhead, as it works natively with Kubernetes.
- Cons: HPA handles pod-level scaling but does not scale the underlying worker nodes in the EKS cluster. While this helps scale workloads at the pod level, it does not address the scaling of nodes themselves.
- When can it be used?: This is useful when you need to scale the application (pods) based on metrics but not the underlying cluster nodes. It is a part of the autoscaling process but doesn't solve the entire problem of scaling the entire EKS infrastructure.
Option C: Use the Kubernetes Cluster Autoscaler to manage the number of nodes in the cluster
- Explanation: The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in the EKS cluster based on the resource requirements of the workloads running on the cluster. It increases the number of nodes when pods cannot be scheduled due to resource constraints and scales down when there are idle nodes.
- Pros: This solution integrates well with Amazon EKS and provides seamless node-level sca...
Author: Noah · Last updated Jul 12, 2026
A company runs a microservice-based serverless web application. The application must be able to retrieve data from multiple Amazon DynamoDB tables A solutions architect needs to give the application the ability to retrieve the data with no impact on the baseline perf...
Let's analyze each option based on operational efficiency and how well it aligns with the requirements of allowing a serverless application to retrieve data from multiple Amazon DynamoDB tables without impacting the baseline performance of the application.
Option A: AWS AppSync pipeline resolvers
- Explanation: AWS AppSync is a managed service for building GraphQL APIs. Pipeline resolvers allow you to combine multiple data sources (e.g., multiple DynamoDB tables) in a single request and return the result to the client.
- Pros: AppSync simplifies data retrieval from multiple sources, including DynamoDB. It also allows efficient data fetching through GraphQL queries, reducing overhead by fetching only the necessary data.
- Cons: While AppSync is a good option for combining data from multiple sources, it requires setting up and managing GraphQL resolvers, which adds some complexity. Additionally, it may introduce operational overhead in terms of configuring and maintaining the GraphQL schema and resolvers.
- When can it be used?: This is a good choice for applications already using GraphQL or for applications where fine-grained data control and aggregation from multiple sources are required. It’s an efficient solution but might introduce slightly more operational complexity than other options.
Option B: Amazon CloudFront with Lambda@Edge functions
- Explanation: Amazon CloudFront is a content delivery network (CDN), and Lambda@Edge allows you to run functions at AWS locations globally in response to CloudFront requests. You could potentially use Lambda@Edge to retrieve data from DynamoDB.
- Pros: CloudFront and Lambda@Edge are designed for low-latency global applications, and Lambda@Edge can handle requests near the end user to reduce latency.
- Cons: Lambda@Edge is generally used for optimizing web content delivery, not for directly querying databases like DynamoDB. While it could fetch data from DynamoDB, this setup would not be as straightforward or efficient as other solutions for handling database queries. Also, there’s potential complexity in managing and deploying Lambda@Edge functions.
- When can it be used?: This is an over-engineered solution for querying data from DynamoDB. It is best used for caching content and edge processing, but not ideal for directly interacting with databases in a serverless architecture.
Option C: Edge-optimize...
Author: NightmareDragon2025 · Last updated Jul 12, 2026
A company wants to analyze and troubleshoot Access Denied errors and Unauthorized errors that are related to IAM permissions. The company has AWS CloudTrail turned o...
Let's evaluate each option based on operational efficiency, ease of implementation, and effectiveness for analyzing and troubleshooting IAM-related errors in AWS CloudTrail logs.
Option A: Use AWS Glue and write custom scripts to query CloudTrail logs for the errors
- Explanation: AWS Glue is a managed ETL (Extract, Transform, Load) service that allows you to prepare and transform data. You can use it to query CloudTrail logs, but this would require you to create custom ETL scripts to extract the relevant error information.
- Pros: AWS Glue is powerful for data transformation and complex queries, and can integrate with other AWS services.
- Cons: Writing custom scripts to parse and query CloudTrail logs introduces complexity. Additionally, AWS Glue is not specifically designed for querying logs, so it may require more effort and expertise to set up compared to other services that are more specialized for querying and analysis.
- When can it be used?: This is useful for large-scale data transformation tasks, but it would be an over-complicated solution for this specific need, which focuses on analyzing errors in CloudTrail logs.
Option B: Use AWS Batch and write custom scripts to query CloudTrail logs for the errors
- Explanation: AWS Batch is designed for running batch processing workloads at scale. It would require you to write custom scripts to query CloudTrail logs and identify the errors.
- Pros: AWS Batch is designed for large-scale batch processing.
- Cons: AWS Batch introduces unnecessary complexity for the task of querying CloudTrail logs. Like AWS Glue, this would involve custom scripting, making it less efficient for this use case. It also adds overhead for managing and running batch jobs, which is unnecessary for just analyzing errors.
- When can it be used?: This can be used for large-scale processing jobs, but it is not the right tool for real-time or straightforward log querying in this context.
Option C: Search CloudTrail logs with Amazon Athena queries to identify the errors
- Explanation: Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using SQL. CloudTrail logs are stored in S3, so Athena can be used to dire...
Author: Zara · Last updated Jul 12, 2026
A company wants to add its existing AWS usage cost to its operation cost dashboard. A solutions architect needs to recommend a solution that will give the company access to its usage cost programmatically. The company must be able to access cost data for the current year and fo...
Let's evaluate the options based on ease of access to usage and cost data programmatically, as well as the requirement to forecast costs for the next 12 months with the least operational overhead.
Option A: Access usage cost-related data by using the AWS Cost Explorer API with pagination
- Explanation: The AWS Cost Explorer API provides a programmatic interface to retrieve detailed cost and usage data. It supports both historical usage data and forecasts, which can meet the company’s need for both current year data and forecasts for the next 12 months.
- Pros: The AWS Cost Explorer API is specifically designed for this use case, allowing you to retrieve cost data for any period and access forecasted costs. It’s programmatic, meaning it can easily integrate with the company’s existing cost dashboard with minimal effort. Additionally, it can provide granular insights into usage and forecasts.
- Cons: The primary challenge is the use of pagination to retrieve large datasets, but this is manageable with AWS SDKs that handle pagination automatically.
- When can it be used?: This is ideal when a programmatic, scalable, and efficient solution is needed to pull both historical and forecasted cost data. It fits perfectly for dashboards that need up-to-date data without manual intervention.
Option B: Access usage cost-related data by using downloadable AWS Cost Explorer report .csv files
- Explanation: This solution involves downloading CSV files of usage cost data from AWS Cost Explorer manually or periodically, then integrating that data into the dashboard.
- Pros: This solution is simple to implement if you don't need real-time data access and are okay with manual or scheduled downloads.
- Cons: It does not provide a programmatic interface, meaning there’s more manual effort involved in downloading the data. Additionally, you would need to automate the download process and integrate it with the dashboard manually, increasing operational overhead. It also doesn’t provide real-time data updates or automatic forecasts.
- When can it be used?: This option could work for small-scale scenarios or for teams that don’t need real-time or dynamic access to cost data.
Option C: Configure AWS Budgets actions to send usage cost data to the compan...
Author: Liam · Last updated Jul 12, 2026
A solutions architect is reviewing the resilience of an application. The solutions architect notices that a database administrator recently failed over the application's Amazon Aurora PostgreSQL database writer instance as part of a scaling exercise. The failover resulted in 3 minutes of downt...
Let's analyze each of the options to determine the most suitable solution for reducing downtime during scaling exercises with minimal operational overhead.
Option A: Create more Aurora PostgreSQL read replicas in the cluster to handle the load during failover.
- Pros: Read replicas can help distribute read traffic, but they do not directly reduce the downtime during failover for write operations. While replicas can take some of the load off the primary instance by handling read traffic, during failover, the database must still promote a replica to be the writer, which causes downtime for write operations.
- Cons: Adding replicas helps with read scalability but does not directly address write availability during failover. This would only mitigate the impact on reads, not writes, and would still result in downtime when a failover occurs.
Option B: Set up a secondary Aurora PostgreSQL cluster in the same AWS Region. During failover, update the application to use the secondary cluster's writer endpoint.
- Pros: This setup can provide a secondary database that could be used in the event of a failover. The failover process could switch to the secondary cluster’s writer, potentially minimizing downtime.
- Cons: This setup introduces complexity and operational overhead, as it requires managing a secondary cluster and ensuring that the data is replicated and synchronized across both clusters. Furthermore, the application needs to handle switching between clusters, which increases the complexity and operational burden.
Option C: Create an Amazon ElastiCache for Memcached cluster to handle the load during failover.
- Pros: Amazon ElastiCache can help offload some...
Author: Rohan · Last updated Jul 12, 2026
A company has a regional subscription-based streaming service that runs in a single AWS Region. The architecture consists of web servers and application servers on Amazon EC2 instances. The EC2 instances are in Auto Scaling groups behind Elastic Load Balancers. The architecture includes an Amazon Aurora global database cluster that extends across multiple Availability ...
To achieve the most fault tolerance for a global application, let's analyze the options and select the most suitable one based on the requirements of minimizing downtime and ensuring resilience:
Option A:
Extend the Auto Scaling groups for the web tier and the application tier to deploy instances in Availability Zones in a second Region. Use an Aurora global database to deploy the database in the primary Region and the second Region. Use Amazon Route 53 health checks with a failover routing policy to the second Region.
- Pros: Deploying instances in a second Region with an Aurora global database will help ensure that the application can handle regional failover. Aurora global databases have cross-region replication and automatic failover, making them resilient. Using Route 53 health checks with a failover routing policy ensures that traffic can be redirected to the secondary Region in case of a failure.
- Cons: This setup involves extending Auto Scaling groups to another region, which introduces additional complexity in managing infrastructure across multiple regions. However, it remains a viable solution for high availability across regions.
Option B:
Deploy the web tier and the application tier to a second Region. Add an Aurora PostgreSQL cross-Region Aurora Replica in the second Region. Use Amazon Route 53 health checks with a failover routing policy to the second Region. Promote the secondary to primary as needed.
- Pros: Using a cross-region Aurora replica allows for some redundancy and minimal downtime in case of failure. Route 53 failover routing can redirect traffic to the second Region if necessary.
- Cons: Although promoting the replica to primary in case of failure is possible, this option introduces manual intervention or additional steps to handle failover. It does not provide automatic failover of the database, which increases the risk of prolonged downtime during a failover event.
Option C:
Deploy the web tier and the application tier to a second Region. Create an Aurora PostgreSQL database in the second Region. Use A...
Author: SilverBear · Last updated Jul 12, 2026
A data analytics company wants to migrate its batch processing system to AWS. The company receives thousands of small data files periodically during the day through FTP. An on-premises batch job processes the data files overnight. However, the batch job takes hours to finish running.
The company wants the AWS solution to process incoming data files as soon as possible with minimal changes to the FTP clients that send the files. The solution must delete the incomin...
To identify the best solution for this use case, we need to focus on the following key factors:
- Efficient data storage and retrieval: The solution must handle thousands of incoming small data files.
- Processing speed: Each file needs to be processed in 3-8 minutes.
- Minimal changes to FTP clients: The FTP clients should be minimally impacted by the migration.
- Operational efficiency: The solution should minimize management overhead, such as job scheduling and infrastructure scaling.
- Automatic deletion of processed files: The solution must delete files after successful processing.
Now, let's analyze each option:
Option A:
Use an Amazon EC2 instance that runs an FTP server to store incoming files as objects in Amazon S3 Glacier Flexible Retrieval. Configure a job queue in AWS Batch. Use Amazon EventBridge rules to invoke the job to process the objects nightly from S3 Glacier Flexible Retrieval. Delete the objects after the job has processed the objects.
- Pros: This option uses S3 Glacier Flexible Retrieval, which is cost-effective for long-term storage. However, Glacier is designed for archival storage and retrieval can take minutes to hours, which is not suitable for the requirement to process files in 3-8 minutes.
- Cons: The latency involved in retrieving files from Glacier is far too high for near-instant file processing. This solution would create significant delays that do not meet the requirement of processing the files quickly.
Option B:
Use an Amazon EC2 instance that runs an FTP server to store incoming files on an Amazon Elastic Block Store (Amazon EBS) volume. Configure a job queue in AWS Batch. Use Amazon EventBridge rules to invoke the job to process the files nightly from the EBS volume. Delete the files after the job has processed the files.
- Pros: EBS provides fast and reliable block storage, and AWS Batch can be used for batch processing. However, EBS volumes are not designed for scalable, cost-effective, or easy integration with FTP workflows. This solution requires manual scaling and management of EC2 instances and EBS volumes, leading to operational complexity.
- Cons: Using EC2 with EBS creates overhead for managing the FTP server, scaling, and ensuring high availability. Furthermore, EBS may not be the best fit for handling a large volume of incoming data files in real time because EBS is not built for high-throughput object storage like S3.
Option C:
Use AWS Transfer Family to create an FTP server to store incoming files on an Amazon Elastic Block Store (Amazon EBS) volume. Configure a job queue in AWS Batch. Use an Amazon S3 event notification when each file ...
Author: Noah · Last updated Jul 12, 2026
A company is migrating its workloads to AWS. The company has transactional and sensitive data in its databases. The company wants to use AWS Cloud solutions to increase security and reduce oper...
To identify the most appropriate solution for migrating transactional and sensitive data to AWS while increasing security and reducing operational overhead, let's analyze the options based on the following key factors:
1. Security of data (both at rest and in transit): Ensuring the sensitive data is properly encrypted and protected is critical.
2. Operational overhead: A solution that minimizes manual management and operational burden.
3. Suitability for databases: The solution must be tailored for database use cases, as the company is dealing with transactional and sensitive data.
Option A:
Migrate the databases to Amazon EC2. Use an AWS Key Management Service (AWS KMS) AWS managed key for encryption.
- Pros: EC2 provides full control over the underlying infrastructure and allows encryption of data using AWS KMS. This gives flexibility to the user for custom setups.
- Cons: This option requires significant operational overhead. You must manage the EC2 instances, handle database patches, backups, and high availability. EC2 does not provide the built-in features for databases (like automated backups, scaling, and monitoring) that a managed database service like Amazon RDS offers. Additionally, encryption using KMS, while secure, requires manual configuration and management of encryption keys.
Option B:
Migrate the databases to Amazon RDS. Configure encryption at rest.
- Pros: Amazon RDS is a fully managed relational database service that abstracts away much of the operational overhead associated with database management. It provides built-in encryption at rest (using AWS KMS), and encryption is automatically applied to your data, backups, and snapshots. This meets the requirement for securing transactional and sensitive data. It also offers features like automated backups, patch management, and scaling without needing much manual intervention.
- Cons: There are minimal cons for this solution, as Amazon RDS is a fully managed service, and its encryption at rest is already well-integrated with AWS security features. The main limitation might be if the company requires extreme customization of the database infrastructure, which would be better handled in EC2.
Option C:
Migrate the data to Amazon S3. Use Am...
Author: Emma Brown · Last updated Jul 12, 2026
A company has an online gaming application that has TCP and UDP multiplayer gaming capabilities. The company uses Amazon Route 53 to point the application traffic to multiple Network Load Balancers (NLBs) in different AWS Regions. The company needs to improve application performanc...
To select the most appropriate solution, we need to focus on the following key factors for improving the online gaming application's performance and reducing latency:
1. Latency reduction: The primary goal is to improve the latency for multiplayer gaming, which relies on quick data transmission and real-time responsiveness.
2. Support for TCP and UDP traffic: The solution must handle both TCP and UDP protocols efficiently since the game uses both for multiplayer capabilities.
3. Scalability: The solution should be able to scale easily to handle increasing user growth.
4. Minimal changes: The solution should have minimal impact on the existing architecture and ensure smooth integration.
Option A:
Add an Amazon CloudFront distribution in front of the NLBs. Increase the Cache-Control max-age parameter.
- Pros: Amazon CloudFront is a content delivery network (CDN) that can reduce latency by caching content closer to end users. It is typically effective for static content.
- Cons: CloudFront is optimized for caching HTTP/HTTPS content, which doesn’t apply well to TCP and UDP traffic. Multiplayer gaming uses real-time communication protocols, which can't be effectively cached like static content. Additionally, increasing the Cache-Control max-age parameter would not benefit real-time gaming traffic as the data changes frequently.
Option B:
Replace the NLBs with Application Load Balancers (ALBs). Configure Route 53 to use latency-based routing.
- Pros: ALBs provide layer 7 load balancing and are excellent for HTTP/HTTPS traffic. Latency-based routing in Route 53 can help direct users to the region with the lowest latency.
- Cons: Application Load Balancers only support HTTP and HTTPS protocols and do not handle TCP and UDP traffic. Since multiplayer gaming relies on both TCP and UDP, ALBs are not suitable for thi...
Author: Liam123 · Last updated Jul 12, 2026
A company needs to integrate with a third-party data feed. The data feed sends a webhook to notify an external service when new data is ready for consumption. A developer wrote an AWS Lambda function to retrieve data when the company receives a webhook callback. The developer must make the Lambda fun...
To solve the problem of integrating with the third-party data feed via a webhook, let’s examine each option and evaluate it based on the key factors of operational efficiency, ease of integration, scalability, and simplicity.
Option A: Create a function URL for the Lambda function. Provide the Lambda function URL to the third party for the webhook.
- Analysis: AWS Lambda supports function URLs that can expose your Lambda function over HTTP(S), making it directly callable by the third party. This is a simple and efficient solution where the third party sends the webhook directly to the Lambda function URL. It eliminates the need for additional infrastructure such as load balancers or message queues.
- Why it’s good:
- Operational Efficiency: No additional services or configuration are required beyond enabling the function URL for the Lambda function.
- Scalability: Lambda automatically scales to handle traffic.
- Simplicity: Direct integration via HTTP(S) is straightforward, which reduces complexity.
- Cost-Effective: No additional services (like ALB, SNS, or SQS) incur extra costs.
Option B: Deploy an Application Load Balancer (ALB) in front of the Lambda function. Provide the ALB URL to the third party for the webhook.
- Analysis: An ALB can route HTTP(S) traffic to Lambda functions, but this introduces unnecessary complexity. You would need to manage the ALB and configure it properly to forward requests to the Lambda.
- Why it’s not ideal:
- Operational Overhead: The ALB adds unnecessary layers of configuration and management. Managing the load balancer adds operational overhead that can be avoided.
- Cost: ALB incurs additional costs for usage, which is unnecessary when Lambda has built-in HTTP(S) capabilities via function URLs.
- Complexity: The setup is more complex compared to using a Lambda function URL directly.
Option C: Create an Amazon Simple Notification Service (Amazon SNS) topic. Attach the topic to the Lambda function. Provide the p...
Author: Nathan · Last updated Jul 12, 2026
A company has a workload in an AWS Region. Customers connect to and access the workload by using an Amazon API Gateway REST API. The company uses Amazon Route 53 as its DNS provider. The company wants to provide individual and secure URLs for all customers.
...
To meet the requirements of providing individual and secure URLs for all customers while maintaining operational efficiency, let’s evaluate each of the options based on the factors of scalability, operational simplicity, and security.
Option A: Register the required domain in a registrar. Create a wildcard custom domain name in a Route 53 hosted zone and record in the zone that points to the API Gateway endpoint.
- Analysis: This option suggests using a wildcard domain (e.g., `.company.com`) in Route 53, which can allow customers to access different endpoints with different subdomains (e.g., `customer1.company.com`, `customer2.company.com`, etc.). This can help provide individual URLs for each customer.
- Why it’s good:
- Operational Efficiency: Using a wildcard domain reduces the need for creating multiple DNS records individually for each customer.
- Scalability: The wildcard approach allows for easy addition of new customers without needing to manually create new DNS entries.
- Security: As long as the wildcard SSL certificate is used, the secure connection for each subdomain will be valid.
Option B: Request a wildcard certificate that matches the domains in AWS Certificate Manager (ACM) in a different Region.
- Analysis: Requesting a wildcard certificate in a different region might create some challenges because AWS Certificate Manager (ACM) certificates are region-specific. If the certificate is not in the same region as the API Gateway, the certificate won’t be usable by the API Gateway endpoint.
- Why it’s not ideal:
- Regional Mismatch: The ACM certificate must be in the same region as the API Gateway, so this approach introduces unnecessary complexity and regional constraints.
Option C: Create hosted zones for each customer as required in Route 53. Create zone records that point to the API Gateway endpoint.
- Analysis: Creating individual hosted zones for each customer is not a scalable solution because it would require a separate hosted zone and DNS configuration for each customer.
- Why it’s not ideal:
- Operational Overhead: Managing individual hosted zones for each customer would be cumbersome and difficult to scale as the customer base grows.
- Not Efficient: This me...
Author: Sofia2021 · Last updated Jul 12, 2026
A company stores data in Amazon S3. According to regulations, the data must not contain personally identifiable information (PII). The company recently discovered that S3 buckets have some objects that contain PII. The company needs to automatically detec...
To meet the company's requirements for detecting PII in S3 and notifying the security team, let's evaluate each option based on PII detection capability, automation, notification method, and operational efficiency.
Option A: Use Amazon Macie. Create an Amazon EventBridge rule to filter the SensitiveData event type from Macie findings and to send an Amazon Simple Notification Service (Amazon SNS) notification to the security team.
- Analysis: Amazon Macie is a managed service specifically designed for detecting sensitive data, including PII, in S3 buckets. Macie can analyze and identify PII in S3 objects and generate findings. These findings can then be forwarded via EventBridge, and an SNS notification can be sent to alert the security team.
- Why it’s good:
- PII Detection: Macie is purpose-built for detecting PII and sensitive data, making it ideal for this use case.
- Automation and Notification: Using EventBridge to filter findings and trigger SNS notifications automates the process and ensures timely alerts to the security team.
- Operational Efficiency: Macie continuously monitors S3 for sensitive data, and the integration with EventBridge and SNS streamlines the alerting process.
Option B: Use Amazon GuardDuty. Create an Amazon EventBridge rule to filter the CRITICAL event type from GuardDuty findings and to send an Amazon Simple Notification Service (Amazon SNS) notification to the security team.
- Analysis: GuardDuty is a threat detection service, primarily focused on identifying suspicious activity or security threats (e.g., unusual API calls or potential data exfiltration). While GuardDuty can detect some forms of malicious activity in S3, it is not specifically designed for detecting PII or sensitive data in objects.
- Why it’s not ideal:
- Not Focused on PII Detection: GuardDuty is focused on threat detection, not the identification of PII or sensitive data within S3 buckets.
- Misses the Specific R...
Author: Andrew · Last updated Jul 12, 2026
A company wants to build a logging solution for its multiple AWS accounts. The company currently stores the logs from all accounts in a centralized account. The company has created an Amazon S3 bucket in the centralized account to store the VPC flow logs and AWS CloudTrail logs. All logs must be highly available for 30 days for frequent analysis, retained...
To meet the company's logging requirements — storing logs for 30 days with frequent access, retaining them for an additional 60 days for backup, and deleting them after 90 days — let's evaluate each option based on cost-effectiveness, operational requirements, and data access patterns.
Option A: Transition objects to the S3 Standard storage class 30 days after creation. Write an expiration action that directs Amazon S3 to delete objects after 90 days.
- Analysis: The S3 Standard storage class is designed for frequently accessed data. However, after 30 days, the logs will no longer need to be frequently accessed, and the cost of keeping them in S3 Standard would be unnecessarily high.
- Why it’s not ideal:
- Cost: S3 Standard is more expensive compared to other storage classes like S3 Standard-IA or Glacier when the data is infrequently accessed after the initial 30-day period.
- Operational Requirements: While this approach works for the initial 30 days of frequent access, it doesn't optimize for the subsequent 60 days when the data is less frequently accessed.
Option B: Transition objects to the S3 Standard-Infrequent Access (S3 Standard-IA) storage class 30 days after creation. Move all objects to the S3 Glacier Flexible Retrieval storage class after 90 days. Write an expiration action that directs Amazon S3 to delete objects after 90 days.
- Analysis: The S3 Standard-IA storage class is designed for data that is infrequently accessed but requires rapid retrieval when needed. This transition is more cost-effective for the 30 to 90-day period, as the logs will be accessed infrequently after the initial 30 days.
- After 90 days, moving the objects to S3 Glacier Flexible Retrieval would be suitable since it’s optimized for archival storage at a lower cost.
- Why it’s good:
- Cost-Effective: S3 Standard-IA is cheaper for infrequently accessed data, and S3 Glacier Flexible Retrieval offers low-cost archival storage.
- Optimizes Access Patterns: The transition from S3 Standard-IA to Glacier allows for efficient data storage with the appropriate balance between cost and access speed.
- Expiration: The expiration action after 90 days ensures that data is deleted as required.
Option C...
Author: Sara · Last updated Jul 12, 2026
A company is building an Amazon Elastic Kubernetes Service (Amazon EKS) cluster for its workloads. All secrets that are stored in Amazon EKS must be encrypted in the Kubern...
The requirement is to ensure that secrets in Amazon EKS are encrypted in the Kubernetes etcd key-value store. Let's evaluate each option based on whether it meets the encryption requirement for secrets within EKS.
Option A: Create a new AWS Key Management Service (AWS KMS) key. Use AWS Secrets Manager to manage, rotate, and store all secrets in Amazon EKS.
- Analysis: While AWS Secrets Manager can manage and store secrets and is capable of encryption using KMS, it does not directly address encrypting secrets stored within the etcd key-value store of Kubernetes. Secrets in EKS (such as Kubernetes secrets) are typically stored in the etcd database, and using Secrets Manager for secret management in EKS does not directly encrypt those secrets in etcd.
- Why it’s not ideal: This approach does not fully meet the requirement of encrypting secrets stored in the etcd database of EKS. It focuses on secret management, not the encryption of the etcd store itself.
Option B: Create a new AWS Key Management Service (AWS KMS) key. Enable Amazon EKS KMS secrets encryption on the Amazon EKS cluster.
- Analysis: EKS KMS secrets encryption allows Kubernetes secrets stored in etcd to be encrypted using a customer-managed AWS KMS key. When this option is enabled, it ensures that secrets within the EKS cluster are encrypted before being stored in the Kubernetes etcd key-value store.
- Why it’s ideal: This option directly addresses the requirement by encrypting secrets at the etcd layer using a KMS key. It is the most appropriate and straightforward solution for ensuring that Kubernet...
Author: David · Last updated Jul 12, 2026
A company wants to provide data scientists with near real-time read-only access to the company's production Amazon RDS for PostgreSQL database. The database is currently configured as a Single-AZ database. The data scientists use complex queries that will not affect the production database....
To evaluate which solution is most cost-effective for providing near real-time read-only access to the production Amazon RDS for PostgreSQL database while meeting high availability requirements, let’s analyze each option:
Option A: Scale the existing production database in a maintenance window to provide enough power for the data scientists.
- Pros:
- Increases the database's capacity to handle complex queries.
- Simpler to implement if the goal is to temporarily scale up resources.
- Cons:
- Not highly available. Scaling the database doesn't provide redundancy in case of failure.
- During maintenance windows, scaling may still not meet the data scientists' continuous needs for real-time access.
- This doesn't address the high availability requirement, as the database is still a Single-AZ configuration.
- Conclusion: This option fails to meet the high availability requirement and doesn't offer a suitable real-time solution.
Option B: Change the setup from a Single-AZ to a Multi-AZ instance deployment with a larger secondary standby instance. Provide the data scientists access to the secondary instance.
- Pros:
- A Multi-AZ deployment enhances high availability by maintaining a standby instance.
- Reduces risk of downtime during failover scenarios.
- Providing read-only access to the standby instance ensures that production performance is not affected by complex queries from data scientists.
- Cons:
- Standby instances in a Multi-AZ configuration are primarily designed for failover, not for read-intensive workloads.
- The standby instance is not optimized for read queries, which can lead to performance degradation for the data scientists' complex queries.
- This option could lead to higher costs because the standby instance is not used for scaling the read workload, making it a less efficient use of resources.
- Conclusion: While it meets the high availability requirement, the performance for read-only access would not be optimal, making this option less cost-effective.
O...
Author: Aria · Last updated Jul 12, 2026
A company runs a three-tier web application in the AWS Cloud that operates across three Availability Zones. The application architecture has an Application Load Balancer, an Amazon EC2 web server that hosts user session states, and a MySQL database that runs on an EC2 instance. The company expects sudden increases in application traffic. The company wants to be able to scal...
To meet the requirements of scalability, high availability, and capacity handling for future traffic increases across three Availability Zones, let's review each option:
Option A: Migrate the MySQL database to Amazon RDS for MySQL with a Multi-AZ DB cluster deployment. Use Amazon ElastiCache for Redis with high availability to store session data and to cache reads. Migrate the web server to an Auto Scaling group that is in three Availability Zones.
- Pros:
- Amazon RDS for MySQL with Multi-AZ provides high availability by automatically replicating data across multiple Availability Zones and offers automatic failover, which is essential for high availability.
- Amazon ElastiCache for Redis is a good choice for high-performance caching and session storage. Redis provides low-latency data access and can scale horizontally. Redis also supports persistence and replication for high availability.
- Auto Scaling for the web server allows the application to automatically scale up or down based on demand, ensuring that capacity increases with traffic spikes while maintaining high availability across the three Availability Zones.
- This solution effectively addresses scalability, high availability, and traffic load management across Availability Zones.
- Cons:
- While this is a comprehensive solution, it may incur higher costs due to the Multi-AZ database deployment and the use of ElastiCache for Redis.
- Conclusion: This solution is highly suitable, offering scalability, high availability, and fault tolerance across all three Availability Zones, while also addressing session data management and caching.
Option B: Migrate the MySQL database to Amazon RDS for MySQL with a Multi-AZ DB cluster deployment. Use Amazon ElastiCache for Memcached with high availability to store session data and to cache reads. Migrate the web server to an Auto Scaling group that is in three Availability Zones.
- Pros:
- Amazon RDS for MySQL with Multi-AZ provides high availability as in Option A.
- Amazon ElastiCache for Memcached is another good caching solution that can handle session data and cache reads. It is suitable for distributed cache scenarios where data consistency is less critical than performance.
- Auto Scaling for the web server ensures scalability and availability across the three Availability Zones.
- Cons:
- ElastiCache for Memcached lacks some advanced features like persistence and data replication, which Redis provides. Redis is generally better suited for use cases requiring strong data persistence and fault tolerance, which would be ideal for session management in high availability scenarios.
- Conclusion: While this solution is still viable, ElastiCache for Redis is a better choice than Memcached due to Redis's persistence and better support for fault tolerance, especially in session data scenarios.
Option C: M...
Author: Emma · Last updated Jul 12, 2026
A global video streaming company uses Amazon CloudFront as a content distribution network (CDN). The company wants to roll out content in a phased manner across multiple countries. The company needs to ensure that viewers who are outside the countries to which...
To meet the requirement of rolling out content in a phased manner across multiple countries while ensuring that viewers outside the designated countries cannot access the content, let's evaluate each option:
Option A: Add geographic restrictions to the content in CloudFront by using an allow list. Set up a custom error message.
- Pros:
- Geographic restrictions (allow list) in CloudFront can restrict access based on the viewer's geographic location. This would allow the company to specify which countries are allowed to access the content, effectively preventing users in countries not on the list from viewing the content.
- CloudFront allows you to set a custom error message for users who are denied access due to geographic restrictions, providing a better user experience.
- Cons:
- Geographic restrictions are not fine-grained and can be bypassed using VPNs or other methods. However, this is still a strong solution for phased country rollouts, especially for most legitimate access control needs.
- Conclusion: This solution is directly suited for the requirement of ensuring that only users from allowed countries can access the content. It is straightforward and cost-effective.
Option B: Set up a new URL for restricted content. Authorize access by using a signed URL and cookies. Set up a custom error message.
- Pros:
- Signed URLs and cookies can help control access to specific content, ensuring that only authorized viewers (who have the correct signed URL or cookie) can access the content.
- This could be useful for restricted content based on user authentication or time-limited access.
- Cons:
- While signed URLs can control access based on the user, it doesn’t solve the issue of country-based restrictions. This is more focused on user-specific or time-based access rather than geographic restrictions.
- This solution might be over-engineered for the use case where access ...
Author: Kai · Last updated Jul 12, 2026
A company wants to use the AWS Cloud to improve its on-premises disaster recovery (DR) configuration. The company's core production business application uses Microsoft SQL Server Standard, which runs on a virtual machine (VM). The application has a recovery point objective (RPO) of 30 seconds or fewer and a recovery time...
To select the most appropriate disaster recovery (DR) solution for this company, let’s carefully analyze each option against the specified requirements: recovery point objective (RPO) of 30 seconds or fewer, recovery time objective (RTO) of 60 minutes, and minimizing costs.
Option A: Configure a multi-site active/active setup between the on-premises server and AWS by using Microsoft SQL Server Enterprise with Always On availability groups.
- Pros:
- Always On availability groups provide high availability and disaster recovery for SQL Server, supporting automatic failover in case of failure, which would help meet both RPO and RTO requirements.
- This solution supports near-zero downtime and low RPO (in the range of seconds) due to the continuous synchronization between the on-premises and AWS instances.
- Cons:
- Microsoft SQL Server Enterprise is significantly more expensive than the Standard edition, increasing the overall cost.
- Multi-site active/active setup requires a high degree of complexity, configuration, and ongoing maintenance, which can add to the overall cost and operational overhead.
- The cost of running SQL Server Enterprise and the complexity of maintaining active/active configurations are likely to exceed the need for minimizing costs, especially when the RTO requirement is less stringent.
- Conclusion: This solution is effective but costly and complex for the scenario, making it less desirable for the company’s needs.
Option B: Configure a warm standby Amazon RDS for SQL Server database on AWS. Configure AWS Database Migration Service (AWS DMS) to use change data capture (CDC).
- Pros:
- Warm standby configuration allows you to maintain an RDS instance on AWS that can be quickly scaled up when needed. The standby instance can be kept in sync with the on-premises SQL Server via AWS DMS with change data capture (CDC), which minimizes data transfer delays and supports near real-time replication.
- This setup provides a cost-effective solution compared to an active/active setup since you only pay for the standby instance during a disaster recovery event.
- RPO of 30 seconds can be achieved using CDC, and RTO of 60 minutes is feasible by quickly promoting the RDS instance to full production status.
- Cons:
- While the standby instance is not active all the time, there may still be some delay in failover to RDS, but it can still meet the company’s RTO and RPO requirements given the simplicity of the se...
Author: Carlos Garcia · Last updated Jul 12, 2026
A company has an on-premises server that uses an Oracle database to process and store customer information. The company wants to use an AWS database service to achieve higher availability and to improve application performance. The company also wants to offload reporting fro...
To determine the most operationally efficient solution for the company’s use case, we need to consider the requirements: higher availability, improved application performance, and offloading reporting functions. We also need to evaluate operational efficiency in terms of ease of setup, maintenance, and management.
Option A: Use AWS Database Migration Service (AWS DMS) to create an Amazon RDS DB instance in multiple AWS Regions. Point the reporting functions toward a separate DB instance from the primary DB instance.
- Pros:
- AWS DMS is a managed service that can migrate databases to AWS with minimal downtime. It could be used to replicate the on-premises Oracle database to Amazon RDS.
- Creating a separate DB instance for reporting ensures that the primary database workload is offloaded, improving performance.
- Cons:
- Multiple AWS Regions introduces complexity and potential latency due to cross-region data transfer. This also increases the cost and operational overhead of managing databases in multiple regions.
- The migration of the Oracle database to RDS and managing cross-region replication would require substantial setup and maintenance effort.
- Conclusion: While AWS DMS could facilitate the migration and replication, the complexity of managing databases across multiple AWS regions makes this a less efficient solution compared to other options.
Option B: Use Amazon RDS in a Single-AZ deployment to create an Oracle database. Create a read replica in the same zone as the primary DB instance. Direct the reporting functions to the read replica.
- Pros:
- Read replicas offload read queries from the primary database, improving performance for reporting functions.
- It’s a simple setup in a single Availability Zone (AZ), making it operationally straightforward and cost-effective.
- Cons:
- Single-AZ deployment doesn't meet the requirement for higher availability. If the primary database fails, there is no automatic failover or backup in place, which could lead to downtime.
- This option is not ideal for production environments that require high availability and fault tolerance.
- Conclusion: While this option is simple, it doesn’t meet the requirement for high availability and would be risky in case of AZ failures. It’s suitable for non-production or less critical systems but not for a primary database handling customer information.
Option C: Use Amazon RDS deployed in a Multi-AZ cluster deployment to cre...
Author: BlazingPhoenix22 · Last updated Jul 12, 2026
A company wants to build a web application on AWS. Client access requests to the website are not predictable and can be idle for a long time. Only customers who have paid a subscription fee can have the ability to sign in and use the web appli...
When considering the requirements, the company needs a web application that is cost-effective for unpredictable traffic, and only paying customers should be able to access the site. The solution should be cost-efficient with minimal infrastructure overhead, especially given the potential for long idle periods.
Analysis of Each Option:
1. A) Create an AWS Lambda function to retrieve user information from Amazon DynamoDB. Create an Amazon API Gateway endpoint to accept RESTful APIs. Send the API calls to the Lambda function.
- Why this is a good option: AWS Lambda charges based on the actual execution time and number of requests. Since the web application could have idle periods, using Lambda ensures you are only paying for actual usage, not idle infrastructure. Amazon DynamoDB is a managed NoSQL database that scales easily with demand and is cost-effective for unpredictable usage patterns.
- Why it's selected: This option is highly cost-efficient for unpredictable traffic since Lambda functions scale automatically, and DynamoDB provides a low-cost solution for storing user data.
2. B) Create an Amazon Elastic Container Service (Amazon ECS) service behind an Application Load Balancer to retrieve user information from Amazon RDS. Create an Amazon API Gateway endpoint to accept RESTful APIs. Send the API calls to the Lambda function.
- Why this is less ideal: ECS with an Application Load Balancer is more suited to applications that require a persistent running infrastructure. Since the client's access requests are not predictable, maintaining containers (and the infrastructure associated with them) may lead to unnecessary costs when the application is idle. Amazon RDS, although a managed service, still incurs costs for a persistent database instance.
- Why it's rejected: This setup is less cost-effective because it involves provisioning and maintaining a service (ECS + ALB + RDS), which might incur costs during idle periods. It is more complex and could result in higher overhead than necessary.
3. C) Create an Amazon Cognito user pool to authenticate users.
- Why this is a good option: Amazon Cognito is a service that allows you to manage user authentication and access. It is designed to handle user sign-ups, sign-ins, and access control for web applications. It scales automatically and has low costs based on the number of active users.
- Why it's selected: Since only paying customers should have access, Cognito provides a secure and scalable solution for user authentication, managing the user pool effect...
Author: Isabella1 · Last updated Jul 12, 2026
A media company uses an Amazon CloudFront distribution to deliver content over the internet. The company wants only premium customers to have access to the media streams and file content. The company stores all content in an Amazon S3 bucket. The company also delivers content on demand to...
To meet the requirements for controlling access to media streams and file content for premium customers only, we need a solution that ensures that only authorized users can access the content from the S3 bucket via CloudFront.
Analysis of Each Option:
1. A) Generate and provide S3 signed cookies to premium customers.
- Why this is not ideal: S3 signed cookies are typically used for controlling access to S3 resources directly, but in this scenario, the media content is being delivered via CloudFront, not directly from S3. Using signed cookies in this context would require additional configuration and is not the most effective or common approach for controlling access to CloudFront-distributed content.
- Why it's rejected: This solution would require managing cookies, which adds unnecessary complexity and isn't the best fit for controlling access to CloudFront content specifically. Also, it could cause issues with large-scale management of permissions.
2. B) Generate and provide CloudFront signed URLs to premium customers.
- Why this is a good option: CloudFront signed URLs are designed for controlling access to CloudFront content, and this fits the scenario perfectly. The media company can generate signed URLs that are valid for a limited time or for specific resources. By providing these signed URLs to premium customers, they ensure that only authorized users can access the content. Signed URLs can also be used to deliver specific content (such as movie rentals or music downloads) on-demand, as required.
- Why it's selected: This is the ideal solution because CloudFront signed URLs are designed specifically to control access to CloudFront-distributed content. They are easy to implement, provide granular control over access, and allow for on-demand deliver...
Author: Daniel · Last updated Jul 12, 2026
A company runs Amazon EC2 instances in multiple AWS accounts that are individually bled. The company recently purchased a Savings Pian. Because of changes in the company's business requirements, the company has decommissioned a large number of EC2 instances. The company wants to use its...
In order to use Savings Plan discounts across multiple AWS accounts, the company needs to set up a way to share those savings between the different accounts. Let's examine each option to determine the most appropriate steps.
Analysis of Each Option:
1. A) From the AWS Account Management Console of the management account, turn on discount sharing from the billing preferences section.
- Why this is a good option: Discount sharing must be enabled in the billing preferences section of the account that manages billing (usually the management account of the AWS Organization). This setting allows the Savings Plan discounts to be shared across all linked accounts within the organization.
- Why it's selected: This option is correct because the management account needs to enable discount sharing to ensure the Savings Plan benefits are extended to other AWS accounts within the organization.
2. B) From the AWS Account Management Console of the account that purchased the existing Savings Plan, turn on discount sharing from the billing preferences section. Include all accounts.
- Why this is also a good option: The account that purchased the Savings Plan (which could be the management account or a linked account) must also turn on discount sharing to allow the discounts to be applied to other accounts in the organization. This step makes sure that the existing Savings Plan is shared with all accounts that need to use it.
- Why it's selected: This option is appropriate because the account that holds the Savings Plan (even if it's not the management account) must enable discount sharing to share the discount with other accounts in the organization.
3. C) From the AWS Organizations management account, use AWS Resource Access Manager (AWS RAM) to share the Savings Plan with other accounts.
- Why this is not ideal: AWS Resource Access Manager (RAM) is used for sharing resources such as Amazon VPC subnets, Amazon EC2 instances, or other specific resources between AWS accounts. However, it is not used to share Savings Plans. Savings Plans cannot be shared using AWS RAM.
- Why it's rejected: This option is in...
Author: Emma · Last updated Jul 12, 2026
A retail company uses a regional Amazon API Gateway API for its public REST APIs. The API Gateway endpoint is a custom domain name that points to an Amazon Route 53 alias record. A solutions architect needs to create a solution that has minimal effects on cus...
To release a new version of an API with minimal impact on customers and minimal data loss, the solution needs to balance smooth transition and risk management. Let's evaluate each option based on these criteria.
Analysis of Each Option:
1. A) Create a canary release deployment stage for API Gateway. Deploy the latest API version. Point an appropriate percentage of traffic to the canary stage. After API verification, promote the canary stage to the production stage.
- Why this is a good option: Canary releases allow you to gradually shift traffic to the new version of the API. By directing a small percentage of traffic to the canary stage, you can verify that the new API version works as expected with minimal risk. If any issues arise, only a small portion of users are affected. After verification, the canary stage can be promoted to production. This solution minimizes disruption and data loss, making it ideal for releasing new API versions.
- Why it's selected: This is the best solution because it allows for controlled deployment, minimizes risk, and ensures a smooth transition from the old to the new API version with minimal customer impact.
2. B) Create a new API Gateway endpoint with a new version of the API in OpenAPI YAML file format. Use the import-to-update operation in merge mode into the API in API Gateway. Deploy the new version of the API to the production stage.
- Why this is less ideal: Using the import-to-update operation in merge mode could result in merging configurations and changes that are difficult to control, especially when dealing with breaking changes. This method doesn’t offer the same level of control as a canary deployment. Deploying immediately to the production stage can lead to disruption if there are any issues with the new version.
- Why it's rejected: Although it could be a valid solution for some cases, it lacks the granularity and control of the canary release strategy, potentially affecting all users immediately. Therefore, it is not ideal for minimizing impact and data loss.
3. C) Create a new API Gateway endpoint with a new version of the API in OpenAPI JSON file format. Use the import-to-update op...
Author: Lucas · Last updated Jul 12, 2026
A company wants to direct its users to a backup static error page if the company's primary website is unavailable. The primary website's DNS records are hosted in Amazon Route 53. The domain is pointing to an Application Load Balancer (ALB). The company needs...
To meet the requirement of directing users to a backup static error page if the company's primary website is unavailable, the solution should ensure high availability, minimal infrastructure overhead, and ease of setup. Let’s evaluate each option.
Analysis of Each Option:
1. A) Update the Route 53 records to use a latency routing policy. Add a static error page that is hosted in an Amazon S3 bucket to the records so that the traffic is sent to the most responsive endpoints.
- Why this is not ideal: A latency routing policy is used to direct traffic to the endpoint that provides the lowest latency for the user, typically used for optimizing performance across multiple regions. However, this does not address the need for failover to a static error page when the primary website is unavailable. The latency routing policy isn’t designed for handling failover scenarios where one endpoint is down.
- Why it's rejected: This option doesn’t specifically address the failover requirement. It’s more suited for traffic distribution based on performance metrics (latency) rather than availability.
2. B) Set up a Route 53 active-passive failover configuration. Direct traffic to a static error page that is hosted in an Amazon S3 bucket when Route 53 health checks determine that the ALB endpoint is unhealthy.
- Why this is a good option: In an active-passive failover configuration, Route 53 will route traffic to the primary resource (the ALB in this case) unless the health check detects that it’s unhealthy. If the primary endpoint is unavailable, traffic will automatically be directed to a secondary endpoint, which in this case would be the static error page hosted in an S3 bucket. This approach minimizes infrastructure overhead and requires minimal changes.
- Why it's selected: This option provides the best solution by using Route 53’s built-in health checks and failover mechanism. It ensures that users are routed to the error page when the primary website is down, with minimal changes to the existing infrastructure.
3. C) Set up a Route 53 active-active configuration with the ALB and an Amazon EC2 instance that hosts a static error page as endpoints. Configure Route 53 to send requests to the instance only if the health checks fail for the ALB.
- ...
Author: RadiantPhoenixX · Last updated Jul 12, 2026
A recent analysis of a company's IT expenses highlights the need to reduce backup costs. The company's chief information officer wants to simplify the on-premises backup infrastructure and reduce costs by eliminating the use of physical backup tapes. The company must preserve the ...
To address the company's need to reduce on-premises backup costs while preserving existing investments in on-premises backup applications and workflows, let's analyze each option:
Option A: Set up AWS Storage Gateway to connect with the backup applications using the NFS interface.
- Explanation: The AWS Storage Gateway can be used to integrate on-premises applications with cloud storage. The NFS interface allows for file-based access to AWS cloud storage. However, backup applications typically use a more structured backup process, and the NFS interface may not integrate as smoothly with the backup workflow designed for tape-based operations.
- Why Rejected: NFS interface is not optimized for backup applications that are traditionally tape-based, where the use of a virtual tape library (VTL) interface is typically expected. The workflow for backups to tape may be significantly disrupted, and the transition to a cloud-based NFS solution might not provide the same capabilities needed for seamless backup processing.
Option B: Set up an Amazon EFS file system that connects with the backup applications using the NFS interface.
- Explanation: Amazon EFS (Elastic File System) is a fully managed, scalable file storage service that supports the NFS protocol, making it suitable for file-based workloads. While EFS is highly scalable and provides great integration with Linux-based systems, it doesn't have the features tailored for backup workflows such as the VTL interface.
- Why Rejected: Although Amazon EFS can integrate via NFS, it does not offer the same backup-specific functionality as a virtual tape library. Additionally, backup applications are typically optimized for tape-style operations, and EFS does not offer the kind of direct integration that would preserve the company'...
Author: Suresh · Last updated Jul 12, 2026
A company has data collection sensors at different locations. The data collection sensors stream a high volume of data to the company. The company wants to design a platform on AWS to ingest and process high-volume streaming data. The solution must be scalable and support data collection in near real time. The company ...
To meet the company's requirements of ingesting and processing high-volume streaming data while storing it in Amazon S3 with the least operational overhead, let’s analyze each option:
Option A: Use Amazon Kinesis Data Firehose to deliver streaming data to Amazon S3.
- Explanation: Amazon Kinesis Data Firehose is a fully managed service designed for ingesting real-time streaming data and delivering it to various destinations, including Amazon S3. It automatically scales to handle large data volumes and supports data transformation, buffering, and compression before delivery to S3.
- Why Selected: This option requires the least operational overhead because Kinesis Data Firehose is fully managed and handles the streaming data ingestion and delivery process. There is minimal configuration required, and Kinesis Data Firehose integrates directly with Amazon S3, making it easy to store data for future reporting. It is ideal for high-volume, near-real-time data ingestion.
Option B: Use AWS Glue to deliver streaming data to Amazon S3.
- Explanation: AWS Glue is a managed ETL (extract, transform, load) service. While it can process streaming data via AWS Glue Streaming ETL, it is primarily designed for batch processing and ETL operations rather than real-time data ingestion.
- Why Rejected: Although AWS Glue can handle streaming data, it is more complex to set up and manage compared to Kinesis Data Firehose, and it is designed more for data transformation than for real-time, high-volume ingestion. It also requires more operational effort in managing data pipelines, and the real-time processing capability may not be as seamless as Kinesis Data Firehose for high-volume data streams.
Option C: Use AWS Lambda to deliver streaming data and sto...
Author: Ming88 · Last updated Jul 12, 2026
A company has separate AWS accounts for its finance, data analytics, and development departments. Because of costs and security concerns, the company wants to control which services each AWS account can ...
To meet the company's requirements of controlling which services each AWS account can use, while minimizing operational overhead, let's analyze each option:
Option A: Use AWS Systems Manager templates to control which AWS services each department can use.
- Explanation: AWS Systems Manager is typically used for managing resources at scale, automating tasks, and maintaining configurations. Systems Manager templates, like those in State Manager or Automation, can help automate tasks but are not ideal for controlling which services can be accessed across multiple AWS accounts.
- Why Rejected: Systems Manager is not designed to control or restrict access to AWS services at the account level. It is more for managing and maintaining resources or configurations, not for enforcing security or service-level access controls.
Option B: Create organization units (OUs) for each department in AWS Organizations. Attach service control policies (SCPs) to the OUs.
- Explanation: AWS Organizations is designed for managing multiple AWS accounts. By creating organizational units (OUs) for each department, you can apply service control policies (SCPs) to control what services and actions are allowed or denied in each account. SCPs allow for centralized control of access to AWS services across accounts, which fits the requirement perfectly.
- Why Selected: This solution offers the least operational overhead. AWS Organizations with SCPs provides a centralized way to manage access to AWS services for multiple accounts. SCPs are easy to implement, scalable, and designed specifically for this type of requirement. They allow the company to define policies at the OU level and apply them to the accounts, ensuring that only specific services are available to each department, with minimal ongoing management.
Option C: Use AWS CloudFormation to automatically provision only the AWS services that each department can use.
- Explanation: AWS CloudFormation is an Infrastructure as Code (IaC) service used to provis...
