You save $69.98
A company has a dedicated Direct Connect circuit with a public virtual interface that reaches AWS public service addresses. Its new requirement is private IP routing to multiple VPCs attached to a Transit Gateway through a Direct Connect gateway. Which VIF type must be provisioned?
Transit VIFs are designed for private connectivity to Transit Gateways through a Direct Connect gateway. A public VIF does not become the private transit attachment merely by advertising new prefixes.
CloudFront and ALBs serve application delivery functions; they do not create Direct Connect transit virtual interfaces or route RFC1918 prefixes into multiple attached VPCs.
A public VIF accesses public AWS service IPs, not private routed reachability to a transit gateway VPC fabric. Advertising private CIDRs there does not implement the requested association.
Gateway endpoints are VPC-level route targets for supported AWS services such as S3, not VLAN or BGP virtual interfaces on a Direct Connect circuit.
A team troubleshooting intermittent container-to-database failures has VPC Flow Logs records showing ACCEPT for the tested five-tuple. The application still reports TLS handshake errors. Which conclusion is best supported by the existing evidence?
The observed ACCEPT value narrows the investigation to what the log covers. TLS protocol errors can arise later, so the next test should check application/server TLS logs and transport details rather than claiming end-to-end application success.
Flow Logs ACCEPT is a network-flow decision field, not a record of TLS certificate verification. A connection can pass the relevant network filtering layer and still fail at encryption negotiation.
DNSSEC concerns DNS response authenticity; it is not implicated merely by a successful network-flow ACCEPT entry. The scenario includes an actual TLS handshake error, which needs protocol-specific evidence.
Flow Logs provide aggregated metadata and may omit some traffic; an ACCEPT record does not independently certify every packet's delivery or absence of retransmission. More specific packet and endpoint traces would be needed.
A latency-sensitive payment gateway uses HTTPS listeners on ALBs in two AWS Regions. Corporate customers allowlist exactly two destination IPv4 addresses and cannot refresh firewall rules during a regional failover. Caching responses is prohibited. Which global entry architecture is appropriate?
A standard Global Accelerator supplies fixed anycast IPv4 entry addresses and routes eligible connections toward healthy regional endpoints, including ALBs. It meets the HTTPS and allowlisting requirements without response caching or regional IP changes.
CloudFront is designed for HTTP delivery and caching patterns, rather than the stated fixed-IP non-cacheable HTTPS ingress need. Enabling a long cache TTL would also be unsafe for individual payment requests.
Elastic IP association is not how ALB nodes obtain their addresses. Even regional fixed addresses would not automatically deliver a stable global pair with AWS-managed health-based regional endpoint routing.
Route 53 can influence DNS answers, but it does not give the application exactly two stable global destination IPs. ALB addresses can change, so a DNS-based plan still forces the customers to manage destination addresses.
An MPI research cluster performs frequent small-message exchange between neighboring EC2 workers. All nodes use supported high-performance instances, but ordinary TCP networking is the main barrier to latency objectives. Which AWS network interface technology should the cluster team evaluate?
EFA provides specialized low-latency network behavior for eligible tightly coupled HPC applications and supported operating systems and instances. It targets communication overhead between cluster nodes.
CloudFront caches HTTP objects for web delivery; it cannot accelerate arbitrary per-rank MPI interconnect messages through cache key configuration.
A gateway endpoint provides private routing to supported AWS services like S3, not low-latency direct network interfaces between EC2 HPC compute nodes.
ALB HTTP request routing is not a drop-in message transport for MPI collective communication and introduces layer-seven load balancing rather than optimized node-to-node fabric behavior.
A malware investigation needs the originating EC2 instance ID and DNS hostname requested for suspicious domains in one VPC. Network flow records provide only destination IP metadata, and public authoritative Route 53 logs lack VPC identity. What AWS telemetry directly supports this investigation?
VPC Resolver query logs include queried names and source VPC or resource details, supporting correlation of suspicious lookups to affected internal EC2 workloads.
ALB access logs cover requests through a web load balancer, not general DNS questions originating from EC2 clients to the VPC resolver.
Direct Connect public VIF provides public AWS service reachability, not per-EC2 DNS query telemetry or an automatic logging sensor.
CloudFront access logs report viewer delivery events for its distributions, not internal VPC Resolver name lookups performed by instances.
A branch gateway supports BGP, but an engineer created an AWS Site-to-Site VPN connection using static routing with manually entered branch CIDRs. The company now requires branch prefixes to change without AWS console edits and wants more responsive route withdrawal. Which change best meets the requirement?
A BGP-capable customer gateway can advertise dynamic branch routes and withdraw them on path failure, improving operational flexibility compared with manually maintained static VPN prefixes.
DNS TTL affects domain answer caching, not the static prefix inventory attached to a Site-to-Site VPN. It does not automate branch routing changes.
CloudFront operates at the HTTP delivery edge and cannot carry RFC1918 network prefixes or act as a dynamic Site-to-Site VPN routing peer.
Security groups control permitted traffic at VPC interfaces but do not provide encrypted tunnels, BGP peerings, or network reachability to an on-premises branch.
An organization configures Route 53 Resolver query logging for a security VPC. Queries initiated by a service in another VPC are missing even though DNS resolution works. The logging configuration is not associated with the application VPC. What is the required correction?
Resolver query logging records queries from the associated VPCs. To include the other application VPC, its association with a suitable logging configuration must be established.
An S3 gateway endpoint determines eligible S3 routing from its VPC and does not change Route 53 Resolver query logging scope for peer VPCs.
ALB logs cover application HTTP requests, not the internal DNS resolution events the investigator specifically needs from the application VPC.
Longer TTL causes more cache hits and can reduce logged DNS activity; it does not attach the missing VPC to an existing logging configuration.
An internet-facing EC2 service's security group allows inbound TCP 443 and has no explicit outbound rule for ephemeral return ports. The subnet network ACL has an inbound allow for 443 but denies all outbound ephemeral ports. The HTTPS handshake fails. Which policy change most directly repairs the return path while keeping the instance SG restrictive?
Network ACLs are stateless and evaluate outbound traffic separately. Since the request on 443 is already permitted, the necessary fix is an appropriately limited outbound allowance for the client's ephemeral response destination ports.
Global Accelerator can route eligible client traffic to endpoints, but it cannot override a stateless subnet network ACL that rejects the outgoing response packets. This is not an endpoint-selection issue.
DNSSEC authenticates DNS data; it does not change whether the TCP SYN-ACK and later response packets can leave the EC2 subnet. The failure is on the return packet path.
The security group already allows the inbound service connection, and SGs are stateful for permitted connection responses. Duplicating the same inbound SG rule does not address the NACL's explicit outbound denial.
A branch Site-to-Site VPN has two tunnel endpoints. The customer gateway is configured with one BGP peer, and planned AWS maintenance occasionally breaks all branch-to-VPC traffic when that peer changes. The branch router supports both BGP sessions. What should be done?
AWS Site-to-Site VPN supplies two tunnels for redundancy. The customer gateway must configure supported paths and peers so traffic can converge to the surviving tunnel during maintenance.
Public DNS TTL changes hostname cache lifetimes, not whether the customer router can establish the second BGP adjacency after primary tunnel interruption.
Widening EC2 security-group exposure cannot repair a missing IPsec tunnel peer on the customer gateway and would introduce unnecessary inbound security risk.
An internet gateway cannot substitute for the encrypted hybrid VPN path to private branch networks and would break the stated confidentiality and addressing requirements.
A VPC attachment was moved into the restricted Transit Gateway route table during a security change. The sending VPC's subnet still forwards 10.88.0.0/16 to the Transit Gateway, but the new associated table has no route to the destination attachment. Security groups remain unchanged. What should the operator inspect first?
Transit Gateway evaluates the route table associated with the ingress attachment. The security change moved that attachment into a table with no destination route, so restoring only the intended propagation or static route repairs forwarding without reopening unrelated segments.
The VPC local route must remain for addresses within the VPC. A default internet-gateway route does not reach the private 10.88.0.0/16 network behind another TGW attachment.
CloudFront caches HTTP application objects and cannot proxy arbitrary private-subnet traffic addressed directly to 10.88.0.0/16. It would not repair a Transit Gateway forwarding table entry.
DNS forwarding changes only the mapping of names to IP addresses. The case provides the IP destination and confirms the subnet points to the Transit Gateway; the failure is the missing onward TGW route.
The security team reviews a quarterly spreadsheet of protected AWS accounts, but the last inventory closed before a newly acquired business created three internet-facing ALBs. An audit now finds no organization WAF policy attached to those new resources even though the team called the quarter's report complete. What weakness of the current audit process directly explains the gap?
The newly deployed ALBs never entered the quarter-end inventory, so a one-time resource list cannot establish current Firewall Manager coverage.
This is a risk in route 53 resolver query logging security visibility: Resolver query logs provide DNS request observations for associated VPC resolution paths, distinct from network-flow and API change logs. It does not account for the firewall manager organization compliance audit fault stated in this incident.
That outcome depends on cloudtrail network api audit, whose mechanism is different: CloudTrail records supported AWS management API activity, including the identity and request parameters behind configuration changes, rather than packet payloads. The reported defect concerns firewall manager organization compliance audit.
Traffic Mirroring copies supported packet traffic to a capture destination, whereas flow logs provide aggregate network metadata. That explains the separate vpc traffic mirroring security packet evidence issue, not this demonstrated firewall manager organization compliance audit failure.
Please check your mailbox for a message from support@examlabs.com and follow the directions.
