Amazon Practice Questions, Discussions & Exam Topics by our Authors
A data engineer maintains custom Python scripts that perform a data formatting process that many AWS Lambda functions use. When the data engineer needs to modify the Python scripts, the data engineer must manually update all the Lambda functions.The data...
To determine which solution best meets the requirement of updating multiple AWS Lambda functions with minimal manual intervention, let's analyze each option based on factors like ease of maintenance, scalability, and automation.
Option A: Store the custom Python scripts in a shared Amazon S3 bucket. Store a pointer to the custom scripts in the execution context object.
- Pros: Storing scripts in Amazon S3 is cost-effective and centralized. It allows updating the scripts in one location and referencing them dynamically within the Lambda functions.
- Cons: Using the execution context object to store the pointer is not ideal, as the context object is typically tied to individual invocations of the function and not meant for persistent script storage. The pointer will be limited to the invocation lifecycle, and updating it requires frequent code changes.
- Use case: This approach may be useful if the Lambda functions fetch scripts dynamically from S3. However, relying on the execution context for this pointer doesn’t offer an efficient, scalable solution for maintenance.
Option B: Package the custom Python scripts into Lambda layers. Apply the Lambda layers to the Lambda functions.
- Pros: Lambda Layers are a great way to share code across multiple Lambda functions. By using Lambda layers, you can centralize the management of custom scripts. Updating the layer automatically reflects in all Lambda functions that use that layer, reducing manual intervention.
- Cons: Requires versioning of Lambda layers, but the overhead is minimal compared to manually updating each Lambda function.
- Use case: This is the most efficient and scalable solution for reusing code across multiple Lambda functions, especially for shared custom scripts like those written in Python. It is ideal for your scenario, as you want to modify the scripts centrally and have the changes reflected in all functions without manually updating each one.
Opt...
Author: Amira · Last updated Jul 30, 2026
A company stores customer data in an Amazon S3 bucket. Multiple teams in the company want to use the customer data for downstream analysis. The company needs to ensure that the teams do not have access to personally identifiable informati...
Let's evaluate each option based on the requirement to ensure that teams do not have access to personally identifiable information (PII) while minimizing operational overhead:
A) Use Amazon Macie to create and run a sensitive data discovery job to detect and remove PII.
- Rejected: Amazon Macie is a great service for discovering and classifying PII in Amazon S3. However, Macie primarily focuses on detection rather than active removal or filtering of PII during data access. While it can be used to discover and alert on PII, the operational overhead of implementing it alongside other services for data access and modification is higher than other options. It doesn't provide an easy way to automatically modify or prevent access to PII once detected.
B) Use S3 Object Lambda to access the data, and use Amazon Comprehend to detect and remove PII.
- Selected: This option allows you to use S3 Object Lambda, which can dynamically modify the data as it's accessed. You can use Amazon Comprehend to detect and remove PII from the data on-the-fly as it is retrieved by downstream teams. This solution ensures that no PII is exposed to the teams, and it is highly scalable with minimal operational overhead, as it automatically processes data without requiring manual intervention. This solution meets the requirement for handling sensitive data with low overhead by processing data only when accessed.
C) Use Amazon Data Firehose and Amazon Comprehend to detect and remove PII.
- Rejected: Amazon Kinesis Data Firehose is primarily used for real-time streaming data processing and delivery to destinations such as ...
Author: Andrew · Last updated Jul 30, 2026
A company stores its processed data in an S3 bucket. The company has a strict data access policy. The company uses IAM roles to grant teams within the company different levels of access to the S3 bucket.The company wants to receive notifications when a user violates the data access policy....
Let's analyze each option to determine the best solution for tracking data access violations and including the username of the violator in the notifications:
A) Use AWS Config rules to detect violations of the data access policy. Set up compliance alarms.
- Rejected: AWS Config is typically used for assessing, auditing, and evaluating configurations of AWS resources to ensure compliance with best practices or internal policies. It doesn't directly track individual actions or events like S3 access attempts. AWS Config would not capture specific access violations to an S3 bucket or provide detailed information about the user violating the policy. Thus, it is not well-suited for this use case, where specific user actions are required.
B) Use Amazon CloudWatch metrics to gather object-level metrics. Set up CloudWatch alarms.
- Rejected: Amazon CloudWatch metrics generally track aggregated data at the service or resource level, such as CPU usage, request count, or error rates. It doesn't natively support tracking object-level access violations or user-specific actions on S3. Additionally, it cannot capture the username of a specific user violating the policy, which is a critical requirement for this use case.
C) Use AWS CloudTrail to track object-level events for the S3 bucket. Forward events to Amazon CloudWatch to set up CloudWatch alarms.
- Selected: AWS CloudTrail is the most appropriate solution. CloudTrail records all API requests made to AWS services, including S3. By enabling object-level logging for S3, CloudTrail will log events such as `GetObject`, `PutObject`, and other S3 actions, along with the associated IAM...
Author: Nia · Last updated Jul 30, 2026
A company needs to load customer data that comes from a third party into an Amazon Redshift data warehouse. The company stores order data and product data in the same data warehouse. The company wants to use the combined dataset to identify potential new customers.A data engineer notices that one of the fields in the source...
Let's evaluate each option to determine the best approach for loading JSON data into Amazon Redshift with the least effort:
A) Use the SUPER data type to store the data in the Amazon Redshift table.
- Selected: The `SUPER` data type in Amazon Redshift is specifically designed for semi-structured data, such as JSON. Using this data type, you can directly load JSON data into Redshift tables without needing to flatten the data beforehand. This method allows Redshift to store and query JSON data in its native format, making it easy to perform complex queries on the data later using Redshift's `Redshift Spectrum` or `SQL` queries. This option minimizes the need for data transformations or complex ETL processes, reducing operational overhead while maintaining query flexibility. Additionally, this approach integrates seamlessly with Redshift's capabilities.
B) Use AWS Glue to flatten the JSON data and ingest it into the Amazon Redshift table.
- Rejected: While AWS Glue is a powerful ETL tool that can flatten JSON data and load it into Redshift, this approach involves more operational overhead compared to using the `SUPER` data type. Flattening JSON data with Glue requires configuring a Glue job, and the data must be transformed into a tabular format, which may not be necessary if the goal is to simply store and query the JSON data in its original structure. This approach would be useful if complex transformations were required, but it adds unnecessary complexity for this scenario.
C) Use Amazon S3 to store the JSON data. Use Amazon Athena to query the data.
- Rejected: This option suggests storing the JSON data in S3 and querying it with Athena, which ...
Author: SilverBear · Last updated Jul 30, 2026
A company wants to analyze sales records that the company stores in a MySQL database. The company wants to correlate the records with sales opportunities identified by Salesforce.The company receives 2 GB of sales records every day. The company has 100 GB of identified sales opportunities. A data engineer needs to develop a process that will analyze and correlate...
To meet the requirements of analyzing and correlating sales records from a MySQL database and Salesforce, we need to consider the scale of the data, the frequency of the process (once per night), and the level of operational overhead that each solution introduces. Let's evaluate each option.
Option A: Use Amazon Managed Workflows for Apache Airflow (Amazon MWAA) to fetch both datasets. Use AWS Lambda functions to correlate the datasets. Use AWS Step Functions to orchestrate the process.
- Pros: Apache Airflow is a powerful workflow orchestration service that can be used to automate ETL tasks. AWS Lambda functions are lightweight and flexible, and AWS Step Functions can handle orchestration and error management.
- Cons: Using Lambda functions for data correlation can be cumbersome, especially given the amount of data (2 GB of sales records per day). AWS Lambda has memory and time limits, which may require additional configurations or splitting of the data into smaller chunks, increasing the complexity. Also, Apache Airflow introduces management overhead.
- Use case: This option might be viable for smaller-scale, less complex workflows. However, for a recurring nightly process dealing with data from two sources, it introduces too much complexity and may not scale well with large datasets, especially with Lambda limitations.
Option B: Use Amazon AppFlow to fetch sales opportunities from Salesforce. Use AWS Glue to fetch sales records from the MySQL database. Correlate the sales records with the sales opportunities. Use Amazon Managed Workflows for Apache Airflow (Amazon MWAA) to orchestrate the process.
- Pros: Amazon AppFlow simplifies integration with Salesforce, allowing easy data transfer to AWS. AWS Glue can fetch and process data from MySQL, and Apache Airflow provides workflow orchestration. This setup would allow seamless integration of data and correlation.
- Cons: Similar to Option A, using Apache Airflow for orchestration and adding AWS Glue for the extraction process introduces overhead in terms of setup, configuration, and ongoing management. While this solution is scalable, it might be over-engineered for the task and could introduce unnecessary complexity.
- Use case: While it addresses integration and correlation effectively, the overhead of using Apache Airflow and AWS Glue might not be justified for this specific use case.
Option C: Use Amazon AppFlow to fetch sales opportunities from Sales...
Author: Aarav2020 · Last updated Jul 30, 2026
A company stores server logs in an Amazon S3 bucket. The company needs to keep the logs for 1 year. The logs are not required after 1 year.A data engineer needs a solution to automatically delete logs that are older...
To determine the best solution with the least operational overhead, let's evaluate each option based on key factors like automation, simplicity, and operational efficiency:
A) Define an S3 Lifecycle configuration to delete the logs after 1 year
- Why it's a good option: Amazon S3 Lifecycle configurations provide an automated, fully managed solution to expire objects after a set period (e.g., 1 year). You don’t need to manage servers or code, making it a highly efficient option in terms of both operational overhead and automation.
- Key factors: Simple to implement, fully automated, and managed by AWS with no additional infrastructure required.
- Why other options are rejected: This solution is very straightforward and requires no manual intervention after the setup. It scales well without requiring additional resources.
B) Create an AWS Lambda function to delete the logs after 1 year
- Why it's a bad option: While Lambda can be used to delete objects, it requires additional setup and ongoing management. The Lambda function would need to be triggered on a schedule, either by an AWS CloudWatch event or by invoking the function periodically. This adds more complexity compared to the S3 Lifecycle approach.
- Key factors: Involves writing and maintaining custom code, scheduling CloudWatch events, and monitoring Lambda executions. It introduces more complexity than necessary, which increases operational overhead.
- Why other options are rejected: It’s more complex than the S3 Lifecycle option and can incur costs depending on the number of invocations.
C) Schedule a cron job on an Amazon EC2 instance to delete the...
Author: Ava · Last updated Jul 30, 2026
A company is designing a serverless data processing workflow in AWS Step Functions that involves multiple steps. The processing workflow ingests data from an external API, transforms the data by using multiple AWS Lambda functions, and loads the transformed data into Amazon DynamoDB.The company needs the workflow to perfor...
In this case, the company needs to design a workflow that involves conditional steps based on the content of the incoming data. Let's evaluate the options to determine which is the best fit:
A) Parallel
- Advantages:
- Parallel execution: The Parallel state can run multiple branches of steps simultaneously, which is useful when you want to perform independent operations concurrently.
- Disadvantages:
- Not conditional: The Parallel state does not allow for decision-making based on data. It's designed for parallelism and not for branching based on content.
- Use case: Useful for running independent tasks concurrently but does not fit when you need branching logic based on input data.
- Why this is not ideal: Since the company needs the workflow to perform specific steps based on incoming data (conditional logic), the Parallel state does not meet the requirement of conditional branching.
B) Choice
- Advantages:
- Conditional branching: The Choice state allows for branching based on the content of the data. It’s ideal for making decisions in the workflow and directing the execution path based on conditions.
- Flexible: You can define different conditions based on the data (e.g., values, expressions, or paths), making it a perfect fit when you need to perform specific steps depending on the incoming data.
- Why this is ideal: The Choice state is specifically designed for the scenario where the workflow must take different paths depending on conditions within the incoming data. This matches the requirement for conditional logic based on data content.
C) Task
- Advantages:
- Execution of tasks: The Task state is used to invoke a service or function, such as calling AW...
Author: Benjamin · Last updated Jul 30, 2026
A company has an Amazon Redshift data warehouse that users access by using a variety of IAM roles. More than 100 users access the data warehouse every day.The company wants to control user access to the objects based on each user'...
To control user access based on job roles, permissions, and the sensitivity of the data, let’s evaluate each of the options available for Amazon Redshift:
A) Use the role-based access control (RBAC) feature of Amazon Redshift
- Advantages:
- Role-based management: RBAC allows you to assign users to specific IAM roles that define their access to various resources in Amazon Redshift. It’s a common method for managing access in a multi-user environment.
- Granular control: You can define different permissions at the database level, schema level, and even the object level (tables, views) based on the user's job role.
- Scalability: With more than 100 users, managing access through RBAC is scalable because it’s based on assigning roles rather than managing individual user permissions.
- Why this is ideal: RBAC is the most straightforward solution for managing user access based on job roles and responsibilities. It allows you to control access efficiently by grouping users into roles and assigning permissions to those roles. This will work well for the company's needs of controlling access based on job roles and permissions.
B) Use the row-level security (RLS) feature of Amazon Redshift
- Advantages:
- Data filtering: RLS allows you to filter the data returned to users based on their specific attributes, such as department, region, or any other field that determines what data they should see. This helps secure sensitive data by ensuring that users only see rows relevant to them.
- Disadvantages:
- Not the primary solution for role management: While RLS is great for filtering data based on specific user attributes, it does not help with managing access to objects themselves, like tables or schemas. It focuses on controlling access to the data within a table.
- Limited role management: It’s not designed to handle permissions based on roles or job responsibilities, which is a broader aspect of managing user access.
- Why this is not ideal: While RLS can be useful for filtering data based on user attributes, it doesn't address the broader concern of controlling access to objects in Redshift (e.g., tables, schemas) based on user roles. RBAC provides more comprehensive control for this use case.
C) Use the column-level security (CLS) feature of Amazon Redshift
- Advantages:
- Fine-grained ...
Author: IceDragon2023 · Last updated Jul 30, 2026
A company uses Amazon DataZone as a data governance and business catalog solution. The company stores data in an Amazon S3 data lake. The company uses AWS Glue with an AWS Glue Data Catalog.A data engineer needs to publish AWS...
To determine the best option for publishing AWS Glue Data Quality scores to the Amazon DataZone portal, let's analyze each option carefully.
Option A:
- Create a data quality ruleset with Data Quality Definition language (DQDL) rules that apply to a specific AWS Glue table.
- Schedule the ruleset to run daily.
- Configure the Amazon DataZone project to have an Amazon Redshift data source.
- Enable the data quality configuration for the data source.
Reasoning:
- The solution proposes creating DQDL rules for AWS Glue tables, which is a valid approach to defining data quality rules.
- However, the data source in the Amazon DataZone project is specified as Amazon Redshift, not AWS Glue. This would mean that the data quality scores from AWS Glue would not be directly available to the DataZone portal through the Redshift configuration.
Why rejected:
- The mismatch between the data source (Amazon Redshift) and AWS Glue makes this solution unsuitable.
Option B:
- Configure AWS Glue ETL jobs to use an Evaluate Data Quality transform.
- Define a data quality ruleset inside the jobs.
- Configure the Amazon DataZone project to have an AWS Glue data source.
- Enable the data quality configuration for the data source.
Reasoning:
- Using the Evaluate Data Quality transform within AWS Glue ETL jobs allows data quality checks to be performed within the ETL process.
- Defining the data quality ruleset within the Glue job and configuring Amazon DataZone with an AWS Glue data source aligns well with the goal of integrating data quality metrics into DataZone.
Why rejected:
- This option is plausible and practical because AWS Glue integrates directly with DataZone through the AWS Glue data source. However, using ETL jobs to apply the data quality rules might not be the most efficient method compared to having a more centralized data quality process with DQDL rules.
Option C:
- Create a data quality ruleset with Data Quality Definition language (DQ...
Author: Aarav · Last updated Jul 30, 2026
A company has a data warehouse in Amazon Redshift. To comply with security regulations, the company needs to log and store all user activities and connection activit...
To determine the best solution for logging and storing all user and connection activities for an Amazon Redshift data warehouse, let's analyze each option:
Option A:
- Create an Amazon S3 bucket. Enable logging for the Amazon Redshift cluster. Specify the S3 bucket in the logging configuration to store the logs.
Reasoning:
- Amazon S3 is a highly scalable and cost-effective storage solution. Amazon Redshift supports storing audit logs in an S3 bucket, which makes this a natural and efficient option.
- Redshift can be configured to store logs (including user and connection activity logs) in an S3 bucket by enabling the logging feature.
- Logs stored in S3 are easy to manage, can be retained for compliance purposes, and can be queried or analyzed later.
- S3 is a suitable option because it is durable and designed for large-scale data storage.
Why selected:
- This solution is ideal as it is fully supported by Redshift and provides a cost-effective, scalable, and reliable method for storing logs.
- It also complies with security regulations by allowing the logs to be securely stored in S3, where they can be retained for as long as necessary.
Option B:
- Create an Amazon Elastic File System (Amazon EFS) file system. Enable logging for the Amazon Redshift cluster. Write logs to the EFS file system.
Reasoning:
- Amazon EFS is a scalable file storage solution, but it is not a native or optimal choice for Redshift logs.
- EFS provides shared file storage that can be mounted by multiple EC2 instances, but it is generally used for different types of workloads that require file system access rather than logging.
- Storing logs in EFS could lead to unnecessary complexity and higher cost compared to Amazon S3, as EFS is more suitable for file systems accessed by EC2 instances and not for simple log storage.
Why rejected:
- Amazon S3 is a more appropriate and cost-efficient storage solution f...
Author: Emily · Last updated Jul 30, 2026
A company wants to migrate a data warehouse from Teradata to Amazon Redshift.Which solution will meet this ...
To determine the best solution for migrating a data warehouse from Teradata to Amazon Redshift with the least operational effort, let's evaluate each option.
Option A:
- Use AWS Database Migration Service (AWS DMS) Schema Conversion to migrate the schema. Use AWS DMS to migrate the data.
Reasoning:
- AWS DMS (Database Migration Service) supports migrating data between different databases, including Teradata to Amazon Redshift. However, AWS DMS does not directly handle schema conversion for a complex source database like Teradata.
- Schema conversion, especially for complex databases like Teradata, requires more specialized tools for mapping the schema, transforming objects, and ensuring compatibility between the source and target databases.
- While AWS DMS can migrate the data, it cannot fully convert the schema, which is a significant part of the migration process.
Why rejected:
- AWS DMS alone will not be sufficient to handle the schema conversion, particularly for complex data warehouses like Teradata. Additional steps or tools would still be necessary.
Option B:
- Use the AWS Schema Conversion Tool (AWS SCT) to migrate the schema. Use AWS Database Migration Service (AWS DMS) to migrate the data.
Reasoning:
- AWS SCT is a powerful tool designed specifically for schema conversion. It can analyze the Teradata schema and convert it into a format compatible with Amazon Redshift, making it ideal for handling the complex schema migration from Teradata.
- After using SCT for schema conversion, AWS DMS can be used to efficiently migrate the actual data from Teradata to Redshift. DMS supports incremental data replication, ensuring minimal downtime during the migration.
- This approach minimizes the operational effort by automating the schema conversion and data migration processes with specialized tools.
Why selected:
- This solution is the most efficient because it uses AWS SCT for schema conversion, which is specifically built for this purpose, and AWS DMS for data migration, which is designed to move large datasets efficiently.
- This solution p...
Author: David · Last updated Jul 30, 2026
A company uses a variety of AWS and third-party data stores. The company wants to consolidate all the data into a central data warehouse to perform analytics. Users need fast response times for analytics queries.The company uses Amazon QuickSight in direct query mode to visualize the data. Users normally run querie...
To determine the best solution for consolidating data into a central data warehouse with fast response times for analytics queries and minimal operational overhead, let's evaluate each option:
Option A:
- Use Amazon Redshift Serverless to load all the data into Amazon Redshift managed storage (RMS).
Reasoning:
- Amazon Redshift Serverless is designed to automatically scale based on demand, which is perfect for handling unpredictable spikes in query activity.
- It simplifies the operational overhead by automatically managing resources like compute and storage, so you don’t need to worry about provisioning or managing clusters.
- Redshift Serverless can be used in direct query mode with Amazon QuickSight, making it easy for users to run analytics queries on the consolidated data.
- Managed storage (RMS) in Redshift is designed to provide fast and efficient querying, so response times are typically good for analytics workloads.
Why selected:
- Redshift Serverless is the most suitable option for this scenario because it provides elasticity to handle unpredictable spikes in query volume without needing manual intervention. It also minimizes the operational overhead by automatically scaling and managing resources.
- This option offers fast response times and integrates smoothly with Amazon QuickSight.
Option B:
- Use Amazon Athena to load all the data into Amazon S3 in Apache Parquet format.
Reasoning:
- Amazon Athena allows users to query data directly in Amazon S3, typically using serverless querying. However, it is not designed to function as a central data warehouse, especially when dealing with large-scale, complex analytics workloads.
- While Athena is good for querying large datasets in S3, it may not provide the same query performance as a fully managed data warehouse like Redshift for high-performance analytics.
- Athena is also more focused on ad hoc querying, so it may not be the best option when fast response times for complex analytics queries are required, particularly during periods of heavy usage.
Why rejected:
- Athena is not designed to be used as a centralized data warehouse for sustained high-performance analytics, and it may not meet the requirements for fast response times during unpredictable spikes in query load. Using ...
Author: Mia · Last updated Jul 30, 2026
A company is planning to create a service that requires encryption in transit. The traffic must not be decrypted between the client and the backend of the service. The company will implement the service by using the gRPC protocol over TCP port 443. The service will scale up to thousands of simultaneous connections. The backend of the service will be hosted on an Amazon Elastic Kubernetes Service (Amazon EKS) duster with the Kubernetes Cluster Autosc...
To determine the appropriate solution, let's break down the requirements and evaluate each option based on key factors such as encryption in transit, mutual TLS (mTLS), backend scalability, and Kubernetes service management.
Key Requirements:
1. Encryption in transit: Traffic must remain encrypted end-to-end, with no decryption between the client and the backend.
2. Mutual TLS (mTLS) authentication: Both the client and backend need to authenticate each other using mTLS.
3. Scalability: The backend service needs to scale automatically with the Kubernetes Cluster Autoscaler and Horizontal Pod Autoscaler.
4. TCP traffic on port 443: The service is gRPC-based, which typically uses HTTP/2 and requires TCP-based communication over port 443.
Evaluation of the options:
A) Install the AWS Load Balancer Controller for Kubernetes. Using that controller, configure a Network Load Balancer with a TCP listener on port 443 to forward traffic to the IP addresses of the backend service Pods.
- Why it works: The Network Load Balancer (NLB) operates at the transport layer (Layer 4), which means it will forward raw TCP traffic without modifying it. This is crucial for gRPC-based services, as they require raw TCP to function correctly. Since the service uses mutual TLS (mTLS), the encryption will not be decrypted between the client and the backend; it stays encrypted across the connection, fulfilling the encryption in transit requirement.
- Scalability: NLB automatically scales and integrates well with Kubernetes and the Cluster Autoscaler.
- Why it is preferred: The key advantage here is that the NLB does not decrypt traffic, making it ideal for scenarios where encryption in transit is paramount. The TCP listener ensures that the gRPC protocol is supported.
B) Install the AWS Load Balancer Controller for Kubernetes. Using that controller, configure an Application Load Balancer with an HTTPS listener on port 443 to forward traffic to the IP addresses of the backend service Pods.
- Why it doesn’t work: The Application Load Balancer (ALB) operates at the HTTP/HTTPS layer (Layer 7), and although it supports HTTPS, it would decrypt th...
Author: Oliver · Last updated Jul 24, 2026
A company is deploying a new application in the AWS Cloud. The company wants a highly available web server that will sit behind an Elastic Load Balancer. The load balancer will route requests to multiple target groups based on the URL in the request. All traffic must use HTTPS. TLS processing must be offloaded to the load balancer. The web se...
Key Requirements:
1. Highly available web server: The application needs to be highly available, meaning it should be able to handle failures in one or more components without downtime.
2. Elastic Load Balancer: Traffic must be routed to multiple target groups based on the request.
3. HTTPS traffic: All traffic must use HTTPS, and TLS processing must be offloaded to the load balancer.
4. Preserving the user's IP address: The web server must be able to read the client's IP address in order to keep accurate security logs.
Evaluation of the options:
A) Deploy an Application Load Balancer with an HTTPS listener. Use path-based routing rules to forward the traffic to the correct target group. Include the X-Forwarded-For request header with traffic to the targets.
- Why it works:
- HTTPS traffic: An Application Load Balancer (ALB) with an HTTPS listener is a suitable choice for handling HTTPS traffic, as TLS offloading can be done at the ALB.
- Routing: Path-based routing can be used effectively with the ALB to forward traffic to different target groups based on the URL path.
- X-Forwarded-For header: The ALB automatically includes the `X-Forwarded-For` header, which contains the original client IP address. This allows the backend web server to retrieve the user's IP address, even though the ALB terminates the TLS connection.
- Why it is preferred:
- TLS offloading: Since the TLS connection is terminated at the ALB, the backend does not need to handle encryption.
- Preserving IP address: The `X-Forwarded-For` header includes the user's IP address, which meets the requirement of logging accurate client information.
B) Deploy an Application Load Balancer with an HTTPS listener for each domain. Use host-based routing rules to forward the traffic to the correct target group for each domain. Include the X-Forwarded-For request header with traffic to the targets.
- Why it works:
- HTTPS traffic: The ALB supports TLS offloading, so HTTPS traffic is supported.
- Routing: Host-based routing can be used to forward traffic to the correct target group for each domain.
- X-Forwarded-For header: Like Option A, the ALB will forward the original client IP address in the `X-Forwarded-For` header.
- Why it might be overcomplicated:
- While host-based routing is a valid option, it may be more complex than path-based routing if there are fewer domains involved. For a single application with multiple paths, path-based routing would be simpler to implement than creating separate listeners for each domain.
- Why rejected:
- Extra complexity: This option is only necessary if multiple domains need to be handled. For a simpler setup, Option A...
Author: Ethan · Last updated Jul 24, 2026
A company has developed an application on AWS that will track inventory levels of vending machines and initiate the restocking process automatically. The company plans to integrate this application with vending machines and deploy the vending machines in several markets around the world. The application resides in a VPC in the us-east-1 Region. The application consists of an Amazon Elastic Container Service (Amazon ECS) cluster behind an Application Load Balancer (ALB). The communication from the vending machines to the application happens over HTTPS.
The company is planning to use an AWS Global Accelerator accelerator and configure sta...
Key Requirements:
1. Application accessibility: The application must only be accessible via the AWS Global Accelerator, not directly through the internet or the ALB's public endpoint.
2. Security: The ALB must only accept traffic from the Global Accelerator, not from the internet at large.
3. Global access: The application is deployed in the us-east-1 region, but it should be accessible globally using static IP addresses from the AWS Global Accelerator.
4. VPC configuration: The ALB needs to be properly configured within the VPC and secured using security groups.
Evaluation of the options:
A) Configure the ALB in a private subnet of the VPC. Attach an internet gateway without adding routes in the subnet route tables to point to the internet gateway. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB's security group to only allow inbound traffic from the internet on the ALB listener port.
- Why this doesn’t work:
- Internet gateway: The presence of an internet gateway but without routes to it is contradictory. The internet gateway allows internet access, but since there are no routes to it, no traffic would actually flow through the internet gateway, making the internet gateway configuration useless.
- Security group misconfiguration: The ALB security group is configured to allow inbound traffic from the internet, which would open the ALB to unwanted access. This violates the requirement to restrict access only to traffic from the Global Accelerator.
- Why rejected: The internet gateway setup is incorrect, and the ALB's security group is too permissive.
B) Configure the ALB in a private subnet of the VPC. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB's security group to only allow inbound traffic from the internet on the ALB listener port.
- Why this doesn’t work:
- Security group misconfiguration: The ALB's security group is still allowing inbound traffic from the internet, which contradicts the requirement that the application should only be accessible via the Global Accelerator.
- Why rejected: The ALB security group is misconfigured by allowing unrestricted access from the internet.
C) Configure the ALB in a public subnet of the VPC. Attach an internet gateway. Add routes in the subnet route tables to point to the internet gateway. Configure the acc...
Author: Henry · Last updated Jul 24, 2026
A global delivery company is modernizing its fleet management system. The company has several business units. Each business unit designs and maintains applications that are hosted in its own AWS account in separate application VPCs in the same AWS Region. Each business unit's applications are designed to get data from a central shared services VPC.
The company wants the network connectivity architecture to provide granular security controls. The arc...
Key Requirements:
1. Granular security controls: The company needs a network architecture that enables fine-grained security controls over the connections between VPCs.
2. Scalability: As more business units are added, the solution must scale without major rework.
3. Central shared services VPC: All applications across different business units need to access data from a central shared services VPC.
4. Isolation between VPCs: Each business unit's application VPC needs to be isolated, with the ability to control which VPCs can communicate with each other and with the central shared services VPC.
Evaluation of Options:
A) Create a central transit gateway. Create a VPC attachment to each application VPC. Provide full mesh connectivity between all the VPCs by using the transit gateway.
- Why it works:
- Centralized management: A transit gateway is designed to connect multiple VPCs in a scalable manner. It allows VPCs to communicate with each other via a central hub.
- Granular security: Security can be controlled through route tables and access control lists (ACLs) for the transit gateway. You can specify which VPCs can communicate with which others.
- Scalability: This solution scales well as more business units are added. New VPCs can be connected to the transit gateway without complex reconfiguration.
- Why it is preferred:
- The transit gateway simplifies the network architecture by centralizing routing between VPCs.
- Granular security controls can be implemented through the transit gateway’s route tables, allowing for very specific control over which VPCs can access the shared services VPC and which others can connect.
- This solution also minimizes the number of connections compared to VPC peering, as you only need to manage a few attachments (one for each VPC) rather than a potentially large number of peerings.
- Best use case: This solution is ideal for managing communication between many VPCs, offering scalability, and centralized control over the network.
B) Create VPC peering connections between the central shared services VPC and each application VPC in each business unit's AWS account.
- Why it doesn’t work:
- Scaling issues: VPC peering becomes difficult to manage as the number of VPCs increases. You would need to create and manage a separate peering connection for each pair of VPCs (central shared services VPC with each application VPC), which would result in a full mesh of peering connections as the number of VPCs grows.
- Limited security controls: With VPC peering, you have limited control over routing, and fine-grained security between VPCs is harder to enforce. It’s more difficult to isolate traffic between different business units while allowing communication with the shared services VPC.
- Why rejected:
- Limited scalability: As more business units are added, the number of VPC peer...
Author: Ethan · Last updated Jul 24, 2026
A company uses a 4 Gbps AWS Direct Connect dedicated connection with a link aggregation group (LAG) bundle to connect to five VPCs that are deployed in the us-east-1 Region. Each VPC serves a different business unit and uses its own private VIF for connectivity to the on-premises environment. Users are reporting slowness when they access resources that are hosted on AWS.
A network engineer finds that there are sudden increases in throughput and that the Direct Connect connection becomes saturated at the same time for about an hour each business day....
Key Requirements:
1. Identifying the business unit causing slowness: The company needs to determine which business unit (via VPC) is causing the sudden increase in throughput and saturation of the Direct Connect link.
2. Resolve the slowness: Once the culprit VPC is identified, the company wants to implement a solution that will resolve the throughput saturation and improve performance.
Evaluation of the Options:
A) Review the Amazon CloudWatch metrics for VirtualInterfaceBpsEgress and VirtualInterfaceBpsIngress to determine which VIF is sending the highest throughput during the period in which slowness is observed. Create a new 10 Gbps dedicated connection. Shift traffic from the existing dedicated connection to the new dedicated connection.
- Why it works:
- CloudWatch metrics: Monitoring the `VirtualInterfaceBpsEgress` and `VirtualInterfaceBpsIngress` metrics for each private virtual interface (VIF) will help identify which VIF is generating the highest throughput and causing saturation during the identified time periods.
- Solution: If one business unit (via VPC) is determined to be the cause of the issue, adding a new 10 Gbps dedicated connection would allow the company to offload some traffic, helping to alleviate the congestion.
- Why it’s rejected:
- Overkill: Adding a new 10 Gbps dedicated connection may not be necessary unless there is a significant and persistent increase in traffic. This option would be more beneficial if the bandwidth of the current connection is insufficient for the overall throughput needs, which isn’t directly proven yet.
- Cost and Complexity: Setting up a new 10 Gbps dedicated connection may be expensive and might introduce unnecessary complexity if a simpler solution could resolve the issue.
B) Review the Amazon CloudWatch metrics for VirtualInterfaceBpsEgress and VirtualInterfaceBpsIngress to determine which VIF is sending the highest throughput during the period in which slowness is observed. Upgrade the bandwidth of the existing dedicated connection to 10 Gbps.
- Why it works:
- CloudWatch metrics: Again, monitoring the `VirtualInterfaceBpsEgress` and `VirtualInterfaceBpsIngress` metrics can help identify which VIF is causing the traffic spikes.
- Upgrade solution: Upgrading the bandwidth of the existing dedicated connection to 10 Gbps would potentially resolve the congestion if the throughput requirements are high.
- Why it’s a good option:
- Targeted upgrade: Upgrading the existing connection to 10 Gbps would be a more efficient solution than creating a new connection, assuming the current connection is close to its throughput limit and the need for more bandwidth is confirmed.
- Cost-effective: It avoids the need for a completely new dedicated connection while addressing the performance issue by increasing the capacity of the existing connection.
- Why it might still be overkill:
- Bandwidth upgrade may not be necessary: If the root cause is occasional spikes rather than sustained high throughput, the problem might be better handled by identifying the traffic pa...
Author: Harper · Last updated Jul 24, 2026
A software-as-a-service (SaaS) provider hosts its solution on Amazon EC2 instances within a VPC in the AWS Cloud. All of the provider's customers also have their environments in the AWS Cloud.
A recent design meeting revealed that the customers have IP address overlap with the provider's AWS deployment. The customers have stated that they will not share their internal IP addresses and that th...
To address the problem of IP address overlap between the provider’s and customers’ VPCs in AWS while ensuring that the customers do not connect over the internet, the solution must focus on private network connectivity and avoiding conflicts with internal IPs. The steps must also be secure and scalable for a Software-as-a-Service (SaaS) provider hosting on AWS. Let's break down each option:
A) Deploy the SaaS service endpoint behind a Network Load Balancer.
- Explanation: A Network Load Balancer (NLB) operates at the network layer (Layer 4) and supports handling TCP traffic efficiently. However, using an NLB doesn’t directly address the requirement to handle IP address overlap and private connections between the SaaS provider and customers. It could facilitate load balancing, but it doesn't solve the issue of overlapping IPs or private connectivity.
- Rejection: The NLB is useful for traffic distribution but does not solve the main issue of private, secure connectivity without IP conflicts.
B) Configure an endpoint service, and grant the customers permission to create a connection to the endpoint service.
- Explanation: AWS PrivateLink allows you to create a private connection between VPCs without traversing the public internet. By configuring an endpoint service, the SaaS provider can expose their service through a private link, and customers can connect to it through an endpoint in their own VPC. This solution allows secure, private access without requiring IP address sharing or conflicts.
- Selected Option: This is a viable solution since it provides private connectivity between VPCs without any need for routing over the internet and without exposing internal IPs.
C) Deploy the SaaS service endpoint behind an Application Load Balancer.
- Explanation: An Application Load Balancer (ALB) operates at Layer 7 and is designed to handle HTTP/HTTPS traffic with more complex routing capabilities. While it could be used to distribute traffic to the SaaS service, it doesn’t directl...
Author: Noah Williams · Last updated Jul 24, 2026
A network engineer is designing the architecture for a healthcare company's workload that is moving to the AWS Cloud. All data to and from the on-premises environment must be encrypted in transit. All traffic also must be inspected in the cloud before the traffic is allowed to leave the cloud and travel to the on-premises environment or to the internet.
The company will expose components of the workload to the internet so that patients can reserve appointments. The architecture must secure these components and protect them against DDoS attacks. The arch...
To meet the security and performance requirements for a healthcare company's workload migrating to the AWS Cloud, the network engineer must design a solution that ensures encryption in transit, traffic inspection, protection from DDoS attacks, and secure exposure of workload components to the internet. Let’s analyze each option:
A) Use Traffic Mirroring to copy all traffic to a fleet of traffic capture appliances.
- Explanation: Traffic Mirroring allows you to capture and inspect network traffic in real-time. While this could be useful for monitoring traffic and detecting security threats, it doesn't directly address the requirement of inspecting traffic before it leaves the cloud or protect the infrastructure from DDoS attacks.
- Rejection: Traffic Mirroring is more suited for monitoring and analysis rather than for inline traffic inspection and protection. It does not provide security controls to enforce rules on the traffic itself or mitigate DDoS attacks.
B) Set up AWS WAF on all network components.
- Explanation: AWS Web Application Firewall (WAF) helps protect web applications by filtering and monitoring HTTP(S) requests. It can block common attack patterns such as SQL injection, cross-site scripting (XSS), and also provide rate limiting for DDoS mitigation. This would be especially useful for securing the exposed components of the workload that patients will interact with, such as reservation systems.
- Selected Option: AWS WAF is a critical component for protecting web-facing components and ensuring that malicious traffic is blocked before it reaches the application layer. This aligns with the need to secure the public-facing endpoints.
C) Configure an AWS Lambda function to create Deny rules in security groups to block malicious IP addresses.
- Explanation: While it’s possible to use AWS Lambda to automate actions based on security group rules, this approach would be reactive and not as effective in preventing attacks like DDoS in real-time. AWS security services like WAF and Shield are more appropriate for automatically mitigating threats at scale.
- Rejection: This is an overcomplicated and indirect method for blocking malicious IPs. AWS offers more specialize...
Author: Aria · Last updated Jul 24, 2026
A retail company is running its service on AWS. The company's architecture includes Application Load Balancers (ALBs) in public subnets. The ALB target groups are configured to send traffic to backend Amazon EC2 instances in private subnets. These backend EC2 instances can call externally hosted services over the internet by using a NAT gateway.
The company has noticed in its billing that NAT gateway usage has increased significan...
The task is to investigate the source of increased NAT gateway usage in the retail company's AWS environment. The network engineer needs to identify which sources are using the NAT gateway and potentially causing increased usage. Let's go over each option:
A) Enable VPC flow logs on the NAT gateway's elastic network interface. Publish the logs to a log group in Amazon CloudWatch Logs. Use CloudWatch Logs Insights to query and analyze the logs.
- Explanation: VPC flow logs capture information about IP traffic going to and from network interfaces in your VPC, including the NAT gateway's elastic network interface. By enabling flow logs for the NAT gateway's interface and publishing them to CloudWatch Logs, you can track which EC2 instances are initiating traffic that goes through the NAT gateway. Using CloudWatch Logs Insights, you can query and analyze the logs to identify patterns or sources of increased usage.
- Selected Option: This is a strong approach because VPC flow logs provide detailed information about the traffic patterns and can be analyzed for trends and anomalies that contribute to the increased NAT gateway usage.
B) Enable NAT gateway access logs. Publish the logs to a log group in Amazon CloudWatch Logs. Use CloudWatch Logs Insights to query and analyze the logs.
- Explanation: NAT gateway access logs provide information about the traffic that is processed by the NAT gateway. However, these logs primarily focus on the source and destination of the traffic and the amount of traffic. While this helps in seeing the amount of traffic that the NAT gateway is handling, it does not provide as detailed an analysis of the specific EC2 instances generating that traffic compared to VPC flow logs.
- Rejection: NAT gateway access logs focus on overall traffic processed by the NAT gateway, but they don't provide as granular visibility into the source of the traffic (i.e., which EC2 instances are generating the traffic), making them less useful than VPC flow logs in this scenario.
C) Configure Traffic Mirroring on the NAT gateway's elastic network interface. Send the traffic to an additional EC2 instance. Use tools such as tcpdump and Wireshark to query and analyze the mirrored traffic.
- Explanation: Traffic Mirroring allows capturing and analyzing network traffic at ...
Author: Sophia · Last updated Jul 24, 2026
A banking company is successfully operating its public mobile banking stack on AWS. The mobile banking stack is deployed in a VPC that includes private subnets and public subnets. The company is using IPv4 networking and has not deployed or supported IPv6 in the environment. The company has decided to adopt a third-party service provider's API and must integrate the API with the existing environment. The service provider's API requires the use of IPv6.
A network engineer must turn on IPv6 connectivity for the existing workload that is deployed in a private subnet. The company does ...
The banking company needs to enable IPv6 connectivity for its existing workload deployed in private subnets. The requirements state that:
1. IPv6 connectivity must be supported for integration with the third-party API.
2. The company does not want to permit IPv6 traffic from the public internet.
3. All IPv6 connectivity must be initiated by the company’s servers, meaning it should be outbound-only for IPv6.
Given these requirements, let's analyze the options:
A) Create an internet gateway and a NAT gateway in the VPC. Add a route to the existing subnet route tables to point IPv6 traffic to the NAT gateway.
- Explanation: This solution introduces an internet gateway, which is designed for internet-bound traffic. However, the company’s requirement specifies no IPv6 traffic from the public internet, so using an internet gateway would conflict with that requirement. Additionally, the NAT gateway is typically used to handle IPv4 traffic.
- Rejection: This solution would allow IPv6 traffic to the public internet, which violates the company's constraint of not permitting public IPv6 traffic.
B) Create an internet gateway and a NAT instance in the VPC. Add a route to the existing subnet route tables to point IPv6 traffic to the NAT instance.
- Explanation: Like option A, this option includes an internet gateway, which would allow traffic to/from the public internet, conflicting with the company’s requirement. The use of a NAT instance is less scalable and harder to manage compared to a NAT gateway, and still doesn’t meet the requirement to block public IPv6 traffic.
- Rejection: Again, the internet gateway would allow unwanted IPv6 traffic from...
Author: Harper · Last updated Jul 24, 2026
A company has deployed an AWS Network Firewall firewall into a VPC. A network engineer needs to implement a solution to deliver Network Firewall flow logs to the company's Amazon OpenSearch Service (Amazon Elasticsearch...
The requirement is to deliver AWS Network Firewall flow logs to an Amazon OpenSearch Service (formerly Amazon Elasticsearch Service) cluster with minimal delay. Let's analyze each option and explain the reasoning behind the selected choice:
A) Create an Amazon S3 bucket. Create an AWS Lambda function to load logs into the Amazon OpenSearch Service (Amazon Elasticsearch Service) cluster. Enable Amazon Simple Notification Service (Amazon SNS) notifications on the S3 bucket to invoke the Lambda function. Configure flow logs for the firewall. Set the S3 bucket as the destination.
- Explanation: This solution involves using an S3 bucket as an intermediate storage location for the flow logs, with a Lambda function triggered by SNS notifications to load the logs into OpenSearch. Although this solution works, there is inherent latency involved because the logs are first written to S3, and the Lambda function must process and load them into OpenSearch. This adds delay compared to a direct delivery mechanism.
- Rejection: While it is a valid approach, it introduces additional latency (storing logs in S3, invoking Lambda, and loading into OpenSearch) which is not ideal for this use case where low latency is required.
B) Create an Amazon Kinesis Data Firehose delivery stream that includes the Amazon OpenSearch Service (Amazon Elasticsearch Service) cluster as the destination. Configure flow logs for the firewall. Set the Kinesis Data Firehose delivery stream as the destination for the Network Firewall flow logs.
- Explanation: This solution involves setting up Kinesis Data Firehose as a delivery stream, which can directly stream the logs into Amazon OpenSearch Service. Kinesis Data Firehose provides a managed and low-latency solution for streaming logs to OpenSearch, ensuring that logs are delivered in real time or near real time with minimal delay.
- Selected Opt...
Author: IronLion88 · Last updated Jul 24, 2026
A company is using custom DNS servers that run BIND for name resolution in its VPCs. The VPCs are deployed across multiple AWS accounts that are part of the same organization in AWS Organizations. All the VPCs are connected to a transit gateway. The BIND servers are running in a central VPC and are configured to forward all queries for an on-premises DNS domain to DNS servers that are hosted in an on-premises data center. To ensure that all the VPCs use the custom DNS servers, a network engineer has configured a VPC DHCP options set in all the VPCs that specifies the custom DNS servers to be used as domain name servers.
Multiple development teams in the company want to use Amazon Elastic File System (Amazon EFS). A development team has created a new EFS file system but cannot mount the file system to one of its Amazon EC2 inst...
Let's break down each option in the context of the problem.
Context and Goal:
The issue is that the EC2 instance cannot resolve the domain name for the EFS mount point. The VPCs are using custom DNS servers (via BIND) for name resolution, but the EC2 instance cannot resolve the DNS name for Amazon EFS.
Option A: Configure the BIND DNS servers in the central VPC to forward queries for efs.us-east-1.amazonaws.com to the Amazon provided DNS server (169.254.169.253).
- Explanation: This option suggests configuring BIND servers to forward queries for Amazon EFS to the Amazon DNS server. Since EFS requires Amazon DNS resolution for its service endpoints, configuring the DNS servers in the central VPC to forward queries to the Amazon DNS server can help the instances resolve EFS-specific names.
- Why it's selected: The Amazon DNS server (169.254.169.253) is responsible for resolving service names like `efs.us-east-1.amazonaws.com`, which is needed to mount the EFS file system. This ensures that the EC2 instances can resolve the necessary Amazon EFS DNS names.
- Why other options are rejected: This solution doesn't disrupt the use of custom DNS servers and leverages existing BIND forwarding.
Option B: Create an Amazon Route 53 Resolver outbound endpoint in the central VPC. Update all the VPC DHCP options sets to use AmazonProvidedDNS for name resolution.
- Explanation: This option involves using Route 53 Resolver outbound endpoints to forward DNS queries for AWS resources to the Amazon DNS server. This ensures that AWS services like EFS can be resolved without disrupting existing DNS infrastructure.
- Why it's selected: This option would also solve the issue of DNS resolution for EFS and other AWS services, as the Resolver outbound endpoint would forward requests to AmazonProvidedDNS for services like EFS.
- Why other options are rejected: While this approach works, Option A directly addresses the specific issue of resolving EFS endpoints by forwarding queries to the Amazon DNS server. Option B could be an alternative but adds complexity by introducing a Resolver outbound endpoint when forwarding queries directly from BIND is simpler.
...
Author: Amira · Last updated Jul 24, 2026
An ecommerce company is hosting a web application on Amazon EC2 instances to handle continuously changing customer demand. The EC2 instances are part of an Auto Scaling group. The company wants to implement a solution to distribute traffic from customers to the EC2 instances. The company must encrypt all traffic at all stages bet...
Let's break down each option in the context of the given requirements: distribute traffic, encrypt all traffic at all stages, and no decryption at intermediate points.
Requirements Recap:
- Distribute traffic: A solution is needed to distribute traffic to EC2 instances, possibly in an Auto Scaling group.
- Encrypt all traffic: Traffic must be encrypted from the customer to the application servers and remain encrypted during transit, with no decryption at intermediate points.
Option A: Create an Application Load Balancer (ALB). Add an HTTPS listener to the ALB. Configure the Auto Scaling group to register instances with the ALB's target group.
- Explanation: ALB supports HTTP and HTTPS listeners. When configured with an HTTPS listener, ALB terminates SSL/TLS at the load balancer, decrypting traffic before forwarding it to the backend instances.
- Why it's rejected: Although ALB supports HTTPS, ALB decrypts the traffic at the load balancer before forwarding it to the EC2 instances. Since the requirement is for no decryption at intermediate points, this option is not suitable. Traffic will be decrypted at the ALB, violating the requirement.
Option B: Create an Amazon CloudFront distribution. Configure the distribution with a custom SSL/TLS certificate. Set the Auto Scaling group as the distribution's origin.
- Explanation: CloudFront is a content delivery network (CDN) that supports HTTPS. By configuring CloudFront with a custom SSL/TLS certificate, the entire traffic can be encrypted from the client to CloudFront and from CloudFront to the EC2 instances.
- Why it’s selected: CloudFront can encrypt traffic between the client and CloudFront, and if configured correctly, the traffic can remain encrypted as it is passed to the Auto Scaling group. No intermediate dec...
Author: Michael · Last updated Jul 24, 2026
A company has two on-premises data center locations. There is a company-managed router at each data center. Each data center has a dedicated AWS Direct Connect connection to a Direct Connect gateway through a private virtual interface. The router for the first location is advertising 110 routes to the Direct Connect gateway by using BGP, and the router for the second location is advertising 60 routes to the Direct Connect gateway by using BGP. The Direct Connect gateway is attached to a company VPC through a virtual private gateway.
A network engineer receives reports that resources in the VPC are not reachable from various locations in either data center. The network eng...
Scenario Overview:
The network engineer is experiencing an issue where resources in the VPC are not reachable from the two on-premises data centers. The VPC route table is not populated with routes from the first data center. The Direct Connect gateway is used to connect the on-premises routers to the VPC, but the routes from one of the data centers (first data center) are not appearing in the VPC route table.
Key Details:
- Two on-premises data centers: Each connected to AWS via Direct Connect.
- BGP Advertising: The first data center is advertising 110 routes, and the second is advertising 60.
- VPC Route Table: Routes from the first data center are not appearing in the route table, suggesting a possible issue with route propagation or limits on the number of routes.
Let's analyze each option:
Option A: Remove the Direct Connect gateway, and create a new private virtual interface from each company router to the virtual private gateway of the VPC.
- Explanation: This option suggests removing the Direct Connect gateway and directly creating a private virtual interface between each router and the VPC's virtual private gateway.
- Why it’s rejected: This approach would be inconvenient and disruptive as it involves significant reconfiguration, including changes to existing Direct Connect connections. It does not directly address the issue of missing routes in the VPC route table. The problem likely lies in the BGP route propagation, which could be resolved without needing to reconfigure the Direct Connect gateway or the virtual private interface.
Option B: Change the router configurations to summarize the advertised routes.
- Explanation: This option suggests configuring the routers to summarize the routes being advertised via BGP. By summarizing routes, fewer routes would be advertised to AWS, potentially preventing exceeding any AWS BGP route limits.
- Why it’s selected: Route limits are often a common issue when multiple routes are advertised via BGP. AWS imposes a limit on the number of r...
Author: Kai99 · Last updated Jul 24, 2026
A company has expanded its network to the AWS Cloud by using a hybrid architecture with multiple AWS accounts. The company has set up a shared AWS account for the connection to its on-premises data centers and the company offices. The workloads consist of private web-based services for internal use. These services run in different AWS accounts. Office-based employees consume these services by using a DNS name in an on-premises DNS zone that is named example.internal.
The process to register a new service that runs on AWS requires a manual and complicated change request to the internal DNS. The process involves many teams.
The company wants to update the DNS registration process by giving the service creators access that will allow them ...
To meet the company's goal of allowing service creators to register their DNS records with minimal configuration changes and maximize cost-effectiveness, the network engineer should implement a solution that simplifies the DNS management process across multiple AWS accounts and integrates it smoothly with the on-premises DNS infrastructure. The goal is to provide a self-service DNS registration mechanism without requiring manual intervention for each new service.
Key Factors:
- The solution must automate the DNS registration process for AWS-hosted services.
- It must be cost-effective with the least possible configuration complexity.
- It should enable service creators to manage DNS records without needing to go through the internal DNS change request process.
- Integration with on-premises DNS is required because the employees access services using DNS names in the `example.internal` zone.
Let's analyze each option:
Option A: Create a record for each service in its local private hosted zone (serviceA.account1.aws.example.internal). Provide this DNS record to the employees who need access.
- Explanation: This would involve creating a separate DNS record for each service in its own private hosted zone. The records would then be provided to employees.
- Why it's rejected: This option would work if employees were directly accessing the private hosted zones, but it would still require coordination to make the DNS records accessible across multiple AWS accounts and to integrate with the on-premises DNS. It doesn't automate the registration process and is not scalable for the company’s goal.
Option B: Create an Amazon Route 53 Resolver inbound endpoint in the shared account VPC. Create a conditional forwarder for a domain named aws.example.internal on the on-premises DNS servers. Set the forwarding IP addresses to the inbound endpoint's IP addresses that were created.
- Explanation: This option involves setting up a Route 53 Resolver inbound endpoint to forward DNS queries for `aws.example.internal` to the shared account’s VPC and then using conditional forwarding on the on-premises DNS servers.
- Why it's selected: This solution centralizes DNS management in the shared AWS account and allows DNS queries for `aws.example.internal` to be forwarded to the shared account’s Route 53 Resolver, which can then resolve names for services running in different AWS accounts. This solution is efficient, provides seamless integration, and centralizes DNS resolution for internal services.
- Why other options are rejected: This approach addresses both the integration with the on-premises DNS and the need to manage AWS DNS records without requiring manual intervention. It automates DNS resolution for internal services and reduces complexity.
Option C: Create an Amazon Route 53 Resolver rule to forward any queries made to onprem.example.internal to the on-premises DNS servers.
- Explanation: This option sets up a Route 53 Resolver rule to forward queries for `onprem.example.internal` to on-premises DNS servers.
- Why it's rejected: While this option could help in resolving DNS for on-premises services, it does not directly address the issue of allow...
Author: Chloe · Last updated Jul 24, 2026
A company has multiple AWS accounts. Each account contains one or more VPCs. A new security guideline requires the inspection of all traffic between VPCs.
The company has deployed a transit gateway that provides connectivity between all VPCs. The company also has deployed a shared services VPC with Amazon EC2 instances that include IDS services for stateful inspection. The EC2 instances are deployed across three Availability Zones. The company has set up VPC associations and routing on the transit gateway. The company has migrated a few test VPCs to th...
In this scenario, the company has deployed a transit gateway to provide connectivity between multiple VPCs, and the traffic must be inspected by EC2 instances running IDS services in a shared services VPC. The issue reported is intermittent connections for traffic crossing Availability Zones. The goal is to determine how to resolve the intermittent connectivity issues.
Let's analyze each option:
Option A: Modify the transit gateway VPC attachment on the shared services VPC by enabling cross-Availability Zone load balancing.
- Explanation: Cross-AZ load balancing allows traffic to be distributed across multiple Availability Zones when traffic is being forwarded to services like EC2 instances. This option helps with ensuring that traffic is efficiently balanced across the EC2 instances deployed in multiple Availability Zones.
- Why it's selected: Since the EC2 instances are deployed across three Availability Zones, enabling cross-AZ load balancing ensures that traffic is properly distributed across all EC2 instances, potentially improving the reliability of traffic flow. It addresses the intermittent connectivity issue when traffic crosses Availability Zones by enabling proper load distribution.
Option B: Modify the transit gateway VPC attachment on the shared services VPC by enabling appliance mode support.
- Explanation: Appliance mode is a feature in the transit gateway that is specifically designed for use cases where network appliances, like firewalls or IDS/IPS systems, are deployed to inspect traffic. It ensures that traffic sent to a network appliance does not pass through the transit gateway’s route table lookup and instead is forwarded directly to the appliance.
- Why it's rejected: Appliance mode is not necessary for this case, as the EC2 instances performing the IDS inspection are already deployed in the shared services VPC. This configuration would bypass the transit gateway’s r...
Author: Sofia · Last updated Jul 24, 2026
A company is using a NAT gateway to allow internet connectivity for private subnets in a VPC in the us-west-2 Region. After a security audit, the company needs to remove the NAT gateway.
In the private subnets, the company has resources that use the unified Amazon CloudWatch agent. A network engineer must create a solution to ensure that the unified CloudWatch agent c...
To ensure that the unified Amazon CloudWatch agent continues to work after the NAT gateway is removed, we need to focus on solutions that allow the private subnets to access CloudWatch services without the need for internet connectivity through a NAT gateway. This can be achieved by leveraging VPC endpoints for Amazon CloudWatch services, along with proper network configurations. Let's break down the options and determine which steps should be taken.
Option Analysis:
A) Validate that private DNS is enabled on the VPC by setting the enableDnsHostnames VPC attribute and the enableDnsSupport VPC attribute to true.
- Why selected: Enabling DNS hostnames and support is essential for private DNS resolution within the VPC. This is necessary when using VPC endpoints because it ensures that services like CloudWatch can be resolved correctly without requiring the NAT gateway.
- Reason for rejection: While important, this option alone doesn't address the removal of the NAT gateway and doesn't directly ensure that CloudWatch access continues working. However, it supports other configurations.
B) Create a new security group with an entry to allow outbound traffic that uses the TCP protocol on port 443 to destination 0.0.0.0/0.
- Why rejected: This would allow outbound internet access to any destination, which negates the purpose of using VPC endpoints for private communication. We are trying to avoid using the NAT gateway, and allowing outbound traffic to 0.0.0.0/0 conflicts with the objective.
- Reason for rejection: It's unnecessary if we implement VPC endpoints for CloudWatch services and restrict traffic to those endpoints.
C) Create a new security group with entries to allow inbound traffic that uses the TCP protocol on port 443 from the IP prefixes of the private subnets.
- Why rejected: This option is aimed at controlling inbound traffic, but CloudWatch is an outbound service. You need to focus on allowing outbound traffic to the CloudWatch endpoints, not inbound traffic from the private subnets.
- Reason for rejection: Doesn't align with the need to access CloudWatch services through...
Author: Lucas · Last updated Jul 24, 2026
An international company provides early warning about tsunamis. The company plans to use IoT devices to monitor sea waves around the world. The data that is collected by the IoT devices must reach the company's infrastructure on AWS as quickly as possible. The company is using three operation centers around the world. Each operation center is connected to AWS through Its own AWS Direct Connect connection. Each operation center is connected to the internet through at least two upstream internet service providers.
The company has its own provider-independent (PI) address space. The IoT devices use TCP protocols for reliable transmission of the data they collect. The IoT devices have both landline and mobile internet connectivity. The i...
To meet the company's requirements for the highest availability and optimal connectivity between IoT devices and AWS services, let's analyze each solution and the corresponding factors.
Option Analysis:
A) Set up an Amazon CloudFront distribution with origin failover. Create an origin group for each Region where the solution is deployed.
- Why rejected: CloudFront is primarily used for content delivery and caching, typically to distribute static content (e.g., websites, media files). While CloudFront does offer origin failover, it's not designed for real-time IoT data transmission. The IoT devices are sending TCP-based data, and CloudFront does not provide the low-latency, high-availability characteristics required for IoT traffic.
- Reason for rejection: CloudFront is not optimized for TCP connections, which is a key requirement for the IoT devices transmitting data reliably.
B) Set up Route 53 latency-based routing. Add latency alias records. For the latency alias records, set the value of Evaluate Target Health to Yes.
- Why selected: Amazon Route 53 latency-based routing enables the DNS service to direct IoT traffic to the AWS Region with the lowest latency. By evaluating the health of the endpoints, Route 53 can route traffic to healthy resources, enhancing availability. This approach also allows for multi-Region deployment, ensuring high availability for the IoT devices by directing traffic to the best-performing AWS Region.
- Reason for selection: This solution directly addresses the requirement for high availability and low-latency data routing to the appropriate AWS Region based on real-time conditions. It is a natural fit for the use case of reliable data transmission from IoT devices, leveraging AWS’s built-in DNS and health checks for high availability.
C) Set up an accelerator in AWS Global Accelerator. Configure Regional endpoint groups and health checks.
- Why selected: AWS Global Accelerator provides global traffic management and uses anycast IP addresses...
Author: James · Last updated Jul 24, 2026
A company is planning a migration of its critical workloads from an on-premises data center to Amazon EC2 instances. The plan includes a new 10 Gbps AWS Direct Connect dedicated connection from the on-premises data center to a VPC that is attached to a transit gateway. The migration must occur over encrypted paths be...
To meet the company's requirements for migrating critical workloads from an on-premises data center to Amazon EC2 instances over encrypted paths with the highest throughput, let’s analyze each option based on throughput, security, and scalability.
Option Analysis:
A) Configure a public VIF on the Direct Connect connection. Configure an AWS Site-to-Site VPN connection to the transit gateway as a VPN attachment.
- Why rejected: A public Virtual Interface (VIF) on Direct Connect connects to AWS public services (like S3 or DynamoDB), not to a VPC directly, which does not meet the requirement for secure communication between the on-premises data center and the VPC. Furthermore, Site-to-Site VPN connections generally offer lower throughput compared to Direct Connect and may not provide sufficient performance for a 10 Gbps connection.
- Reason for rejection: Public VIF doesn't support direct VPC connectivity, and VPN connections over a public internet path will not provide the highest throughput.
B) Configure a transit VIF on the Direct Connect connection. Configure an IPsec VPN connection to an EC2 instance that is running third-party VPN software.
- Why rejected: A transit VIF on Direct Connect provides a high-performance, dedicated connection to a VPC and allows the use of the AWS Transit Gateway. However, configuring IPsec VPN with third-party VPN software introduces an additional layer of complexity and reduces the throughput. IPsec VPNs generally do not scale well for high-throughput connections like 10 Gbps due to encryption overhead.
- Reason for rejection: Introducing third-party VPN software adds unnecessary complexity and reduces throughput, not suitable for high-throughput requirements.
C) Configure MACsec for the Direct Connect connection. Configure a transit VIF to ...
Author: Charlotte · Last updated Jul 24, 2026
A network engineer must develop an AWS CloudFormation template that can create a virtual private gateway, a customer gateway, a VPN connection, and static routes in a route table. During testing of the template, the network engineer notes that the CloudFormation ...
In this scenario, the network engineer is encountering an error during the testing of the CloudFormation template, where the resources (virtual private gateway, customer gateway, VPN connection, and static routes in the route table) are not being created in the correct order. Let's analyze the options and determine the best course of action.
Option Analysis:
A) Change the order of resource creation in the CloudFormation template.
- Why rejected: CloudFormation inherently manages the order of resource creation based on resource dependencies. For example, a virtual private gateway must exist before a VPN connection is created, and a route table must be configured after creating the VPN connection. Simply changing the order of resources without specifying dependencies will not guarantee proper creation, as CloudFormation will attempt to create resources in parallel where possible, which can lead to errors if the dependencies are not clearly defined.
- Reason for rejection: CloudFormation can automatically manage most dependencies, so manually changing the order of resource creation is not a sustainable solution.
B) Add the DependsOn attribute to the resource declaration for the virtual private gateway. Specify the route table entry resource.
- Why rejected: The `DependsOn` attribute can force CloudFormation to create the resources in a specific order, but in this case, it’s unnecessary to make the route table entry depend on the virtual private gateway. The route table entries should depend on the VPN connection or the virtual private gateway, not directly on the route table itself.
- Reason for rejection: This solution forces an unnecessary dependency between the virtual private gateway and the ...
Author: CrystalWolfX · Last updated Jul 24, 2026
A company operates its IT services through a multi-site hybrid infrastructure. The company deploys resources on AWS in the us-east-1 Region and in the eu-west-2 Region. The company also deploys resources in its own data centers that are located in the United States (US) and in the United Kingdom (UK). In both AWS Regions, the company uses a transit gateway to connect 15 VPCs to each other. The company has created a transit gateway peering connection between the two transit gateways. The VPC CIDR blocks do not overlap with each other or with IP addresses used within the data centers. The VPC CIDR prefixes can also be aggregated either on a Regional level or for the company's entire AWS environment.
The data centers are connected to each other by a private WAN connection. IP routing information is exchanged dynamically through Interior BGP (iBGP) sessions. The data centers maintain connectivity to AWS through one AWS Direct Connect connection in the US and one Direct Connect connection in the UK. Each Direct Connect connection is terminated on a Direct Connect gateway and is associated with a local transit gateway through a transit VIF.
Traffic follows the shortest geographical path from source to destination. For example, packets from the UK data center that are targeted to resources in eu-west-2 travel across the local Direct Connect connection. In cases of cross-Region data ...
The problem described in the question pertains to optimizing the routing setup to ensure that cross-Region data transfers continue functioning correctly, even when the private WAN connection is interrupted. The network engineer must modify the routing configuration to prevent these interruptions while keeping the normal traffic routing intact. Let's break down and analyze each option based on the given requirements.
Option Analysis:
A) Remove all the VPC CIDR prefixes from the list of subnets advertised through the local Direct Connect connection. Add the company's entire AWS environment aggregate route to the list of subnets advertised through the local Direct Connect connection.
- Why rejected: This option would aggregate all AWS VPC CIDR blocks into a single large route. While this might simplify routing, it could break the requirement to retain detailed routing in the non-aggregated form for cross-Region traffic, as requested by the engineer. It also might affect how the traffic is routed between Regions and to the data centers, since the individual VPC CIDRs wouldn’t be advertised anymore.
- Reason for rejection: The solution oversimplifies the routing and doesn’t preserve the detailed CIDR prefixes necessary for proper cross-Region routing during failure scenarios.
B) Add the CIDR prefixes from the other Region VPCs and the local VPC CIDR blocks to the list of subnets advertised through the local Direct Connect connection. Configure data center routers to make routing decisions based on the BGP communities received.
- Why selected: This option ensures that the CIDR prefixes from the other Region’s VPCs and local VPCs are advertised through the Direct Connect connection. By using BGP communities, the data center routers can make routing decisions based on the BGP attributes, allowing for more granular control. If one of the Direct Connect links fails, this approach will still ensure that routing continues to work by using the backup paths across the private WAN or the correct Regional Direct Connect connections.
- Reason for selection: This solution retains the specific CIDR blocks for routing decisions, preserving the required granularity for cross-Region traffic routing and utilizing BGP communities to control routing dynamically.
C) Add the aggregate IP prefix for the other Region and the local VPC CIDR blocks to the list of subnets advertised through the local Direct Connect connection.
- Why rejected: Aggregating the IP prefixes for the local Region and the other Region might not provide the level of detail needed for routing decisions, especially for cross-Region data trans...
Author: IronLion88 · Last updated Jul 24, 2026
A company's network engineer needs to design a new solution to help troubleshoot and detect network anomalies. The network engineer has configured Traffic Mirroring. However, the mirrored traffic is overwhelming the Amazon EC2 instance that is the traffic mirror target. The EC2 instance hosts tools that the company's security team uses to analyze the traffic. The netwo...
The scenario involves designing a solution for handling traffic mirroring that addresses performance, scalability, and high availability. Let's evaluate the options:
Option A: Deploy a Network Load Balancer (NLB) as the traffic mirror target. Behind the NLB, deploy a fleet of EC2 instances in an Auto Scaling group. Use Traffic Mirroring as necessary.
- Analysis:
- NLBs are designed for handling large volumes of traffic with low latency and high throughput. NLBs operate at the network layer (Layer 4), which is ideal for traffic mirroring that does not need content-based routing.
- Auto Scaling EC2 instances behind the NLB ensure that the system scales to accommodate high or variable traffic loads, providing high availability and scaling as needed.
- Traffic mirroring needs to be handled as per the system's demands, and NLB can forward mirrored traffic to the Auto Scaling EC2 fleet efficiently.
- Why it works:
- The NLB can efficiently distribute traffic to a fleet of EC2 instances, ensuring the system is highly available and scalable. This is ideal when the mirrored traffic volume is high, as the NLB can handle large-scale traffic distribution without creating bottlenecks.
- Key factors:
- Traffic mirroring can be handled continuously, scaling dynamically with the Auto Scaling group behind the NLB.
Option B: Deploy an Application Load Balancer (ALB) as the traffic mirror target. Behind the ALB, deploy a fleet of EC2 instances in an Auto Scaling group. Use Traffic Mirroring only during non-business hours.
- Analysis:
- ALBs operate at Layer 7 (the application layer) and are designed to route traffic based on content, such as URLs or headers. However, Traffic Mirroring generally focuses on capturing raw traffic data, which doesn't require the detailed content inspection that ALBs provide.
- The decision to use Traffic Mirroring only during non-business hours limits the flexibility of the solution and is not ideal for continuous or high-demand traffic mirroring scenarios.
- Why it's less ideal:
- ALBs are not optimized for handling raw network traffic at scale (Layer 4). Additionally, limiting Traffic Mirroring to non-business hours is a restrictive approach, especially if the company needs real-time anomaly detection or troubleshooting.
- Key factors:
- The focus on non-business hours may not meet the demand for continuous monitoring, and using ALBs for traf...
Author: Sofia · Last updated Jul 24, 2026
A company uses a hybrid architecture and has an AWS Direct Connect connection between its on-premises data center and AWS. The company has production applications that run in the on-premises data center. The company also has production applications that run in a VPC. The applications that run in the on-premises data center need to communicate with the applications that run in the VPC. The company is using corp.example.com as the domain name for the on-premises resources and is using an Amazon Route 53 private hosted zone for aws.example.com to host the VPC resources.
The company is using an open-source recursive DNS resolver in a VPC subnet and is using a DNS resolver in the on-premises data center. The company's on-premises DNS resolver has a forwarder that directs requests for the aws.example.com domain name to the DNS resolver in the VPC. Th...
To replace the open-source recursive DNS resolver with Amazon Route 53 Resolver endpoints and ensure that DNS resolution works correctly between on-premises and VPC applications, the following steps need to be taken:
Option A: Create a Route 53 Resolver rule to forward aws.example.com domain queries to the IP addresses of the outbound endpoint.
- Analysis:
- In this case, the Route 53 Resolver rule can be created in the VPC to forward DNS queries for the aws.example.com domain to the outbound endpoint.
- The outbound endpoint is responsible for forwarding DNS queries from the VPC to the on-premises DNS resolver. This setup allows DNS queries from the VPC for on-premises domains to be sent correctly to the on-premises data center DNS server.
- Why it's selected:
- This configuration is correct because the outbound endpoint facilitates communication from the VPC to the on-premises DNS resolver. Therefore, queries for aws.example.com need to be forwarded to the outbound endpoint.
Option B: Configure the on-premises DNS resolver to forward aws.example.com domain queries to the IP addresses of the inbound endpoint.
- Analysis:
- The on-premises DNS resolver should forward queries for the aws.example.com domain to the inbound endpoint in the VPC.
- The inbound endpoint in the VPC is responsible for accepting DNS queries from the on-premises resolver and resolving them for AWS resources in the VPC.
- Why it's selected:
- The on-premises resolver should forward DNS queries for aws.example.com to the inbound endpoint so that it can resolve DNS queries for AWS resources.
Option C: Create a Route 53 Resolver inbound endpoint and a Route 53 Resolver outbound endpoint.
- Analysis:
- Both an inbound endpoint and an outbound endpoint are required for DNS resolution between the on-premises and AWS environments:
- The inbound endpoint allows DNS queries from the on-premises DNS resolver to reach the VPC.
- The outbound endpoint allows DNS queries from the VPC to reach the on-premises DNS resolver.
- Why it's selected:
- This option is correct because both endpoints are essential for bidirectional DNS communication between the on-premises environment and the VPC.
Option D: Create a Route 53 Resolver rule to forward aws.example.com domain ...
Author: Liam · Last updated Jul 24, 2026
A government contractor is designing a multi-account environment with multiple VPCs for a customer. A network security policy requires all traffic between any two VPCs to be transparently inspected by a third-party appliance.
The customer wants a solution that features AWS Transit Gateway. The setup must be highly available across multiple Availability Zones, and the solution needs to support automated failov...
To design a multi-account environment with multiple VPCs that requires traffic inspection by a third-party appliance, the solution needs to meet the requirements for high availability, automated failover, and transparent inspection while avoiding asymmetric routing. Let’s review and select the correct steps for this solution.
Option A: Deploy two clusters that consist of multiple appliances across multiple Availability Zones in a designated inspection VPC. Connect the inspection VPC to the transit gateway by using a VPC attachment. Create a target group, and register the appliances with the target group. Create a Network Load Balancer (NLB), and set it up to forward to the newly created target group. Configure a default route in the inspection VPC's transit gateway subnet toward the NLB.
- Analysis:
- This option sets up multiple appliances in highly available clusters across multiple Availability Zones. The use of a Network Load Balancer (NLB) is appropriate for forwarding traffic to the appliances in the inspection VPC because the NLB can distribute traffic across the appliance clusters.
- The default route in the inspection VPC towards the NLB ensures that traffic is directed to the inspection appliances for inspection.
- Why it's selected:
- The design provides high availability and failover by distributing appliances across multiple Availability Zones. Using an NLB ensures transparent traffic inspection without introducing asymmetric routing.
- Why it's rejected:
- This is a solid option for most use cases but it does not use a Gateway Load Balancer, which is specifically optimized for network appliance scenarios.
Option B: Deploy two clusters that consist of multiple appliances across multiple Availability Zones in a designated inspection VPC. Connect the inspection VPC to the transit gateway by using a VPC attachment. Create a target group, and register the appliances with the target group. Create a Gateway Load Balancer, and set it up to forward to the newly created target group. Configure a default route in the inspection VPC's transit gateway subnet toward the Gateway Load Balancer endpoint.
- Analysis:
- This option also sets up high availability by deploying appliance clusters across multiple Availability Zones. The key difference here is the use of a Gateway Load Balancer (GLB), which is specifically designed for scenarios like traffic inspection.
- The GLB is a better fit for forwarding traffic to third-party appliances for transparent inspection because it is built to work seamlessly with network appliances and supports automated failover and scaling.
- Why it's selected:
- Gateway Load Balancer is the most suitable option for routing traffic to network appliances, as it offers integration with security and monitoring appliances. The GLB also supports automated failover and high availability across multiple Availability Zones.
Option C: Configure two route tables on the transit gateway. Associate one route table with all the attachments of the application VPCs. Associate the other route table with the inspection VPC's attachment. Propagate all VPC attachments into t...
Author: Noah · Last updated Jul 24, 2026
A company has deployed Amazon EC2 instances in private subnets in a VPC. The EC2 instances must initiate any requests that leave the VPC, including requests to the company's on-premises data center over an AWS Direct Connect connection. No resources outside the VPC can be allowed to open communications directly to the EC2 instances.
The on-premises data center's customer gateway is configured with a stateful firewall device that filters for incoming and outgoing requests to and from multiple VPCs. In addition, the company ...
Let's evaluate the best solution that satisfies the requirement with the least operational overhead.
Key Requirements:
1. EC2 instances need to initiate outbound traffic to both the internet and the on-premises data center.
2. No resources outside the VPC (including the on-premises data center) should directly communicate with the EC2 instances.
3. The on-premises firewall should allow only outbound traffic from EC2 instances to the data center, using a single IP address.
4. We want a solution with the least operational overhead.
Option A: Create a VPN connection over the Direct Connect connection by using the on-premises firewall. Use the firewall to block all traffic from on-premises to AWS. Allow a stateful connection from the EC2 instances to initiate the requests.
- Analysis:
- This option creates a VPN connection over the Direct Connect connection. While it ensures that the EC2 instances can initiate requests to the on-premises data center, the operational complexity increases with the need to configure a VPN connection and manage additional stateful firewall rules on the on-premises side.
- Stateful firewall would allow responses to the EC2 instance's outbound requests, but this adds operational overhead for VPN management and firewall configuration, especially considering Direct Connect is already in use.
- Why it's rejected:
- The requirement mentions using the least operational overhead, and managing a VPN connection on top of Direct Connect would increase complexity and overhead.
Option B: Configure the on-premises firewall to filter all requests from the on-premises network to the EC2 instances. Allow a stateful connection if the EC2 instances in the VPC initiate the traffic.
- Analysis:
- This solution suggests using the on-premises firewall to filter inbound traffic from the on-premises network to EC2 instances, which would meet the requirement of preventing incoming traffic from the on-premises data center to EC2 instances. However, it still requires management of firewall rules on the on-premises side.
- The firewall needs to support stateful connections, but there is no mention of how EC2 instances will communicate with the on-premises data center. This solution is vague on how the IP match rule will be applied or how to ensure the EC2 instances' outbound connections are correctly routed.
- Why it's rejected:
- This option is incomplete in addressing how to route outbound traffic to the on-premises data center while using the least overhead. It doesn't fully explain the mechanism for allowing outbound traffic through the firewall.
Option C: Deploy a ...
Author: Ishaan · Last updated Jul 24, 2026
A global company operates all its non-production environments out of three AWS Regions: eu-west-1, us-east-1, and us-west-1. The company hosts all its production workloads in two on-premises data centers. The company has 60 AWS accounts and each account has two VPCs in each Region. Each VPC has a virtual private gateway where two VPN connections terminate for resilient connectivity to the data centers. The company has 360 VPN tunnels to each data center, resulting in high management overhead. The total VPN throughput for each Region is 500 Mbps.
The company wants to migrate the production environments to AWS. The company needs a s...
Let's evaluate the options for simplifying the network architecture, supporting future growth, and addressing the need to reduce management overhead in a highly scalable way, while accommodating the increased traffic of 2 Gbps per Region.
Key Requirements:
1. Simplification of the network architecture.
2. Reduced management overhead.
3. Scalability to handle an increase in traffic (2 Gbps per Region).
4. The solution should allow future growth and provide resilience between the data centers and AWS.
Option A: Set up an AWS Direct Connect connection from each data center to AWS in each Region. Create and attach private VIFs to a single Direct Connect gateway. Attach the Direct Connect gateway to all the VPCs. Remove the existing VPN connections that are attached directly to the virtual private gateways.
- Analysis:
- Direct Connect (DX) is a managed, high-throughput, and low-latency solution for connecting on-premises data centers to AWS. It would provide better performance (2 Gbps per Region or more) compared to VPN connections.
- The use of a single Direct Connect gateway is a good idea for managing connectivity to multiple VPCs and Regions from the data centers, reducing the complexity and overhead of managing multiple VPN tunnels.
- Removing existing VPNs and replacing them with Direct Connect reduces VPN tunnel management overhead and simplifies the architecture.
- Scalability is addressed by Direct Connect’s ability to support high-throughput traffic and offer resilience via redundant connections.
- Why it's selected:
- Direct Connect provides a dedicated, high-bandwidth solution, which is ideal for supporting future growth and the increased traffic (2 Gbps per Region).
- This solution dramatically reduces management overhead by consolidating the network connections to a single managed service (Direct Connect).
- Why other options are rejected:
- Direct Connect is the most suitable solution in this case because it is designed for high-throughput, dedicated network traffic. It simplifies network architecture, improves reliability, and allows for growth, all without the complexities of managing multiple VPN connections.
Option B: Create a single transit gateway with VPN connections from each data center. Share the transit gateway with each account by using AWS Resource Access Manager (AWS RAM). Attach the transit gateway to each VPC. Remove the existing VPN connections that are attached directly to the virtual private gateways.
- Analysis:
- A single transit gateway consolidates traffic routing between multiple VPCs and accounts, improving manageability.
- However, VPN connections to the data centers will still be used, and this doesn’t fully address the requirement for high throughput (2 Gbps) in each Region.
- Transit gateways with VPN connections can be a good option for simplifying routing and reducing the number of connections, but they still rely on VPN tunn...
Author: Krishna · Last updated Jul 24, 2026
A company is building its website on AWS in a single VPC. The VPC has public subnets and private subnets in two Availability Zones. The website has static content such as images. The company is using Amazon S3 to store the content.
The company has deployed a fleet of Amazon EC2 instances as web servers in a private subnet. The EC2 instances are in an Auto Scaling group behind an Application Load Balancer. The EC2 instances will serve traffic, and they must pull content from an S3 bucket to render the webpages. The company is using AWS Direct Connect with a public VIF for on-premises connectivity to the S3 bucket.
A network engineer notices that traffic between the EC2 instances and Amaz...
To address the network engineer's concern regarding increasing NAT gateway costs due to traffic between EC2 instances and Amazon S3, let's analyze each option:
A) Create a Direct Connect private VIF. Migrate the traffic from the public VIF to the private VIF.
- Why it’s rejected: Direct Connect provides a dedicated network connection between an on-premises data center and AWS. A public VIF (Virtual Interface) enables communication with public AWS services like S3, while a private VIF allows communication with AWS resources that are within the VPC. However, since the EC2 instances in the VPC are already using a public VIF to access Amazon S3 (which is a public service), simply moving traffic to a private VIF would not directly address the issue of reducing NAT gateway costs for traffic between EC2 and S3. A private VIF does not solve the problem of routing S3 traffic through a NAT gateway.
B) Create an AWS Site-to-Site VPN tunnel over the existing public VIF.
- Why it’s rejected: Setting up a VPN tunnel over an existing public VIF is a method for securely connecting an on-premises network to AWS, but it would add unnecessary complexity and cost. The VPN would primarily be used for on-premises to AWS communication, not for reducing costs related to EC2-to-S3 traffic. Additionally, VPN connections are generally not as efficient as direct access methods like VPC endpoints for Amazon S3.
C) Implement interface VPC endpo...
Author: Sofia · Last updated Jul 24, 2026
A company wants to improve visibility into its AWS environment. The AWS environment consists of multiple VPCs that are connected to a transit gateway. The transit gateway connects to an on-premises data center through an AWS Direct Connect gateway and a pair of redundant Direct Connect connections that use transit VIFs. The company must receive notif...
To address the network engineer's requirement for receiving notifications whenever a new route is advertised to AWS from on-premises over Direct Connect, let's analyze each option:
A) Enable Amazon CloudWatch metrics on Direct Connect to track the received routes. Configure a CloudWatch alarm to send notifications when routes change.
- Why it’s rejected: While CloudWatch metrics can help monitor the performance of Direct Connect (e.g., connection health, traffic volume), they do not provide detailed visibility into the specific routes being advertised over the connection. CloudWatch metrics primarily monitor the link status and data throughput but not the actual routes themselves. Therefore, this option does not meet the requirement to track and notify when routes change.
B) Onboard Transit Gateway Network Manager to Amazon CloudWatch Logs Insights. Use Amazon EventBridge (Amazon CloudWatch Events) to send notifications when routes change.
- Why it’s rejected: While EventBridge (formerly CloudWatch Events) can indeed send notifications when changes occur, Transit Gateway Network Manager does not directly support route change notifications over Direct Connect. Transit Gateway Network Manager is more about providing visibility into the overall transit network and its connectivity status. Although you can track some network state changes, it does not natively offer direct tracking or notifications for route advertisements over Direct Connect.
C) Configure an AWS Lambda function to periodically check the routes on the Direct Connect gateway and to send notifications when routes change.
- Why it’s rejected: This solution would involve wri...
Author: Liam · Last updated Jul 24, 2026
A software company offers a software-as-a-service (SaaS) accounting application that is hosted in the AWS Cloud The application requires connectivity to the company's on-premises network. The company has two redundant 10 GB AWS Direct Connect connections between AWS and its on-premises network to accommodate the growing demand for the application.
The company already has encryption between its on-premises network and the colocation. The company needs to encrypt traffic between AWS and...
The goal of the network engineer is to encrypt traffic between AWS and the on-premises network using existing 10 GB Direct Connect connections and without introducing unnecessary operational overhead. Let’s evaluate each option based on these requirements:
A) Deploy a new public VIF with encryption on the existing Direct Connect connections. Reroute traffic through the new public VIF.
- Why it’s rejected: A public VIF (Virtual Interface) is designed for accessing public AWS services, not for private connections between AWS and an on-premises network. Encrypting traffic through a public VIF wouldn’t achieve the required private connectivity for the accounting application or meet the encryption requirement between the on-premises network and AWS. Also, public VIF cannot be used to directly encrypt the traffic over the existing Direct Connect private connections. Thus, this option is unsuitable.
B) Create a virtual private gateway. Deploy new AWS Site-to-Site VPN connections from on premises to the virtual private gateway. Reroute traffic from the Direct Connect private VIF to the new VPNs.
- Why it’s rejected: This option introduces unnecessary complexity and would add additional latency by routing traffic through VPN tunnels. The VPN would encrypt the traffic, but VPNs are typically used for lower bandwidth, less reliable connections, and would add extra overhead to manage, especially for the required 10 GB bandwidth. Using VPNs in this case is less efficient compared to using the native encryption method that Direct Connect offers with MACsec.
C) Deploy a new pair of 10 GB Direct Connect connections with MACsec. Configure MACsec on the edge routers. Reroute traffic to the new Direct Connect connections. Decommission the original Direct Connect connections.
- Why it’s selected: MACsec (Media ...
Author: Mia · Last updated Jul 24, 2026
A company hosts an application on Amazon EC2 instances behind an Application Load Balancer (ALB). The company recently experienced a network security breach. A network engineer must collect and analyze logs that include the client IP address, target IP address, target port, and user agent ...
To select the most operationally efficient solution for collecting and analyzing logs that include the client IP address, target IP address, target port, and user agent, let’s evaluate each option:
A) Configure the ALB to store logs in an Amazon S3 bucket. Download the files from Amazon S3, and use a spreadsheet application to analyze the logs.
- Why it’s rejected: Storing the logs in an S3 bucket and manually downloading them to analyze in a spreadsheet application is highly inefficient for real-time analysis, especially for large datasets. It introduces significant operational overhead in terms of manual processing and doesn't scale well. Additionally, this method lacks automation and would not allow for timely or effective monitoring of traffic, which is critical in post-breach scenarios.
B) Configure the ALB to push logs to Amazon Kinesis Data Streams. Use Amazon Kinesis Data Analytics to analyze the logs.
- Why it’s rejected: While Kinesis Data Streams and Kinesis Data Analytics can provide real-time processing and analysis of data, this solution is more complex than needed for log analysis in this case. It involves setting up and managing a streaming data pipeline, which may introduce additional operational overhead and is more suitable for real-time data processing applications rather than log analysis.
C) Configure Amazon Kinesis Data Streams to stream data from the ALB to Amazon OpenSearch Service (Amazon Elasticsearch Service). Use search operations in Amazon OpenSearch Service (Amazon Elasticsearch Service) to analyze the data.
- Why it’s rejected: While Amazon OpenSearch S...
Author: FlamePhoenix2025 · Last updated Jul 24, 2026
A media company is implementing a news website for a global audience. The website uses Amazon CloudFront as its content delivery network. The backend runs on Amazon EC2 Windows instances behind an Application Load Balancer (ALB). The instances are part of an Auto Scaling group. The company's customers access the website by using service example com as the CloudFront custom domain name. The CloudFront origin points to an ALB that uses service-alb.example.com as the domain name.
The company's ...
To ensure that the traffic between users and the backend is encrypted in transit, let's evaluate the proposed options and select the best ones based on security requirements:
A) Create a self-signed certificate for service.example.com. Import the certificate into AWS Certificate Manager (ACM). Configure CloudFront to use this imported SSL/TLS certificate. Change the default behavior to redirect HTTP to HTTPS.
- Why it’s rejected: Self-signed certificates are not recommended for production environments because they are not trusted by clients. CloudFront needs a trusted SSL/TLS certificate to establish secure connections with clients. Additionally, while redirecting HTTP to HTTPS is good practice, using a self-signed certificate would not meet the company’s security policy of using trusted certificates.
B) Create a certificate for service.example.com by using AWS Certificate Manager (ACM). Configure CloudFront to use this custom SSL/TLS certificate. Change the default behavior to redirect HTTP to HTTPS.
- Why it’s selected: This option is ideal for the public-facing CloudFront distribution. A trusted certificate from AWS Certificate Manager (ACM) ensures that CloudFront uses HTTPS for secure communication with clients. By redirecting HTTP to HTTPS, this configuration ensures that all traffic is encrypted in transit between the users and CloudFront, meeting the security policy requirements.
C) Create a certificate with any domain name by using AWS Certificate Manager (ACM) for the EC2 instances. Configure the backend to use this certificate for its HTTPS listener. Specify the instance target type during the creation of a new target group that uses the HTTPS protocol for its targets. Attach the existing Auto Scaling group to this new target group.
- Why it’s rejected: While this option proposes configuring HTTPS for the backend, it is using a certificate for any domain name, which is not aligned with the service-alb.example.com domain name for the backend. This setup could lead to certificate mismatches and security warnings, which can compromise trust and violate security policies. A certificate must match the correct domain (service-alb.example.com) used by the ALB for backend traffic.
D) Create a public certificate from a third-party certificate provider with any domain name for the EC2 instances. Configure the backend to us...
Author: Carlos Garcia · Last updated Jul 24, 2026
A company is hosting an application on Amazon EC2 instances behind a Network Load Balancer (NLB). A solutions architect added EC2 instances in a second Availability Zone to improve the availability of the application. The solutions architect added the instances to the NLB target group.
The company's operations team notices that traffi...
To address the issue where traffic is being routed only to the instances in the first Availability Zone, we need to ensure that the Network Load Balancer (NLB) is properly distributing traffic to the EC2 instances across both Availability Zones. Let’s evaluate each option:
Option A: Enable the new Availability Zone on the NLB
- Explanation: When you add EC2 instances in a new Availability Zone (AZ) to an NLB target group, you need to ensure that the NLB is configured to route traffic to all available AZs. This can be done by explicitly enabling the new AZ in the NLB configuration.
- Why it works: By default, an NLB only routes traffic to instances in AZs that are enabled in the NLB configuration. Enabling the new AZ ensures that traffic can be routed to instances in both the original and the new AZ.
- Why it is preferred: This option is the most operationally efficient solution because it directly addresses the issue without requiring additional changes like creating new NLBs or target groups. It maintains the current setup and simply updates the AZs.
Option B: Create a new NLB for the instances in the second Availability Zone
- Explanation: Creating a new NLB would involve setting up a completely new load balancer to handle traffic for the instances in the second AZ. This option is inefficient as it would require maintaining two separate NLBs.
- Why it's not ideal: It introduces unnecessary complexity by using multiple NLBs for what should be a single load balancing solution, making it harder to manage and maintain. Additionally, you’d lose the benefits of a single global load balancing configuration across all AZs.
Option C: Enable proxy protocol on the NLB
- Explanation: The proxy protocol all...
Author: Emily · Last updated Jul 24, 2026
A network engineer needs to set up an Amazon EC2 Auto Scaling group to run a Linux-based network appliance in a highly available architecture. The network engineer is configuring the new launch template for the Auto Scaling group.
In addition to the primary network interface the network appliance requires a second network interface that will be used exclusively by the application to exchange traffic with hosts over the internet. The company has set up a Bring Your...
Let's evaluate each of the options provided for setting up an Amazon EC2 Auto Scaling group with a second network interface (ENI) that uses an Elastic IP address from the BYOIP pool:
Option A: Configure the two network interfaces in the launch template. Define the primary network interface to be created in one of the private subnets. For the second network interface, select one of the public subnets. Choose the BYOIP pool ID as the source of public IP addresses.
- Explanation: This option configures both network interfaces directly in the launch template. The primary ENI is associated with a private subnet, and the second ENI is associated with a public subnet, where the Elastic IP address from the BYOIP pool is used as the public IP.
- Why it works: This is a straightforward and efficient solution for setting up a highly available architecture where the second network interface is exposed to the public subnet with the desired BYOIP Elastic IP address.
- Why it’s preferred: By configuring both ENIs in the launch template, you automate the process of instance creation and network interface attachment without additional scripts or manual intervention. It's highly operationally efficient because everything is handled automatically when the Auto Scaling group launches instances.
Option B: Configure the primary network interface in a private subnet in the launch template. Use the user data option to run a cloud-init script after boot to attach the second network interface from a subnet with auto-assign public IP addressing enabled.
- Explanation: This option uses the cloud-init script in the user data to attach a second network interface to the instance after it boots. The network interface would be in a subnet with auto-assign public IPs enabled.
- Why it's not ideal: This approach introduces complexity because it requires a post-launch script to manage the second network interface attachment. While this can work, it complicates the architecture and may cause delays in instance initialization, which could be a concern for high availability and scaling.
- Why it’s less efficient: Handling network interfaces after boot adds operational complexity and potential failure points. Moreover, it doesn’t offer the same level of control over the network interface as Option A, which directly associates the second ENI during launch.
Option C: Create an AWS Lambda function to run as a lifecycle hook of the Auto Scaling group when an instance is launching. In the Lambda function, assign a network interface to an AWS Glob...
Author: Suresh · Last updated Jul 24, 2026
A company delivers applications over the internet. An Amazon Route 53 public hosted zone is the authoritative DNS service for the company and its internet applications, all of which are offered from the same domain name.
A network engineer is working on a new version of one of the applications. All the application's components are hosted in the AWS Cloud. The application has a three-tier design. The front end is delivered through Amazon EC2 instances that are deployed in public subnets with Elastic IP addresses assigned. The backend components are deployed in private subnets from RFC1918.
Components of the application need to be able to access other components of the application within the application's V...
Let's evaluate each option in detail and determine which steps will best meet the requirements for delivering the application with a consistent DNS experience both internally (within the VPC) and externally (over the internet).
Key Requirements:
1. Access application components within the VPC using the same hostnames that are used over the public internet.
2. Future DNS changes should be accommodated easily (like introducing new hostnames or retiring DNS entries).
3. The application components are in public subnets with Elastic IP addresses, and backend components are in private subnets.
Option A: Add a geoproximity routing policy in Route 53.
- Explanation: A geoproximity routing policy in Route 53 routes traffic based on the geographic location of the requestor and the resources. This option is used for routing traffic based on geographic proximity, not for managing internal and external DNS resolution.
- Why it's rejected: This is not relevant to the need for DNS resolution for both internal and external access to application components. The requirement here focuses on having the same DNS names for internal and external access, not on geographic routing.
Option B: Create a Route 53 private hosted zone for the same domain name. Associate the application’s VPC with the new private hosted zone.
- Explanation: A private hosted zone will allow you to resolve DNS names internally within the VPC. You can create the same domain name in the private hosted zone as in the public hosted zone, but with private IP addresses (for internal communication within the VPC).
- Why it works: By associating the private hosted zone with the VPC, you ensure that internal components of the application can resolve the same hostnames that are used publicly, but they will resolve to private IP addresses for internal traffic. This solution aligns with the requirement to access application components within the VPC using the same hostnames.
- Why it’s selected: This solution directly addresses the need to have the same DNS names for both internal and external use.
Option C: Enable DNS hostnames for the application's VPC.
- Explanation: Enabling DNS hostnames for the VPC ensures that EC2 instances in the VPC can be assigned DNS hostnames. This is necessary for allowing DNS resolution within the VPC.
- Why it works: Enabling DNS hostnames ensures that all the EC2 instances within the VPC can be accessed using DNS names, and it’s a necessary step to ensure that instances can be resolved to their private IP addresses within the VPC.
- Why it’s selected: This is a fundamental step in ensuring that instances can resolve DNS names within the VPC, making it a necessary configuration.
Option D: Create entries in the private hosted zone for each name in the public hosted zone by using the corresponding private IP addresses.
- Explanation: In the private hosted zone, you can manually create DNS entries that match those in the public hosted zone but point to ...
Author: James · Last updated Jul 24, 2026
A company is deploying an application. The application is implemented in a series of containers in an Amazon Elastic Container Service (Amazon ECS) cluster. The company will use the Fargate launch type for its tasks. The containers will run workloads that require connectivity initiated over an SSL connection. Traffic must be able to flow to the application from other AWS acco...
Let's evaluate each of the options based on the requirements and constraints of the given scenario:
Requirements Recap:
- The containers run in an ECS cluster using the Fargate launch type.
- Traffic must be initiated over SSL connections.
- The application must scale as more consumers use the application.
- Private connectivity is needed from other AWS accounts.
- The solution must allow for easy and efficient scaling.
Option A: Choose a Gateway Load Balancer (GLB) as the type of load balancer for the ECS service. Create a lifecycle hook to add new tasks to the target group from Amazon ECS as required to handle scaling. Specify the GLB in the service definition. Create a VPC peer for external AWS accounts. Update the route tables so that the AWS accounts can reach the GLB.
- Explanation: A Gateway Load Balancer (GLB) is typically used to direct traffic to specialized appliances, like security appliances, but it is not the best choice for a standard application load balancing setup. GLBs are designed for use cases like traffic inspection, firewalling, and VPNs, rather than general web traffic routing.
- Why it’s not ideal: GLBs are not designed for SSL traffic and web application load balancing. The GLB solution would also add unnecessary complexity by introducing VPC peering, which is not the most efficient solution for a scenario where SSL and scalable load balancing are needed.
Option B: Choose an Application Load Balancer (ALB) as the type of load balancer for the ECS service. Create path-based routing rules to allow the application to target the containers that are registered in the target group. Specify the ALB in the service definition. Create a VPC endpoint service for the ALB. Share the VPC endpoint service with other AWS accounts.
- Explanation: An Application Load Balancer (ALB) supports SSL termination and path-based routing, which makes it a good fit for web applications. Additionally, it can be used with ECS and Fargate to route traffic to container tasks. A VPC endpoint service for the ALB allows private connectivity from other AWS accounts.
- Why it works: The ALB provides the SSL functionality and scalability required by the application, while the VPC endpoint service allows private connectivity from other AWS accounts. This solution enables scaling, SSL support, and private connectivity in a straightforward manner.
- Why it’s preferred: The ALB is a highly suitable choice because it provides the necessary application-layer routing, SSL handling, and private connectivity with ease.
Option C: Choose an Application Load Balancer (ALB) as the type of load balancer for the ECS service. Create path-bas...
Author: Oliver · Last updated Jul 24, 2026
A company's development team has created a new product recommendation web service. The web service is hosted in a VPC with a CIDR block of 192.168.224.0/19. The company has deployed the web service on Amazon EC2 instances and has configured an Auto Scaling group as the target of a Network Load Balancer (NLB).
The company wants to perform testing to determine whether users who receive product recommendations spend more money than users who do not receive product recommendations. The company has a big sales event in 5 days and needs to integrate its existing production environment with the recommendation engine by then. The existing...
To meet the requirement of integrating the systems with the least disruption while ensuring a smooth connection between the web service VPC (192.168.224.0/19) and the production VPC (192.168.128.0/17), let's evaluate each option in detail:
Option A: Create a VPC peering connection between the web service VPC and the existing production VPC. Add a routing rule to the appropriate route table to allow data to flow to 192.168.224.0/19 from the existing production environment and to flow to 192.168.128.0/17 from the web service environment. Configure the relevant security groups and ACLs to allow the systems to communicate.
- Explanation: VPC peering establishes a direct network connection between two VPCs, enabling instances in either VPC to communicate with each other as long as appropriate route tables and security groups are configured.
- Why it works: This solution is simple to implement and allows traffic to flow between the two VPCs. It also results in minimal disruption since the existing infrastructure remains unchanged. The routing rules and security configurations ensure that only authorized communication happens between the VPCs.
- Why it’s preferred: VPC peering is a straightforward solution for this use case, as it allows for easy and direct communication between the web service VPC and the production VPC. It is also fast to set up and involves minimal disruption to the existing environment.
- Limitations: The main limitation is that VPC peering does not support transitive routing (i.e., routing between VPCs through a third VPC), but this is not a problem in this scenario because only the two specific VPCs are involved.
Option B: Ask the development team of the web service to redeploy the web service into the production VPC and integrate the systems there.
- Explanation: This option suggests moving the web service to the production VPC, which would involve significant changes to the deployment architecture, reconfiguration of security settings, and potential downtime during the redeployment process.
- Why it’s rejected: This solution would be disruptive because it requires redeploying the web service into the production VPC, which is not ideal when there are only five days left to integrate the systems. It introduces risk, and the redeployment may cause significant delays or complications, especially given that the integration needs to be completed soon.
Option C: Create a VPC endpoint service. Associate the VPC endpoint service with the NLB for the web service. Create an interface VPC endpoint for the web service in the existing production VPC.
- Explanation: A VPC endpoint...
Author: Ahmed97 · Last updated Jul 24, 2026
A network engineer needs to update a company's hybrid network to support IPv6 for the upcoming release of a new application. The application is hosted in a VPC in the AWS Cloud. The company's current AWS infrastructure includes VPCs that are connected by a transit gateway. The transit gateway is connected to the on-premises network by AWS Direct Connect and AWS Site-to-Site VPN. The company's on-premises devices have been updated to support the new IPv6 requirements.
The company has enabled IPv6 for the existing VPC by assigning a new IPv6 CIDR block to the VPC and by assigning IPv6 to the subnets for dual-stack support. The company has launched new Amazon EC2 instances for the new application in the updated subnets.
When updating the hybrid network to support IPv6 the network eng...
Analysis:
To determine the best solution, we need to consider several key factors:
1. IPv6 Connectivity Between VPC and On-Premises:
The company wants to support IPv6 without changing the current infrastructure. This means the solution should not involve making changes to existing VPC connections, Direct Connect, or Site-to-Site VPN, except to add IPv6 support where necessary.
2. Blocking Direct Internet Access to EC2 Instances via IPv6:
The engineer must block direct inbound internet access to the EC2 instances' IPv6 addresses. However, outbound internet access needs to be allowed.
3. Operational Efficiency:
The solution should minimize operational overhead, ensuring that the existing setup is utilized as much as possible and does not involve unnecessary steps or resources.
---
Option Breakdown:
- Option A:
- Update the Direct Connect transit VIF and configure BGP peering with the AWS-assigned IPv6 peering address.
- Create a new VPN connection that supports IPv6.
- Add an egress-only internet gateway.
- Update security groups and route tables.
Analysis:
- Direct Connect and VPN Update: This is fine since both are capable of supporting IPv6 and can be updated without impacting existing infrastructure.
- Egress-only Internet Gateway: This is the correct way to block direct inbound access to the instances' IPv6 addresses while allowing outbound internet access.
- Security Group and Route Table Updates: Updating these to ensure proper IPv6 communication is standard practice.
- Pros: Efficient solution that avoids making major changes to the infrastructure.
- Cons: This requires creating a new VPN connection, which might be slightly cumbersome compared to reusing existing connections.
- Option B:
- Same as Option A but updates the existing VPN connection to support IPv6 connectivity instead of creating a new VPN connection.
Analysis:
- This is the more efficient choice compared to Option A because it avoids the need for a new VPN connection and le...
Author: Deepak · Last updated Jul 24, 2026
A network engineer must provide additional safeguards to protect encrypted data at Application Load Balancers (ALBs) through the use of a unique random sessio...
Analysis:
To meet the requirement of providing additional safeguards to protect encrypted data at Application Load Balancers (ALBs) using a unique random session key, the network engineer needs to focus on ensuring that the encryption at the ALB leverages strong session key protection, ideally through mechanisms like forward secrecy (FS) or encryption keys that are unique and robust.
---
Option Breakdown:
- Option A: Change the ALB security policy to a policy that supports TLS 1.2 protocol only.
- Analysis: TLS 1.2 is a widely used protocol that provides secure communication, but it does not necessarily involve the concept of a unique random session key or forward secrecy. It mainly ensures the confidentiality and integrity of data during transmission.
- Pros: Ensures secure encryption using TLS 1.2, which is considered strong.
- Cons: This option does not specifically address the requirement for a unique random session key or safeguards related to forward secrecy. It only addresses the protocol used for encryption, without adding the layer of security that would protect the session keys in the way forward secrecy would.
- Use Case: While TLS 1.2 is necessary for security, this option alone does not meet the unique session key requirement.
- Option B: Use AWS Key Management Service (AWS KMS) to encrypt session keys.
- Analysis: AWS KMS is a fully managed service that allows for the creation and control of encryption keys. Using KMS to encrypt session keys would add an additional layer of protection to the session keys used by the ALB. However, session keys are typically generated dynamically and used for short durations, so the emphasis should be on forward secrecy to ensure that session keys are not compromised.
- Pros: AWS KMS is an excellent way to manage and protect keys, and it can provide strong encryption.
- Cons: While KMS is a powerful tool for key management, it does not directly address the requirement for forward secrecy or a unique random session key in the context of protecting data in transit during the TLS handshake.
- Use Case: KMS can be beneficial for protecting keys in a broader sense, but forward secrecy would be the better approach for ensuring s...
Author: Oliver · Last updated Jul 24, 2026
A company has deployed a software-defined WAN (SD-WAN) solution to interconnect all of its offices. The company is migrating workloads to AWS and needs to extend its SD-WAN solution to support connectivity to these workloads.
A network engineer plans to deploy AWS Transit Gateway Connect and two SD-WAN virtual appliances to provide this connectivity. According to company policies, only...
Analysis:
To meet the company's requirements of routing traffic through a single SD-WAN virtual appliance at a given time, the network engineer needs to configure routing in such a way that only one SD-WAN appliance handles traffic to/from the AWS workloads, while still allowing flexibility in the network architecture.
Here’s a breakdown of the options:
---
Option A: Add a static default route in the transit gateway route table to point to the secondary SD-WAN virtual appliance. Add routes that are more specific to point to the primary SD-WAN virtual appliance.
- Analysis:
- Static Routes: By using static routes, the engineer can ensure that specific traffic is directed to the primary or secondary SD-WAN appliance.
- Default Route to Secondary Appliance: Pointing the default route to the secondary appliance could work for backup traffic, ensuring it handles traffic only when no more specific routes are available for the primary appliance.
- More Specific Routes to Primary Appliance: Specific routes to workloads or subnets could direct traffic through the primary appliance, as required by the company policy.
- Pros: This setup would ensure that the primary appliance handles the normal workload, with the secondary appliance being used as a backup. It’s simple and straightforward.
- Cons: The downside is the manual management of routes, which might be less scalable or flexible if the network grows or changes frequently.
- Use Case: This is an ideal option for a simple setup where traffic needs to be statically routed to a primary appliance and failover to a secondary appliance in case of issues.
---
Option B: Configure the BGP community tag 7224:7300 on the primary SD-WAN virtual appliance for BGP routes toward the transit gateway.
- Analysis:
- BGP Community Tags: Community tags in BGP are typically used to signal routing preferences between peers, such as preferring one route over another.
- BGP Preferences: By using the community tag to prefer routes from the primary appliance, the network engineer can influence routing decisions. However, this approach doesn’t inherently restrict routing to a single appliance; instead, it would only prioritize one appliance's routes over the other.
- Pros: This method provides some control over which appliance is preferred.
- Cons: It doesn’t guarantee that only one appliance handles traffic at a given time, which is the requirement. There could still be scenarios where both appliances handle traffic simultaneously.
- Use Case: While useful for controlling route preference, it doesn't meet the requirement of ensuring only one appliance is handling traffic at ...
