Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 821Question →

A SysOps administrator is evaluating cost-saving options for an application running on Amazon EC2 instances, AWS Fargate, and AWS Lambda functions. Which TWO of the following statements correctly describe the scope or characteristics of Compute Savings Plans? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: They apply to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda.; They apply to EC2 instance usage regardless of instance family, size, operating system, or AWS Region.

Answer

Compute Savings Plans apply to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda, and they apply to EC2 instance usage regardless of instance family, size, operating system, or AWS Region.
Compute Savings Plans offer the greatest flexibility by automatically applying to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda, regardless of the instance family, size, OS, tenancy, or AWS Region.

Step-by-Step Solution

1
Analyze the application requirements.
The application runs on Amazon EC2, AWS Fargate, and AWS Lambda.
Understanding the compute services used helps determine which Savings Plan offers the necessary coverage.
2
Evaluate the scope of Compute Savings Plans.
Compute Savings Plans automatically apply to EC2, Fargate, and Lambda across any Region, instance family, size, OS, or tenancy.
This matches the services used by the application and offers maximum flexibility.
3
Compare with EC2 Instance Savings Plans and organization features.
EC2 Instance Savings Plans are limited to a specific instance family in a specific Region and do not cover Fargate or Lambda. Savings Plans can be shared across AWS Organization accounts, and EC2 Instance Savings Plans offer higher maximum discounts than Compute Savings Plans.
This eliminates the incorrect choices by distinguishing the scope, discount levels, and sharing capabilities of different plans.

Key Concept

Compute Savings Plans vs. EC2 Instance Savings Plans
Question 822Question →

A company stores sensitive media assets in an Amazon S3 bucket encrypted with an AWS KMS customer managed key (SSE-KMS). A SysOps administrator is configuring an Amazon CloudFront distribution to serve these assets globally using a custom domain name at the zone apex (e.g., example.com). To meet security compliance, access to the S3 bucket must be restricted so that content is accessible only through CloudFront using Origin Access Control (OAC). Which combination of actions should the administrator perform to securely configure this architecture? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the S3 bucket policy to allow the s3:GetObject action for the CloudFront service principal (cloudfront.amazonaws.com), specifying the Origin Access Control (OAC) ARN as the source ARN in the condition block.; Update the KMS key policy to allow the kms:Decrypt action for the CloudFront service principal (cloudfront.amazonaws.com), specifying the Origin Access Control (OAC) ARN as the source ARN in the condition block.

Answer

Update the S3 bucket policy to allow the s3:GetObject action for the CloudFront service principal conditional on the OAC ARN, and update the KMS key policy to allow the kms:Decrypt action for the CloudFront service principal conditional on the OAC ARN.
To secure S3 origins behind CloudFront distributions using customer managed KMS encryption, two configuration steps are vital: First, the S3 bucket policy must allow `s3:GetObject` requests originating from the OAC. Second, because S3 handles decryption using the customer managed KMS key, the KMS key policy must explicitly authorize the CloudFront service principal (`cloudfront.amazonaws.com`) to call `kms:Decrypt` when requested via the specific OAC.

Step-by-Step Solution

1
Configure the S3 Bucket Policy to authorize CloudFront OAC.
The bucket policy allows the cloudfront.amazonaws.com service principal to execute s3:GetObject only when the source ARN matches the OAC.
This restricts direct access to S3 objects and forces viewers to access content through CloudFront.
2
Configure the KMS Customer Managed Key Policy to authorize CloudFront OAC decryption.
The KMS key policy allows the cloudfront.amazonaws.com service principal to perform the kms:Decrypt operation.
Because objects are encrypted with SSE-KMS, CloudFront must have permissions to decrypt the assets during retrieval.

Key Concept

CloudFront Origin Access Control with SSE-KMS Encrypted S3 Origins
Question 823Question →

A company has a single-account high-performance data processing environment. The environment consists of the following workloads in the us-east-1 Region:

- An Auto Scaling group of EC2 instances running r6i.2xlarger6i.2xlarge (Intel-based) that scales dynamically between 44 and 1616 instances depending on queue depth.
- AWS Lambda functions performing preprocessing tasks with a steady daily average consumption of 80,00080,000 GB-seconds.
- AWS Fargate tasks running on Amazon ECS using the c6gc6g (Graviton2-based) architecture, consuming a constant 88 vCPUs and 1616 GB of memory.

The development team plans to upgrade the Fargate tasks to c7gc7g (Graviton3-based) architecture within the next 9090 days. The EC2 instance family (r6ir6i) will remain unchanged for the next 1212 months.

Which TWO purchase options should a SysOps administrator combine to achieve the maximum cost savings for these workloads with the least operational overhead? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An EC2 Instance Savings Plan for the r6ir6i instance family in the us-east-1 Region; A Compute Savings Plan to cover the AWS Fargate tasks and AWS Lambda functions

Answer

The SysOps administrator should purchase an EC2 Instance Savings Plan for the r6ir6i instance family in the us-east-1 Region to cover the EC2 instances, and a Compute Savings Plan to cover the AWS Fargate tasks and AWS Lambda functions.
The correct strategy combines an EC2 Instance Savings Plan for the stable r6ir6i EC2 instance family and a Compute Savings Plan for the Fargate and Lambda workloads. EC2 Instance Savings Plans offer the highest discount rates (similar to Standard RIs) for a specific family within a region, and they automatically apply to any instance size or OS within that family, which perfectly matches the scaling behavior of the Auto Scaling group. For the Fargate and Lambda workloads, a Compute Savings Plan is the correct choice because it is the only Savings Plan type that covers Fargate and Lambda, and its flexibility allows the Fargate tasks to migrate from the c6gc6g to the c7gc7g family without losing the discount.

Step-by-Step Solution

1
Analyze the EC2 instances requirements
The EC2 instances run on a stable family (r6ir6i) in a single region (us-east-1) but scale dynamically from 44 to 1616 instances. To maximize savings and cover scaling without manual modification overhead, an EC2 Instance Savings Plan for the r6ir6i family is chosen over RIs or Compute Savings Plans.
EC2 Instance Savings Plans offer up to 72% savings (matching Standard RIs) and automatically apply to any instance size, OS, or tenancy within the specified family, making them ideal for scaling groups within a single family.
2
Analyze the Fargate tasks and Lambda requirements
The Fargate tasks are scheduled to migrate from c6gc6g to c7gc7g architecture within 9090 days, and the Lambda functions run regularly. A Compute Savings Plan is selected to cover both workloads.
Compute Savings Plans are the only plan type that covers Fargate and Lambda. Their flexibility allows changes in instance family (c6gc6g to c7gc7g), region, or compute type while maintaining cost savings.
3
Combine the purchase options
Combine the r6ir6i EC2 Instance Savings Plan with a Compute Savings Plan.
This combination maximizes the discount for the stable EC2 fleet (using the higher-discount EC2 Instance Savings Plan) while preserving full flexibility for the evolving Fargate and Lambda workloads (using the Compute Savings Plan).

Key Concept

Selecting the optimal combination of Savings Plans (EC2 Instance vs. Compute) based on workload stability, scaling requirements, instance family migrations, and service compatibility (EC2 vs. Fargate vs. Lambda).
Question 824Question →

A SysOps administrator is troubleshooting connectivity between an application tier in private subnet 10.0.2.0/2410.0.2.0/24 and a PostgreSQL database instance (10.0.3.8910.0.3.89) in private subnet 10.0.3.0/2410.0.3.0/24. The database instance's security group is already configured to allow inbound TCP traffic on port 54325432 from the application tier's security group.

VPC Flow Logs are enabled on the network interface of the database instance and record the following entry:
`2 123456789012 eni-0123456789abcdef0 10.0.2.45 10.0.3.89 49152 5432 6 1 40 1620000000 1620000010 REJECT OK`

Which TWO configuration changes are required to resolve this issue and allow successful database connections? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add an inbound rule to the database subnet's Network ACL that allows TCP traffic on port 54325432 from source CIDR 10.0.2.0/2410.0.2.0/24.; Add an outbound rule to the database subnet's Network ACL that allows TCP traffic on ephemeral ports (1024−655351024-65535) to destination CIDR 10.0.2.0/2410.0.2.0/24.

Answer

To resolve the connectivity issue, the database subnet's Network ACL must be configured to allow the inbound traffic on port 54325432 from the application subnet, and allow the outbound return traffic on the ephemeral port range (1024−655351024-65535) to the application subnet.
The VPC Flow Logs entry shows an ingress packet from the application server (10.0.2.4510.0.2.45, source port 4915249152) to the database instance (10.0.3.8910.0.3.89, destination port 54325432) being rejected. Because the database instance's security group is already configured to allow this inbound traffic, the block is occurring at the database subnet's Network Access Control List (Network ACL). Since Network ACLs are stateless, rules must be configured explicitly for both inbound and outbound traffic. First, an inbound rule must be added to the database subnet's Network ACL to allow TCP traffic on port 54325432 from the application subnet CIDR (10.0.2.0/2410.0.2.0/24). Second, because the client initiated the connection using an ephemeral port (4915249152), an outbound rule must be added to the database subnet's Network ACL to allow the database's response traffic on the ephemeral port range (1024−655351024-65535) back to the application subnet.

Step-by-Step Solution

1
Analyze the VPC Flow Log entry.
The log entry reveals that TCP traffic from 10.0.2.4510.0.2.45 (port 4915249152) to 10.0.3.8910.0.3.89 (port 54325432) is being rejected (`REJECT`) at the database interface level.
To determine where the connection is being blocked.
2
Identify the blocking security control.
Since the security group is already configured to permit the traffic, the block must be due to the database subnet's Network ACL.
To narrow down which configuration needs modification.
3
Apply stateless Network ACL rules.
Add an inbound Network ACL rule to allow TCP traffic on port 54325432 from the source subnet 10.0.2.0/2410.0.2.0/24. Add an outbound Network ACL rule to allow response traffic on the ephemeral port range (1024−655351024-65535) back to the destination subnet 10.0.2.0/2410.0.2.0/24.
Because Network ACLs are stateless, both ingress and egress paths must be explicitly permitted.

Key Concept

Stateless Network ACLs require explicit inbound and outbound rules for traffic flow, including allowing return traffic on ephemeral ports, whereas stateful Security Groups automatically allow return traffic.
Question 825Question →

A SysOps Administrator is configuring network security for a two-tier application. Amazon EC2 instances in the application subnet must be able to initiate database connections to Amazon RDS DB instances in the database subnet on TCP port 1433. The database subnet's Network Access Control List (NACL) is currently configured with default deny rules.

Which two rules must be added to the database subnet's NACL to allow this communication? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An inbound rule to allow TCP traffic from the application subnet IP range on destination port 1433; An outbound rule to allow TCP traffic to the application subnet IP range on destination ports 1024-65535

Answer

An inbound rule to allow TCP traffic from the application subnet IP range on destination port 1433, and an outbound rule to allow TCP traffic to the application subnet IP range on destination ports 1024-65535.
The correct answers describe the stateless configuration required for a NACL. Specifically, an inbound rule must allow TCP traffic from the application subnet on destination port 1433 to accept the incoming connections, and an outbound rule must allow TCP traffic to the application subnet on the ephemeral port range (1024-65535) to allow response packets.

Step-by-Step Solution

1
Identify the communication flow and port requirements.
The application servers initiate a connection to the database on TCP port 1433. The database answers using client-side ephemeral ports (range 1024-65535).
This establishes the necessary ports for both inbound requests and outbound responses.
2
Configure the inbound rule on the database subnet's NACL.
Allow TCP traffic from the application subnet's CIDR block targeting destination port 1433.
This allows connection requests to enter the database subnet.
3
Configure the outbound rule on the database subnet's NACL.
Allow TCP traffic to the application subnet's CIDR block targeting destination ports 1024-65535.
Because NACLs are stateless, return traffic must be explicitly permitted outbound through the ephemeral port range.

Key Concept

Network Access Control Lists (NACLs) are stateless, requiring explicit rules for both inbound request traffic and outbound return traffic (which uses ephemeral ports).
Estimated Time:1m 0s
Question 826Question →

An organization requires the monitoring of all rejected TCP traffic in a specific VPC. A SysOps Administrator is tasked with creating a VPC Flow Log that publishes to a CloudWatch Logs log group. To minimize operational costs, log data must only be retained for 30 days. Additionally, the administrator must adhere to the principle of least privilege when granting permissions.

Which of the following actions should the administrator perform to successfully establish this monitoring setup? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create an IAM role with a trust relationship that allows the vpc-flow-logs.amazonaws.com service principal to assume the role, and attach a policy allowing log delivery permissions to the log group.; Attach an IAM policy to the administrator's IAM identity that includes the iam:PassRole permission for the resource ARN of the flow logs IAM role.

Answer

To successfully set up VPC Flow Logs with CloudWatch Logs and limit retention, the administrator must create an IAM role with a trust relationship allowing the vpc-flow-logs.amazonaws.com service principal to assume the role and attach permissions to write to CloudWatch Logs, and also attach an IAM policy to the administrator's identity granting the iam:PassRole permission for that role.
To configure VPC Flow Logs to publish to CloudWatch Logs, the VPC Flow Logs service principal (vpc-flow-logs.amazonaws.com) must be allowed to assume an IAM role that has write permissions to CloudWatch Logs. Additionally, the administrator who is creating the flow log must have the iam:PassRole permission to assign this role to the service. The retention is managed directly on the CloudWatch Logs log group.

Step-by-Step Solution

1
Configure the CloudWatch Logs log group retention period.
Set the retention of the destination log group to 30 days.
This manages retention and controls costs at the correct log group level.
2
Create and configure the IAM role for VPC Flow Logs.
An IAM role is created with a trust policy for the vpc-flow-logs.amazonaws.com service principal and an execution policy allowing logs:CreateLogStream and logs:PutLogEvents.
This authorizes the VPC Flow Logs service to write logs into the destination CloudWatch Logs log group.
3
Grant iam:PassRole permissions to the administrator's IAM identity.
The administrator's IAM user or group policy allows the iam:PassRole action targeting the ARN of the flow logs IAM role.
This permits the administrator to pass the required role to the flow logs service during flow log creation.

Key Concept

VPC Flow Logs Permission and Log Retention Configuration
Question 827Question →

An Amazon EC2 instance with private IP address 10.0.4.1210.0.4.12 is launched in a private subnet. The instance must make outbound HTTPS requests to an external API endpoint at 203.0.113.80203.0.113.80. The SysOps Administrator has configured security groups and Network Access Control Lists (Network ACLs) for the subnet, but connection attempts from the instance to the API consistently time out. The administrator enables VPC Flow Logs and observes the following log records:

2 123456789012 eni-0a1b2c3d4e5f6g7h8 10.0.4.12 203.0.113.80 52345 443 6 1 40 1783900800 1783900860 ACCEPT OK
2 123456789012 eni-0a1b2c3d4e5f6g7h8 203.0.113.80 10.0.4.12 443 52345 6 1 40 1783900800 1783900860 REJECT OK

Which configuration adjustment will resolve this connectivity issue?

Show answer & explanation

Answer: Add an inbound rule to the subnet's Network ACL allowing TCP traffic from 203.0.113.80203.0.113.80 on ports 1024−655351024-65535.

Answer

Add an inbound rule to the subnet's Network ACL allowing TCP traffic from 203.0.113.80203.0.113.80 on ports 1024−655351024-65535.
The correct option is to add an inbound rule to the subnet's Network ACL allowing TCP traffic from the external API on the ephemeral port range. This is because security groups are stateful and automatically permit return traffic. Network ACLs, however, are stateless and inspect inbound and outbound traffic separately. The VPC Flow Logs show that the outbound request was accepted, but the inbound response on the ephemeral port (52345) was rejected. Thus, the stateless Network ACL blocked the return path because it lacked an inbound rule for ephemeral ports.

Step-by-Step Solution

1
Analyze the VPC Flow Log records to identify the traffic flow direction and the action taken on the packets.
The first log record shows outbound traffic from the EC2 instance (10.0.4.1210.0.4.12) to the API (203.0.113.80203.0.113.80) on destination port 443 with a status of `ACCEPT`. The second record shows inbound return traffic from the API to the EC2 instance on destination port 52345 (an ephemeral port) with a status of `REJECT`.
Identifying that the outbound request is allowed but the return traffic is blocked narrows the issue down to the return path security configurations.
2
Evaluate the stateful and stateless behaviors of the security controls applied to the EC2 instance and subnet.
Security groups are stateful; they automatically allow return traffic for any established connection. Network ACLs are stateless; they evaluate traffic in both directions independently and require explicit rules for both request and response paths.
Understanding the difference in statefulness helps determine whether the security group or Network ACL is responsible for blocking the return traffic.
3
Determine where the return packet is blocked and what rule is missing.
Since the security group automatically allows the return traffic, the block must be occurring at the stateless Network Access Control List (Network ACL). The return packet has a destination port in the ephemeral range (1024−655351024-65535). Thus, the inbound Network ACL must be updated to allow this traffic.
Adding an inbound rule to the Network ACL for the ephemeral ports will permit the return traffic to reach the instance, resolving the timeout.

Key Concept

The stateless nature of Network ACLs requires explicit rules for both request and return paths, including dynamically allocated ephemeral ports for return traffic.
Estimated Time:3m 0s
Question 828Question →

A SysOps Administrator is setting up flow logs for a VPC to deliver network traffic logs to an Amazon CloudWatch Logs log group. The administrator has created a destination log group and has configured an IAM role designed for VPC Flow Logs. When the administrator tries to create the VPC Flow Log, the action fails with an access denied error. Which action will resolve this issue?

Show answer & explanation

Answer: Add a policy to the administrator's IAM identity that grants the `iam:PassRole` permission for the flow logs IAM role.

Answer

Add a policy to the administrator's IAM identity that grants the `iam:PassRole` permission for the flow logs IAM role.
When a SysOps Administrator creates a VPC Flow Log that publishes to CloudWatch Logs, the Flow Logs service must act on behalf of the user. To delegate this authority, the administrator passes an IAM service role to the VPC Flow Logs service. AWS requires the administrator's IAM user or role to have the `iam:PassRole` permission for that specific service role to prevent unauthorized escalation of privilege.

Step-by-Step Solution

1
Analyze the permission failure when enabling the VPC Flow Logs destination.
Identify that the administrator's current policy does not permit passing the configuration role to the VPC Flow Logs service.
Creating a resource that utilizes a service role requires authorization to delegate that role.
2
Attach a policy with the `iam:PassRole` action targeting the Flow Logs role ARN to the administrator's IAM user or group.
The console session successfully validates that the administrator has the authority to pass the IAM role.
This satisfies the AWS security boundary that prevents users from configuring services with roles they are not authorized to use.

Key Concept

Configuring VPC Flow Logs requires the administrator to have the `iam:PassRole` permission on the IAM role passed to the service.
Question 829Question →

A SysOps Administrator is configuring a VPC Flow Log to deliver traffic logs to an Amazon CloudWatch Logs log group. The administrator has created the log group and an IAM role with a trust policy that allows the VPC Flow Logs service principal to assume the role. The IAM role has a permissions policy that allows it to create log streams and put log events. However, when the administrator attempts to create the VPC Flow Log using the AWS CLI, the command fails with an Access Denied error.

Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The IAM policy attached to the SysOps Administrator's user account lacks the iam:PassRole permission for the VPC Flow Logs service role.

Answer

The IAM policy attached to the SysOps Administrator's user account lacks the iam:PassRole permission for the VPC Flow Logs service role.
To create a VPC Flow Log that publishes to CloudWatch Logs, you must pass the IAM role that has permissions to write to CloudWatch Logs. AWS requires the user creating the flow log to have the iam:PassRole permission on that role to prevent unauthorized escalation of privileges.

Step-by-Step Solution

1
Identify the AWS service interaction requirements for VPC Flow Logs.
VPC Flow Logs requires an IAM role to publish to CloudWatch Logs on behalf of the user.
This is a cross-service configuration where AWS VPC delegates writing logs to CloudWatch Logs using a service role.
2
Analyze the permission required by the administrator's user identity to associate the role.
The administrator must have the iam:PassRole permission to pass the role to the VPC Flow Logs service.
Without iam:PassRole, the IAM user cannot associate a service role with an AWS resource, resulting in an Access Denied error during creation.

Key Concept

VPC Flow Logs IAM Delegation and PassRole Permissions
Estimated Time:1m 30s
Question 830Question →

A SysOps administrator is reviewing the weekly AWS Trusted Advisor Cost Optimization report for a production workload. The report contains the following findings:
- An Amazon Elastic Block Store (Amazon EBS) volume has had less than 11 IOPS of write activity for the past 14 days.
- An Application Load Balancer (ALB) has had an ActiveConnectionCount of 00 over the past 7 days.
- An Amazon RDS PostgreSQL DB instance has had no active database connections (DatabaseConnections is 00) for the past 8 days.
- An Elastic IP address (EIP) is listed under the Unassociated Elastic IP Addresses check.
- A group of Amazon EC2 instances running under an Auto Scaling group is flagged under the Low Utilization Amazon EC2 Instances check, showing consistent 3%3\% average CPU utilization.

Which two actions should the SysOps administrator take to resolve these findings and optimize costs? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Release the unassociated Elastic IP address, and delete the Application Load Balancer after verifying no traffic is routed to its DNS name.; Create a final snapshot of the idle RDS PostgreSQL DB instance, and then delete the DB instance.

Answer

The correct actions are to release the unassociated Elastic IP address and delete the idle Application Load Balancer, and to take a final snapshot of the idle RDS PostgreSQL DB instance before deleting it.
Releasing the unassociated Elastic IP address stops the hourly charge for unassigned EIPs. Deleting the Application Load Balancer with zero active connections removes the hourly base charges for the idle load balancer. Creating a final snapshot of the idle RDS PostgreSQL DB instance and deleting it eliminates all DB instance charges while preserving the data for potential future recovery.

Step-by-Step Solution

1
Address the unallocated Elastic IP and idle Application Load Balancer findings.
Identify that disassociation does not stop EIP charges; the EIP must be released. Deleting the idle Application Load Balancer removes hourly base charges.
AWS charges for unassociated Elastic IPs to encourage efficient address space usage. ALBs incur hourly charges regardless of traffic volume.
2
Address the idle Amazon RDS PostgreSQL DB instance finding.
Determine that stopping the instance is not a permanent solution, as stopped RDS instances automatically restart after 7 days. Deleting the instance with a final snapshot is correct.
Deleting the instance stops all compute charges, while the snapshot preserves historical data without incurring active database engine costs.
3
Evaluate the Auto Scaling group and EIP disassociation distractors.
Rule out manual EC2 termination because the Auto Scaling group will automatically replace terminated instances. Rule out disassociation as it keeps the EIP allocated.
Auto Scaling monitors instance health and count relative to its desired capacity setting. Manual intervention at the instance level fails to change this capacity setting.

Key Concept

AWS Trusted Advisor Cost Optimization checks flag idle and underutilized resources. Remediating these requires understanding specific resource lifecycles: Elastic IPs must be released, idle load balancers should be deleted, and idle RDS DB instances must be snapshotted and deleted to prevent auto-restart charges.
Question 831Question →

An organization wants to perform deep packet inspection on traffic directed to a backend application server in a private subnet. A SysOps Administrator configures an Amazon VPC Traffic Mirroring session. The mirror source is the primary Elastic Network Interface (ENI) of the application server, which is running on a t2.mediumt2.medium EC2 instance. The mirror target is a security monitoring tool running on a c5.largec5.large EC2 instance in the same VPC.

The Security Group of the c5.largec5.large target instance is configured to allow inbound UDP traffic on port 47894789. The Security Group of the t2.mediumt2.medium source instance permits all inbound traffic from the application's load balancer, but its outbound rules restrict traffic to 0.0.0.0/00.0.0.0/0 on TCP ports 8080 and 443443 only. The Network ACLs associated with both subnets allow all traffic.

The administrator notices that no mirrored traffic is being received by the monitoring tool.

Which two modifications must the administrator make to resolve this issue and enable successful packet mirroring?

Select all that apply

Show answer & explanation

Answer: Modify the outbound rules of the t2.mediumt2.medium instance's Security Group to permit UDP port 47894789 traffic to the monitoring tool.; Change the application server's instance type from t2.mediumt2.medium to a Nitro-based instance type, such as t3.mediumt3.medium.

Answer

To resolve the issue, the administrator must change the application server's instance type from a Xen-based t2.mediumt2.medium to a Nitro-based instance type (such as t3.mediumt3.medium) and modify the outbound rules of the source instance's Security Group to permit UDP port 47894789 traffic to the monitoring tool.
VPC Traffic Mirroring requires Nitro-based instances (such as t3.mediumt3.medium) for the source. Additionally, mirrored traffic is encapsulated in VXLAN headers (UDP port 47894789) and is subject to the security group rules of the mirror source. Therefore, the source instance's Security Group must allow outbound UDP port 47894789 traffic.

Step-by-Step Solution

1
Evaluate source instance hardware platform support for VPC Traffic Mirroring.
Identify that the t2.mediumt2.medium instance type is Xen-based and does not support Traffic Mirroring as a source.
VPC Traffic Mirroring sources must be Nitro-based instance types.
2
Analyze security group rules on the mirror source ENI.
Identify that the outbound Security Group rules on the source instance block UDP port 47894789 traffic.
Mirrored traffic is encapsulated in VXLAN (UDP port 47894789) and is evaluated against the source instance's stateful Security Group.
3
Formulate remediation steps for the identified blockages.
Upgrade the instance type to a Nitro-based type (e.g., t3.mediumt3.medium) and update the Security Group rules to allow outbound UDP 47894789 traffic.
Both hardware support and security group path clearance are required for mirrored packets to reach the target.

Key Concept

VPC Traffic Mirroring Requirements and Security Group Constraints
Question 832Question →

A SysOps Administrator is setting up an application on an Amazon EC2 instance in a custom VPC. To allow inbound SSH traffic from the administrator's IP address, the administrator adds an inbound rule to the security control. The administrator wants to ensure that the return outbound traffic from the instance back to the administrator's IP address is automatically permitted without having to define any additional outbound rules. Which security control should the administrator use to meet this requirement?

Show answer & explanation

Answer: Security Groups

Answer

Security Groups
Security Groups are stateful security controls that operate at the instance level. When an inbound rule is added to allow SSH traffic, the Security Group automatically allows the return outbound traffic back to the client, regardless of any outbound rules configured in the Security Group.

Step-by-Step Solution

1
Identify the requirement for return traffic to be automatically permitted based on allowed inbound traffic.
This indicates a stateful security control.
Stateful firewalls automatically allow return traffic for any established connection without needing explicit rules in the opposite direction.
2
Evaluate the stateful nature of VPC security features.
Security groups are stateful, whereas Network ACLs are stateless.
Choosing security groups allows return traffic automatically, satisfying the SysOps Administrator's requirement.

Key Concept

Stateful vs Stateless VPC Security Controls
Question 833Question →

An enterprise uses an AWS Transit Gateway to connect multiple VPCs to their on-premises network. The primary path is a 10 Gbps10\text{ Gbps} AWS Direct Connect connection via a Transit VIF associated with a Direct Connect gateway attached to the Transit Gateway. A Site-to-Site VPN connection is established directly to the Transit Gateway as a backup path. Both paths advertise the corporate network range of 172.16.0.0/12172.16.0.0/12 using BGP.

During a failover test, a SysOps administrator disables the BGP session on the Direct Connect connection. However, traffic destined for the corporate network is dropped instead of failing over to the backup Site-to-Site VPN. Inspection of the Transit Gateway route table reveals a manually configured static route for 172.16.0.0/12172.16.0.0/12 pointing to the Direct Connect gateway attachment.

Which two actions must the SysOps administrator take to resolve this issue and ensure automatic failover to the VPN connection? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable route propagation for both the Direct Connect gateway attachment and the Site-to-Site VPN attachment in the Transit Gateway route table.; Delete the static route for 172.16.0.0/12172.16.0.0/12 from the Transit Gateway route table.

Answer

Enable route propagation for both the Direct Connect gateway attachment and the Site-to-Site VPN attachment in the Transit Gateway route table, and delete the static route for the on-premises range from the Transit Gateway route table.
The correct options are deleting the manual static route and enabling route propagation for both attachments. In AWS Transit Gateway, static routes always take precedence over propagated routes. When a static route exists, traffic is sent to the target attachment regardless of the state of the underlying BGP session, resulting in blackholed traffic if the link is down. Deleting the static route allows dynamic routing to take over. Once the static route is removed, enabling route propagation ensures that both paths are dynamically learned. AWS Transit Gateway automatically prefers Direct Connect gateway attachments over Site-to-Site VPN attachments when both advertise the same prefix, meaning the Direct Connect path will be used under normal conditions, and traffic will fail over to the VPN path only if the Direct Connect BGP session goes down.

Step-by-Step Solution

1
Analyze the routing precedence in the Transit Gateway route table.
Identify that the manual static route for 172.16.0.0/12172.16.0.0/12 takes precedence over any dynamically propagated routes, preventing traffic from failing over when the Direct Connect BGP session goes down.
Static routes always override propagated routes in AWS Transit Gateway routing tables.
2
Remove the static routing constraint.
Delete the static route for 172.16.0.0/12172.16.0.0/12 pointing to the Direct Connect gateway attachment.
Removing the static route allows dynamic routing protocols (BGP) to dictate path selection.
3
Configure dynamic route propagation.
Enable route propagation for both the Direct Connect gateway attachment and the Site-to-Site VPN attachment in the Transit Gateway route table.
Enabling propagation allows the TGW to dynamically add and remove the routes based on BGP status. Under normal conditions, TGW automatically prefers Direct Connect gateway attachments over Site-to-Site VPN attachments for identical prefixes.

Key Concept

AWS Transit Gateway Routing Precedence and Dynamic Failover
Question 834Question →

A company's SysOps administrator is reviewing the monthly AWS billing report and notices high charges under 'EC2-Other' due to NAT Gateway data processing fees and cross-Availability Zone (cross-AZ) billing. The application architecture consists of EC2 instances hosted in private subnets across three Availability Zones (`us-west-2a`, `us-west-2b`, and `us-west-2c`) within a single VPC in the `us-west-2` Region. These instances upload approximately 80 TB80\text{ TB} of data monthly to an Amazon S3 bucket located in the same Region. Currently, the VPC is configured with a single NAT Gateway in `us-west-2a`, and all private subnet route tables direct default outbound traffic (0.0.0.0/00.0.0.0/0) to this NAT Gateway. Which of the following is the most cost-effective solution to eliminate these data transfer charges while keeping the instances within private subnets?

Show answer & explanation

Answer: Create an Amazon S3 Gateway VPC Endpoint, associate it with the route tables of all private subnets across the three Availability Zones, and ensure the S3 bucket policy permits access from the VPC.

Answer

Create an Amazon S3 Gateway VPC Endpoint, associate it with the route tables of all private subnets across the three Availability Zones, and ensure the S3 bucket policy permits access from the VPC.
The correct option is to create a S3 Gateway VPC Endpoint and associate it with the private subnets' route tables. Amazon S3 Gateway Endpoints are a free feature that routes S3 traffic directly over the AWS internal network, avoiding both NAT Gateway data processing fees ($0.045/GB) and cross-AZ charges.

Step-by-Step Solution

1
Analyze the current data path and cost components.
The current path routes S3 traffic from all private subnets (including us-west-2b and us-west-2c) to a single NAT Gateway in us-west-2a. This incurs cross-AZ charges (0.01/GBineachdirection)andNATGatewayprocessingcharges(0.01/GB in each direction) and NAT Gateway processing charges ( 0.045/GB).
Identifying where the data transfer fees originate allows us to target them for optimization.
2
Evaluate the cost of alternative routing mechanisms for Amazon S3 traffic.
Gateway VPC Endpoints for S3 are free of charge (both hourly and data processing fees), whereas Interface VPC Endpoints charge hourly rates plus 0.01/GBprocessingfees,andNATGatewayschargehourlyratesplus0.01/GB processing fees, and NAT Gateways charge hourly rates plus 0.045/GB processing fees.
Comparing available options ensures the most cost-effective solution is selected.
3
Determine the required route table modifications.
The Gateway VPC Endpoint must be associated with the route tables of the private subnets containing the EC2 instances so that traffic destined for S3 is routed directly through the endpoint rather than the default route to the NAT Gateway.
If the route tables are not updated, traffic will continue to route through the NAT Gateway, resulting in no cost savings.

Key Concept

Using Gateway VPC Endpoints to optimize data transfer costs for Amazon S3 traffic within a VPC.
Question 835Question →

An organization has deployed an Application Load Balancer (ALB) in a public subnet to distribute traffic to a fleet of Amazon EC2 web instances residing in a private subnet. The public subnet CIDR is 10.0.1.0/2410.0.1.0/24 and the private subnet CIDR is 10.0.2.0/2410.0.2.0/24.

The security controls are configured as follows:
- The ALB's security group allows inbound TCP traffic on ports 8080 and 443443 from 0.0.0.0/00.0.0.0/0, and allows all outbound traffic.
- The EC2 instances' security group allows inbound TCP traffic on ports 8080 and 443443 from the ALB's security group.
- The Network ACL (NACL) for the private subnet has an inbound rule allowing TCP traffic on ports 8080 and 443443 from 10.0.1.0/2410.0.1.0/24, and an outbound rule allowing all traffic to 0.0.0.0/00.0.0.0/0.
- The Network ACL (NACL) for the public subnet has inbound rules allowing TCP traffic on ports 8080 and 443443 from 0.0.0.0/00.0.0.0/0. However, its outbound rules are restricted to only allow TCP traffic on ports 8080 and 443443 to 0.0.0.0/00.0.0.0/0.

Users report that connection attempts to the ALB timeout.

Which of the following changes will resolve this issue and restore connectivity?

Show answer & explanation

Answer: Modify the public subnet's outbound Network ACL rules to allow outbound TCP traffic to the ephemeral port range 10241024-6553565535 for destination 0.0.0.0/00.0.0.0/0.

Answer

Modify the public subnet's outbound Network ACL rules to allow outbound TCP traffic to the ephemeral port range 10241024-6553565535 for destination 0.0.0.0/00.0.0.0/0.
Network ACLs are stateless, meaning that both inbound and outbound traffic must be explicitly allowed. When a client initiates a connection to the Application Load Balancer, the source port of the client's request is a random ephemeral port (typically 10241024-6553565535). The return traffic from the ALB back to the client will have the client's ephemeral port as the destination port. Because the public subnet's outbound Network ACL only allows outbound traffic on ports 8080 and 443443, the return traffic to the client's ephemeral port is blocked. Allowing outbound TCP traffic to the range 10241024-6553565535 resolves this issue.

Step-by-Step Solution

1
Trace the lifecycle of a client connection to the ALB and identify the ports involved.
The client initiates a connection from a random ephemeral port (typically 10241024-6553565535) to the ALB on port 8080 or 443443.
Understanding the source and destination ports in both directions is critical for troubleshooting stateless firewalls like Network ACLs.
2
Evaluate the stateful vs. stateless behavior of the security groups and Network ACLs in the path.
The security groups are stateful and automatically allow return traffic. The Network ACLs are stateless, meaning outbound return traffic must be explicitly allowed. The public subnet's outbound Network ACL restricts outbound traffic to destination ports 8080 and 443443 only.
This restriction blocks the response packets sent from the ALB back to the client's ephemeral port, causing the client connection to time out.
3
Formulate a rule modification to permit the blocked return traffic.
The public subnet's outbound Network ACL must be updated to allow outbound TCP traffic to the destination range 10241024-6553565535 for 0.0.0.0/00.0.0.0/0.
This allows the stateless Network ACL to permit return traffic back to the client's ephemeral ports.

Key Concept

Stateless Network ACL rule evaluation and ephemeral port requirements
Question 836Question →

An organization manages its cloud infrastructure using AWS Organizations with consolidated billing enabled. A SysOps administrator is tasked with optimizing compute costs for the following two distinct workloads:

1. A development workload consisting of Amazon EC2 m5.largem5.large instances that will be migrated to a serverless architecture using AWS Fargate and AWS Lambda over the next three months.
2. A production workload consisting of a steady-state fleet of Amazon EC2 c6i.xlargec6i.xlarge instances in the us−west−2us-west-2 region that is expected to remain unchanged for the next 1212 months.

Which of the following purchasing strategies should the administrator implement to maximize savings while minimizing the risk of unused commitments? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Purchase a Compute Savings Plan to cover the development workload that is migrating to AWS Fargate and AWS Lambda.; Purchase EC2 Instance Savings Plans targeting the c6ic6i instance family in the us−west−2us-west-2 region for the steady-state production workload.

Answer

Purchase a Compute Savings Plan to cover the development workload that is migrating to AWS Fargate and AWS Lambda, and purchase EC2 Instance Savings Plans targeting the c6ic6i instance family in the us−west−2us-west-2 region for the steady-state production workload.
Purchasing a Compute Savings Plan is correct for the development workload because Compute Savings Plans apply automatically to EC2, AWS Fargate, and AWS Lambda, regardless of changes in instance family, size, region, or compute service. Purchasing EC2 Instance Savings Plans targeting the c6ic6i instance family in us−west−2us-west-2 is correct for the production workload because it offers the highest discount for steady-state instances of a specific family in a single region when no changes to the family or region are expected.

Step-by-Step Solution

1
Analyze the development workload requirements.
The development workload is currently on EC2 but is migrating to Fargate and Lambda. Compute Savings Plans are required here because they apply to EC2, Fargate, and Lambda, providing the necessary flexibility as the compute type changes.
Choosing a plan with broader scope avoids wasted commitments during architecture shifts.
2
Analyze the production workload requirements.
The production workload is steady-state, uses c6ic6i instances in us−west−2us-west-2, and will not change. EC2 Instance Savings Plans offer higher savings than Compute Savings Plans for a specific instance family in a specific region, making them the most cost-effective choice for this workload.
Matching the commitment type to the stability of the workload yields the highest discount.
3
Evaluate the incorrect options based on scope limits.
EC2 Instance Savings Plans and Reserved Instances do not apply to Lambda or Fargate services. Standard RIs cannot be converted to serverless commitments. Disabling consolidated billing sharing limits account scope but does not restrict resource type application.
Understanding scope boundaries helps identify and eliminate invalid configurations.

Key Concept

Selecting the optimal AWS Savings Plans type based on workload flexibility and stability requirements.
Estimated Time:2m 0s
Question 837Question →

A SysOps Administrator is configuring a Gateway Endpoint for Amazon S3 to allow Amazon EC2 instances in a private subnet to access S3 buckets. Which configuration steps must the administrator complete to ensure that the EC2 instances can communicate with Amazon S3 through the endpoint? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Select the Route Table associated with the private subnet when creating the Gateway Endpoint to automatically add the route targeting the endpoint.; Ensure the Security Group associated with the EC2 instances allows outbound HTTPS traffic to the Amazon S3 prefix list.

Answer

Selecting the Route Table associated with the private subnet during endpoint creation, and ensuring the Security Group associated with the EC2 instances allows outbound HTTPS traffic to the Amazon S3 prefix list.
Establishing connectivity to Amazon S3 via a Gateway Endpoint requires associating the Endpoint with the private subnet's Route Table. This automatically inserts a route directing traffic for the S3 prefix list to the Gateway Endpoint. Additionally, the EC2 instance's Security Group must allow outbound HTTPS traffic to the S3 prefix list to permit the egress connection.

Step-by-Step Solution

1
Associate the Route Table during Gateway Endpoint creation.
A route targeting the Gateway Endpoint (vpce-xxxxxx) with the destination set to the Amazon S3 prefix list is automatically added to the subnet's Route Table.
This directs traffic destined for Amazon S3 through the Gateway Endpoint instead of routing it over the public internet.
2
Configure the EC2 instance Security Group.
Outbound HTTPS traffic is permitted to the S3 prefix list.
Security Groups are stateful; allowing outbound traffic to the prefix list ensures that the instances can successfully initiate connections to Amazon S3.

Key Concept

Gateway Endpoints use Route Table prefix lists to direct traffic to AWS services and do not support Security Groups, unlike Interface Endpoints which use Elastic Network Interfaces and Security Groups.
Question 838Question →

A company runs a web application on Amazon EC2 instances inside a private subnet. The instances are registered to a target group of an Application Load Balancer (ALB) located in a public subnet. The application is configured to run on port 8080, and the target group's health check is configured to use the default settings (HTTP on traffic-port at path '/'). Recently, the Security team implemented a new custom Network Access Control List (NACL) on the private subnet with an inbound rule allowing TCP port 8080 from the public subnet CIDR, and an outbound rule allowing TCP port 8080 to the public subnet CIDR. Additionally, the application was updated to redirect all unauthenticated requests to '/login' via an HTTP 302 response code. Following these changes, the ALB reports all EC2 instances as unhealthy. To resolve this issue and restore the healthy status of the targets, which set of actions must a SysOps Administrator take?

Show answer & explanation

Answer: Configure a dedicated, unauthenticated health check endpoint on the application that returns HTTP 200, update the target group health check path to point to this endpoint, and modify the private subnet's outbound network ACL to allow TCP traffic on ephemeral ports (1024-65535) to the public subnet CIDR.

Answer

Configure a dedicated, unauthenticated health check endpoint on the application that returns HTTP 200, update the target group health check path to point to this endpoint, and modify the private subnet's outbound network ACL to allow TCP traffic on ephemeral ports (1024-65535) to the public subnet CIDR.
Configuring a dedicated, unauthenticated endpoint that returns HTTP 200 and setting the target group to health check this endpoint resolves the response code mismatch caused by the HTTP 302 redirect to the login page. Furthermore, because Network Access Control Lists (NACLs) are stateless, they require return traffic to be explicitly allowed. Since the Application Load Balancer initiates health check connections using ephemeral ports, the private subnet's outbound NACL must allow traffic on ports 1024-65535 to the public subnet CIDR to allow response packets to reach the load balancer.

Step-by-Step Solution

1
Diagnose the application-level health check failure caused by the redirect.
Identify that the application redirects unauthenticated traffic to '/login' returning an HTTP 302 status code. Since the target group health check defaults to expecting HTTP 200, this results in a response code mismatch.
To pass health checks, the load balancer needs to receive a response code that matches its configured matcher (by default, HTTP 200).
2
Analyze the stateless network ACL rules on the private subnet.
Identify that the outbound NACL rule is configured to only allow port 8080. Since network ACLs are stateless, they must explicitly allow outbound return traffic. When the load balancer initiates a health check, it uses a random ephemeral port (1024-65535) as the source. The response from the EC2 instance is destined for this ephemeral port, which is blocked by the outbound NACL.
Stateless firewalls require explicit rules in both directions; outbound rules must permit return traffic to the ephemeral ports of the client.
3
Implement the resolution steps for both application and network layers.
Create a dedicated, unauthenticated '/healthz' endpoint on the EC2 instances that returns HTTP 200. Configure the target group to use this new path. Then, modify the private subnet's outbound network ACL rule to allow TCP traffic on ephemeral ports (1024-65535) to the public subnet CIDR.
This dual-remediation resolves the redirect issue at the application layer and allows the return traffic to flow back to the load balancer at the network layer.

Key Concept

Stateless Network Access Control Lists (NACLs) ephemeral ports and Application Load Balancer health check matcher configuration.
Estimated Time:3m 0s
Question 839Question →

A startup is optimizing its AWS costs for a single-account workload that consists of:

* A steady-state database running on a single Amazon RDS db.m6g.xlargedb.m6g.xlarge instance.
* An application tier running on Amazon EC2 c6i.largec6i.large instances, which the startup plans to migrate to graviton-based c7g.largec7g.large instances in the next quarter.
* Microservices running on AWS Fargate.

Which two purchasing strategies should a SysOps administrator recommend to achieve the highest cost savings while maintaining operational flexibility? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Purchase a Compute Savings Plan to cover the EC2 instances and AWS Fargate tasks.; Purchase a Reserved Instance for the Amazon RDS database.

Answer

Purchase a Compute Savings Plan to cover the EC2 instances and AWS Fargate tasks, and purchase a Reserved Instance for the Amazon RDS database.
A Compute Savings Plan provides the required flexibility because it applies automatically to both Amazon EC2 and AWS Fargate, regardless of instance family, size, or region. This accommodates the planned migration from the c6i family to the c7g family. Because Savings Plans do not support Amazon RDS, a separate Reserved Instance is needed to optimize the database tier.

Step-by-Step Solution

1
Analyze the compute requirements and migration plans for the application tier and containerized tasks.
Identify that the EC2 instances are transitioning from the c6i family to the c7g family, and AWS Fargate is used for microservices.
To choose a commitment option that permits instance family changes and covers containerized compute.
2
Evaluate Savings Plans options against the compute components.
Determine that a Compute Savings Plan covers EC2 and Fargate across any instance family, accommodating the upcoming c6i to c7g migration.
EC2 Instance Savings Plans would restrict the discount to the c6i family, leading to wasted commitment post-migration.
3
Identify the optimization strategy for the database tier.
Determine that Amazon RDS is not eligible for Savings Plans, and select a database Reserved Instance.
RDS requires database Reserved Instances to receive commitment-based discounts.

Key Concept

Operational scope and flexibility differences between Compute Savings Plans, Instance Savings Plans, and Reserved Instances.
Question 840Question →

A company connects its multi-VPC environment using an AWS Transit Gateway. The primary connection to the corporate datacenter is a 1 Gbps1\text{ Gbps} AWS Direct Connect (DX) connection using a Transit Virtual Interface (Transit VIF) through a Direct Connect Gateway (DXGW). A Site-to-Site VPN is configured directly to the Transit Gateway as a backup path. The on-premises database subnet resides in the CIDR block `172.16.100.0/24172.16.100.0/24`, which belongs to the larger corporate network range of `172.16.0.0/12172.16.0.0/12`. During a routine audit, a SysOps administrator notices that database-bound traffic is routing over the VPN tunnel instead of the DX connection, even though the DX connection is fully operational and has low utilization. In the Transit Gateway route table, the administrator identifies a propagated route for `172.16.0.0/12172.16.0.0/12` pointing to the DXGW and a propagated route for `172.16.100.0/24172.16.100.0/24` pointing to the VPN attachment.

Which two actions should the SysOps administrator take to ensure that traffic to the database subnet primarily uses the Direct Connect connection and only fails over to the VPN if the Direct Connect connection becomes unavailable? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Advertise the `172.16.100.0/24172.16.100.0/24` prefix over the Direct Connect BGP session from the on-premises router.; Configure the customer gateway to only advertise the summarized `172.16.0.0/12172.16.0.0/12` prefix over the Site-to-Site VPN BGP session, removing the `172.16.100.0/24172.16.100.0/24` prefix advertisement.

Answer

To direct database traffic over the Direct Connect connection as the primary path, the administrator must either advertise the specific database subnet prefix (172.16.100.0/24172.16.100.0/24) over the Direct Connect BGP session, or stop advertising that specific prefix over the VPN BGP session so that both paths only advertise the summarized range (172.16.0.0/12172.16.0.0/12).
AWS Transit Gateway uses Longest Prefix Match (LPM) to route traffic. Because the VPN was advertising a more specific prefix (172.16.100.0/24172.16.100.0/24) than the Direct Connect (172.16.0.0/12172.16.0.0/12), traffic preferred the VPN. To resolve this, the prefix lengths must be equal on both paths. This is achieved by either advertising the specific prefix (172.16.100.0/24172.16.100.0/24) over the Direct Connect BGP session or by only advertising the summary prefix (172.16.0.0/12172.16.0.0/12) over the VPN. Once prefix lengths are equal, the Transit Gateway applies its default preference order, which prioritizes Direct Connect Gateway over VPN.

Step-by-Step Solution

1
Analyze the route advertisements and determine that Longest Prefix Match (LPM) is taking precedence because the VPN is advertising a more specific CIDR (172.16.100.0/24172.16.100.0/24) than the Direct Connect path (172.16.0.0/12172.16.0.0/12).
Confirmed that the mismatch in prefix length is bypassing the default preference for Direct Connect.
AWS Transit Gateway evaluates prefix length first before evaluating attachment type preferences.
2
Align the prefix lengths by either advertising the specific subnet (172.16.100.0/24172.16.100.0/24) over Direct Connect, or removing the specific advertisement from the VPN so both paths use the summary (172.16.0.0/12172.16.0.0/12).
Prefix lengths are matched on both the Direct Connect and VPN paths.
Matching the prefix lengths forces Transit Gateway to use the attachment type hierarchy for routing decisions.
3
Verify that Transit Gateway defaults to prioritizing the Direct Connect Gateway (DXGW) attachment over the VPN attachment for identical prefixes.
Traffic correctly routes over the Direct Connect connection and fails over to the VPN only if the Direct Connect connection goes down.
Direct Connect Gateway has a higher default priority than Site-to-Site VPN in Transit Gateway route tables.

Key Concept

AWS Transit Gateway path selection logic which prioritizes Longest Prefix Match (LPM) over BGP attributes and attachment preferences, followed by a preference for Direct Connect Gateway over VPN for equal prefixes.
PreviousPage 42 / 49Next
All practice questions — AWS Certified SysOps Administrator - Associate | Examkin