You save $69.98
Two Transit Gateways are peered across Regions A and B. A VPC in Region A can reach the local TGW, but traffic to a service subnet in Region B fails. The peering attachment is AVAILABLE and both VPC subnet route tables already point to their local TGW. The operator must verify that the inter-Region forwarding path AND its return path are actually provisioned. Which evidence is sufficient?
TGW peering does not propagate remote routes. Both regional TGW routing tables need the appropriate static routes, and successful bidirectional traffic confirms the packet path.
Attachment state and a one-way route cannot prove that the Region B return path is configured.
Routes from subnets to the local TGW cannot substitute for static routes across a peering attachment.
TGW peering attachments do not dynamically propagate remote VPC routes; toggling propagation is not proof of peering reachability.
A shared Transit Gateway carries production, development and vendor traffic that must remain separated by explicit trust policy.
Which technical explanation best accounts for the network behavior described?
Transit Gateway attachment association and propagation control which routed prefixes each network segment can reach, independent of VPC security-group rules. A direct check is to separate Transit Gateway route tables by trust boundary and allow only the required attachments and prefix propagations and observe the corresponding path.
AWS WAF inspects supported HTTP request attributes at layer seven and can count, block or challenge requests according to web ACL rules. That is a valid account of aws waf managed and rate-limiting rules, but it does not explain the cross-account transit gateway route segmentation behavior in the scenario.
Firewall Manager coordinates organization-wide firewall policies for eligible resources, while each resource's security behavior still requires policy scope and remediation. That is a valid account of firewall manager centralized security policy, but it does not explain the cross-account transit gateway route segmentation behavior in the scenario.
PrivateLink allows authorized VPC consumers to access a published endpoint service without broad VPC peering or transitive network reachability. That is a valid account of privatelink least-privilege service boundary, but it does not explain the cross-account transit gateway route segmentation behavior in the scenario.
An engineer adds a more-specific BGP advertisement 10.40.8.0/24 through the backup VPN while Direct Connect announces 10.40.0.0/16. Unexpectedly, traffic to 10.40.8.0/24 uses VPN even though the Direct Connect circuit is healthy. What routing principle is most relevant?
Longest-prefix matching is evaluated before many path-preference comparisons for unequal destination masks. The VPN /24 can win over the Direct Connect /16.
A blanket transport preference cannot be assumed over a more-specific matching destination.
DNS caching does not choose the next hop for an IP destination prefix.
WAF filters HTTP requests, not hybrid BGP route lookup.
An engineer created VPC peering between two nonoverlapping VPCs, and both sides accepted it. The instances still cannot connect because neither VPC route table targets the peering connection for the other CIDR. What should be implemented?
VPC peering requires matching data-plane routes on each side; acceptance alone creates no automatic route.
Peering does not permit transitive reachability through an intermediate peer.
S3 transport does not configure VPC peer routes.
Organizations policies alone cannot install missing VPC routes.
A regulated account has deployed AWS Network Firewall in an inspection VPC, but one application subnet’s default route still points directly at its NAT gateway instead of the intended firewall endpoint path. Test traffic from that subnet reaches the internet, and the central firewall flow log has no matching entry. Which exposure does the misconfigured route create?
Inspection depends on the traffic actually being routed through the relevant firewall endpoint; deploying the resource alone does not force coverage.
Longer log retention cannot capture packets that never reach the firewall endpoint.
Rule ordering matters only to packets forwarded through the firewall; the subnet bypasses inspection.
Capacity is not the problem: the misconfigured route prevents those packets from reaching the endpoint.
A public Route 53 DNSSEC-signed zone has a valid DNSKEY set but an incorrect DS digest remains at the parent after a key rollover. Users relying on validating resolvers receive SERVFAIL; nonvalidating clients still obtain addresses. Which trust-boundary error is responsible?
A mismatch in DNSSEC delegation causes validators to reject otherwise present signed records.
An ALB TLS listener is unrelated to the cryptographic parent-to-child DNSSEC chain.
TTL size does not make a stale parent DS value match current keys.
UDP 500 is associated with IKE, not public DNSSEC chain validation.
An engineer sees VPC Flow Log records showing ACCEPT for a TCP connection, but the receiving application still times out. What is the most defensible interpretation of the ACCEPT action?
Flow Log ACCEPT indicates a network-level allowance observation; higher layers or the reverse path can still fail.
Flow Logs do not verify an application-level response.
Flow Logs contain no such per-connection IAM authentication verdict.
An ACCEPT entry does not validate the original DNS lookup or selected destination.
After provisioning a Direct Connect private virtual interface, its AWS-side BGP session becomes Established and advertised routes appear. Yet connectivity to a private EC2 subnet fails only in the return direction because that subnet’s route table lacks the campus prefix. What should be fixed?
BGP reachability upstream does not bypass the subnet’s need for a valid return route to the on-premises prefix.
The BGP session already works; removing it cannot fix the missing VPC return route.
Application certificate identity does not provide an absent IP route.
Content authorization is unrelated to VPC return-path routing.
A subnet's newly added static prefix route directs traffic to an unexpected gateway after a TGW attachment change.
Which AWS networking configuration best addresses this specific requirement?
IP routing selects a matching destination prefix under the service's route-selection rules; changing security groups cannot override the selected next hop. The proposed change can be checked by whether a route-table trace shows the approved next hop for the exact destination CIDR and end-to-end probes complete on the return path.
This configuration addresses privatelink endpoint lifecycle restoration, not the aws gateway route-priority and static-route validation requirement. PrivateLink connectivity depends on accepted service endpoints and healthy provider backends without granting consumer VPCs general routes.
This configuration addresses hybrid route summarization and overlap response, not the aws gateway route-priority and static-route validation requirement. Route aggregation reduces route-table entry counts, but an overly broad summary may route destinations not actually owned by the advertising site.
This configuration addresses vpc endpoint private versus public service reachability, not the aws gateway route-priority and static-route validation requirement. Gateway endpoints provide VPC route targets for supported services such as S3, while interface endpoints expose private service addresses through endpoint ENIs.
A public domain operator needs cryptographic assurance that public DNS records have not been modified in transit to validating resolvers.
Which AWS networking configuration best addresses this specific requirement?
DNSSEC establishes a chain of trust from a parent DS record to the child zone's signing keys, allowing validating resolvers to reject forged answers. The proposed change can be checked by whether a validating resolver accepts signed published records and rejects a deliberately broken test chain as expected.
This configuration addresses split-horizon dns precedence troubleshooting, not the dnssec public-zone validation and signing requirement. VPC Resolver selects eligible private namespaces and forwarding rules based on match and association; public records need not be consulted when a matching private zone exists.
This configuration addresses route 53 resolver inbound endpoint deployment, not the dnssec public-zone validation and signing requirement. An inbound resolver accepts queries from outside the VPC and resolves the associated private namespace without publishing the records to the public internet.
This configuration addresses route 53 resolver outbound rule association, not the dnssec public-zone validation and signing requirement. Resolver forwarding rule selection depends on matching domain names and VPC association; endpoints alone do not select where matching DNS queries go.
A domain registrar still delegates example.org to a legacy DNS provider. A network team creates a complete Route 53 public hosted zone and confirms its authoritative name servers answer correctly when queried directly, but normal internet lookups still see old records. What is missing?
Recursive resolvers discover authoritative servers via delegation, not by searching all hosted zones for a domain name.
Changing zone data does not redirect the parent delegation.
Private zones answer only associated VPC resolvers and do not fix public authority.
An inbound private DNS endpoint is not used by the internet’s delegation chain.
Please check your mailbox for a message from support@examlabs.com and follow the directions.
