Practice Test #1

Running a cron-based script on EC2 in each account creates significant administrative overhead (instances, patching, IAM, scheduling, scaling). A 5-minute interval is not immediate detection and can allow policy violations to persist. Logging to RDS adds cost and management and still doesn’t provide native compliance reporting. This approach is operationally heavy and not aligned with AWS managed governance patterns.

Lambda reduces server management, but the option describes “programmatically checks,” implying polling rather than event-driven detection. Polling still isn’t immediate and requires scheduling and custom state storage. OpenSearch per account is expensive and operationally complex, and it doesn’t provide the straightforward compliance history and audit views that AWS Config provides. SAM helps deployment, but governance/reporting remains custom.

GuardDuty is a threat detection service and does not provide a standard finding type for NAT gateway creation (the referenced finding type is not a typical GuardDuty taxonomy). Even if events were captured, storing runtime logs in S3 is not the same as compliance history with rule evaluations and timelines. This option also mixes services in a way that is less reliable for compliance governance than AWS Config.

Option B uses only two 10 Gbps connections, one per Direct Connect location, each terminating on a different router. Although the bandwidth is sufficient, the design has only one circuit per location, so a single circuit failure removes all connectivity through that location. This provides less circuit-level resiliency than a four-connection design and does not align as well with a requirement to withstand circuit failures. AWS best practice for maximum resiliency is to use multiple connections across multiple locations and routers.

Option C provides four 1 Gbps connections for a total of 4 Gbps only during normal operation. If a single circuit fails, available bandwidth drops to 3 Gbps, which no longer meets the 4 Gbps transfer requirement. Likewise, if a router fails and two circuits are attached to that router, only 2 Gbps remains. Therefore, this option is resilient from an availability perspective but does not preserve the required throughput during the specified failure scenarios.

Option D provides only two 1 Gbps connections, for a maximum aggregate throughput of 2 Gbps. That is insufficient to meet the stated 4 Gbps peak traffic requirement even before considering any failures. In addition, losing one circuit or one router would reduce capacity even further. This option fails both the bandwidth and resiliency requirements.

Not the most operationally efficient. A DynamoDB-driven Lambda updater requires building and maintaining custom automation, IAM roles, error handling, and deployment in every account. It introduces operational overhead and potential drift if the function fails or is misconfigured. While it can work, it is less scalable and less elegant than using a native VPC construct designed for centrally managed CIDR allow lists.

This option is less efficient because it adds EventBridge and Lambda to update security groups whenever the prefix list changes, which reintroduces custom orchestration and operational overhead. If a prefix list is the chosen abstraction, the goal should be to consume it directly where supported rather than trigger code to rewrite security group rules. It also omits the necessary cross-account sharing mechanism, so it does not fully solve the multi-account central-management requirement.

Similar to option A, this is a custom automation approach with higher operational burden. Storing CIDRs in S3 and running Lambda to update security groups across accounts requires per-account deployment, cross-account permissions, and robust handling for failures and concurrency. It is not as efficient or scalable as using a managed prefix list shared via AWS RAM, which is purpose-built for this use case.

Incorrect. AWS Site-to-Site VPN is for connecting networks (e.g., on-premises to VPC), not for individual remote users like Client VPN. Migrating users to Site-to-Site VPN would require new customer gateway devices/configuration and does not directly address geolocation; it also causes significant service interruption and operational change compared to adjusting Client VPN routing.

Incorrect. Removing the 0.0.0.0/0 outbound rule from the Client VPN endpoint security group does not solve the routing problem that causes geolocation issues. It would likely break legitimate outbound connectivity from VPN clients to internal resources (and possibly required AWS services) and introduces avoidable disruption. Geolocation is driven by egress path/IP, not SG rules.

Incorrect. Deleting and recreating the Client VPN endpoint in a different VPC is highly disruptive (new endpoint, associations, authorization rules, client configuration updates). It may change the egress IP range and thus geolocation, but it does not address the root cause (full-tunnel routing of internet traffic through AWS). Split-tunnel and route changes are the minimal-interruption fix.

CloudFront distributions with NLB origins plus Route 53 weighted routing can provide some traffic shifting, but CloudFront is not intended as a general TCP/UDP front door for arbitrary application protocols behind NLB. Also, weighted DNS does not inherently minimize jitter/first-byte latency because traffic still traverses the public internet after DNS resolution. This option mixes services in a way that doesn’t best meet the TCP/UDP and jitter requirements.

S3 Transfer Acceleration only accelerates transfers to and from Amazon S3 using edge locations; it does not front an EC2/NLB-based multi-tier application and does not provide TCP/UDP listener routing to NLB endpoints. It also does not offer the required multi-Region traffic dials for phased rollouts of an application stack. This is a service mismatch.

CloudFront origin groups are mainly for origin failover (primary/secondary) and are oriented around HTTP/HTTPS content delivery rather than generic TCP/UDP application traffic. Route 53 latency routing can steer users to lower-latency Regions, but it cannot precisely control rollout percentages like Global Accelerator traffic dials, and it won’t reduce jitter/first-byte latency as effectively as routing over the AWS backbone.

Incorrect. Amazon CloudFront is primarily a CDN for HTTP/HTTPS and does not provide a general-purpose UDP acceleration path to an NLB origin. While CloudFront can front certain TCP-based origins for web delivery, it is not designed to proxy proprietary UDP sensor protocols. For UDP acceleration and static anycast ingress, Global Accelerator is the appropriate AWS service.

Incorrect. Route 53 failover routing is active-passive and is intended for availability when the primary endpoint becomes unhealthy. It does not optimize for latency and will not address intermittent packet loss when the primary endpoint remains healthy. Also, “packets are dropped” is not something Route 53 can detect per-flow; DNS failover is coarse-grained and slow relative to UDP telemetry streams.

Incorrect. Enhanced networking with ENA improves EC2 network performance (higher bandwidth, lower latency, higher PPS) once packets reach the instance. The problem described is packet loss in transit over the public internet from South Asia to us-west-2, before traffic arrives at AWS. ENA will not materially improve reliability of the long-distance path or reduce internet routing-related loss.

This option is incorrect because the default ALB listener rule cannot be modified to include conditions such as path-pattern or source-ip. The default rule is always unconditional and is evaluated only after all higher-priority rules have been checked. It also describes forwarding to the management target group when the conditions are not matched, which is the opposite of the desired behavior. Group-level stickiness does not fix the invalid listener-rule design.

This option is wrong because ALB listener rules should use the native source-ip condition rather than inspecting the X-Forwarded-For header. X-Forwarded-For can contain multiple addresses and is not the intended access-control primitive for ALB listener rule matching. The requirement is specifically to restrict access by on-premises source CIDR ranges, which ALB supports directly. While group-level stickiness may be useful, the traffic-matching method here is technically inappropriate.

This option is incorrect because forwarding all requests to the web app target group would prevent the /management path from being routed to the management target group. It also says to disable stickiness, which conflicts with the stateful nature of the management application. A proper ALB configuration needs a specific higher-priority rule for /management and a separate default action for everything else. This option does not implement the required listener-rule combination.

TGW improves VPC-to-VPC scalability, but using a Site-to-Site VPN between TGW and the SD-WAN transit VPC still relies on VPN tunnel constructs and often more manual routing (static routes or limited dynamic behavior depending on design). It can work, but it is not the lowest operational overhead compared to TGW Connect’s purpose-built SD-WAN integration and BGP-based dynamic route exchange.

VPC peering does not scale well for this use case: it is non-transitive (a key limitation when trying to build a hub), requires managing many peering connections as VPC count grows, and increases route table entries per peer. It also doesn’t inherently reduce operational overhead versus the current model and can reintroduce route table scaling challenges.

This mixes two incompatible scaling approaches: VPC peering for VPC connectivity (which is non-transitive and operationally heavy at scale) and TGW Connect for SD-WAN integration. Even if SD-WAN integration is improved, the VPC-to-VPC and VPC-to-hub connectivity would still suffer from peering’s scaling/management limitations, so it does not meet the overall requirement with the least operational overhead.

Incorrect. VPC Reachability Analyzer is the right tool for checking paths within a VPC, but the detection mechanism is wrong. Network configuration changes (security groups, NACLs, route tables) are control-plane API calls recorded in AWS CloudTrail, not “logged in CloudWatch” by default. While CloudTrail logs can be delivered to CloudWatch Logs, the standard and most direct event trigger is EventBridge matching CloudTrail events.

Incorrect. Transit Gateway Network Manager Route Analyzer is not the best fit for validating connectivity between resources within a single VPC, especially when the failure could be caused by security groups or NACLs. Additionally, the option relies on changes being “logged in CloudWatch,” which is not the primary source for configuration-change events. This combination does not meet the stated requirement as cleanly as CloudTrail + Reachability Analyzer.

Incorrect. CloudTrail is the correct change-detection source, but Transit Gateway Network Manager Route Analyzer is the wrong analysis tool for the requirement. The question asks for connectivity verification between critical application resources within a single VPC after changes to SG/NACL/route tables. VPC Reachability Analyzer evaluates those VPC constructs directly; TGW Route Analyzer is focused on TGW route propagation/associations and attachment routing, not full VPC reachability semantics.