You save $69.98
A PrivateLink consumer interface endpoint remains AVAILABLE, but the provider NLB has no healthy application targets after a rollout. Which observation is sufficient to declare the actual private service restored?
PrivateLink endpoint control-plane state is separate from the provider backend's readiness and application behavior.
Endpoint state alone does not establish that targets can serve requests.
Resource sharing does not verify provider application health.
Unrelated connectivity is not a test of the PrivateLink service.
A central network template creates S3 gateway endpoints but engineers keep forgetting to associate the endpoint with private route tables after deployments. Security wants this association consistent and reviewable in source control. What process correction is best?
The intended routing relationship becomes part of reproducible stack state rather than an undocumented postdeployment manual step.
A NAT default route does not replace the missing more-specific service endpoint association.
Hostname changes do not establish service gateway endpoint routes.
A checklist alone cannot enforce reproducible infrastructure state under template governance.
A security audit finds that CloudFront viewer connections are encrypted but the distribution still fetches sensitive content over HTTP from an application origin.
Which observation would most directly demonstrate the required network outcome?
TLS tests show valid HTTPS from browsers and encrypted origin fetches without an unexpected HTTP fallback. That is relevant because cloudFront has separate viewer-to-edge and edge-to-origin transport settings; encrypting one segment does not automatically encrypt both.
This would validate acm private ca internal mutual trust. The case instead needs evidence for cloudfront https viewer and origin settings: TLS tests show valid HTTPS from browsers and encrypted origin fetches without an unexpected HTTP fallback.
This would validate vpn encryption over direct connect. The case instead needs evidence for cloudfront https viewer and origin settings: TLS tests show valid HTTPS from browsers and encrypted origin fetches without an unexpected HTTP fallback.
This would validate route 53 dnssec chain-of-trust protection. The case instead needs evidence for cloudfront https viewer and origin settings: TLS tests show valid HTTPS from browsers and encrypted origin fetches without an unexpected HTTP fallback.
A TGW VPC attachment and its propagations look correct, but EC2 traffic still leaves the private subnet toward a legacy peering route for the destination VPC prefix. The old peering connection is inactive. What subnet-level correction is required?
VPC route tables independently choose the packet’s target before it reaches the transit gateway.
The packet never enters the transit path while the subnet targets inactive peering.
Interface endpoint DNS cannot redirect a subnet’s IP CIDR route.
Changing HTTP status codes does not select the correct VPC next hop.
Private EC2 workers in one Region upload terabytes daily to S3, all through a public NAT gateway. Billing shows large NAT gateway data-processing charges. The subnet route tables can support S3 gateway endpoints. Which optimization most directly reduces the NAT processing path?
Eligible S3 requests can use the gateway endpoint route instead of being processed by NAT for internet egress.
More gateways do not inherently remove the NAT per-GB processing path.
S3 bucket access does not become an ALB target-group function.
DNS caching does not bypass NAT processing for the object traffic.
A company wants CloudFront origin access control (OAC) to sign requests to private S3 objects, but the distribution points to the bucket's static website endpoint rather than an S3 REST origin. Direct anonymous requests to the website endpoint still succeed while OAC signing cannot be applied there. Which architectural limitation most directly prevents the intended private-origin design?
CloudFront OAC signing for private S3 access is supported on regular S3 bucket origins, not the bucket website endpoint configured as a custom origin.
DNS caching does not change which S3 origin type supports OAC signing.
Cache retention does not restrict unauthenticated direct object access.
ALB HTTP routing is unrelated to CloudFront-to-S3 request authorization.
A low-latency EC2 network service saturates packet-per-second processing on a legacy instance type despite spare CPU. The workload requires improved enhanced networking support and predictable throughput. What should be assessed?
ENA-enabled instance network performance is dependent on compatible hardware and instance capacity, not CPU alone.
CDN tuning cannot raise the instance’s ENI packet processing limit.
Network security cannot simply be removed to guarantee higher instance NIC capacity.
More DNS queries do not expand packet processing capacity.
A datacenter router starts advertising a new /16 summary over Direct Connect even though it owns only a handful of /24 branches within that block. The summary also covers a prefix owned by another team; traffic for that network now follows the wrong site. What risk does careless summarization create?
The broad advertised prefix includes addresses this site does not own, so other networks can forward valid traffic to the wrong on-premises destination.
That outcome depends on aws gateway route-priority and static-route validation, whose mechanism is different: IP routing selects a matching destination prefix under the service's route-selection rules; changing security groups cannot override the selected next hop. The reported defect concerns hybrid route summarization and overlap response.
PrivateLink connectivity depends on accepted service endpoints and healthy provider backends without granting consumer VPCs general routes. That explains the separate privatelink endpoint lifecycle restoration issue, not this demonstrated hybrid route summarization and overlap response failure.
This is a risk in transit gateway route propagation drift: Gateway routing policy uses the route table associated with an originating attachment and propagates routes only to eligible route tables. It does not account for the hybrid route summarization and overlap response fault stated in this incident.
Two peered VPCs use private EC2 hostnames. Instances in one VPC resolve the peer’s public DNS hostname to public addresses even though the intended route is private peering. Both VPCs have DNS support enabled. What additional peering setting should the network team evaluate?
VPC peering DNS resolution configuration can influence address answers for eligible hostnames without requiring public packet routing.
Turning off DNS resolution would prevent the intended hostname lookups.
Internet routing would defeat the private inter-VPC path objective.
DNSSEC proof does not choose private-address resolution over public hostname answers.
A hospital has a private hosted zone services.aws.internal associated with a VPC. Its on-premises DNS servers need to resolve records from that zone over Direct Connect without exposing those records publicly. Which entry point should the data center forward queries toward?
Inbound endpoints accept DNS queries from on-premises resolvers into AWS for VPC-associated resolution.
Outbound endpoints relay AWS-originated queries outward and have the wrong direction for this requirement.
Publishing the private records publicly violates the stated privacy requirement.
An internet gateway does not operate as a DNS resolver endpoint.
A SaaS ALB has two HTTPS listener rules: priority 10 matches /api/* and priority 20 matches /api/admin/*. The general API target group receives sensitive admin requests despite the more specific-looking second path. What should the engineer adjust?
ALB listener rules are evaluated by assigned priority; matching a broad rule first prevents the later specific rule from winning.
Connection draining does not change listener rule precedence.
Listener rules need distinct ordering and cannot share the same priority.
DNS record type does not reorder an ALB’s HTTPS listener rules.
Please check your mailbox for a message from support@examlabs.com and follow the directions.
