Investigate a private worker connection failure.

Example Answer

DNS succeeds and the worker's egress rule allows the approved destination, but its associated route table has no route for that address. The control worker supports the existing NAT and vendor path working. I would add the approved destination's /32 route to that NAT in the affected subnet's route table, keeping the TCP 443 restriction.

I would verify the actual route-table association, then test a TLS-validating vendor request from the original worker and confirm unrelated egress remains denied. Adding a public IP or inbound rules would not be the scoped fix this evidence supports.

Worked reasoning

The route chain should be worker subnet → existing public NAT → internet gateway → vendor. 203.0.113.40 is outside 10.20.0.0/16, so the supplied local-only table cannot forward that destination. A security-group allow rule permits traffic through its filter; it does not create a route.

The reviewed route addition is:

Use the actual NAT identity from the approved environment; the exercise intentionally supplies no operational resource ID. Change the source of truth and confirm the subnet is associated with the edited table. A default route would be broader than this fixed-destination requirement. Routing itself is not a port-level authorization control, so preserve the narrow security group.

The alternative hypothesis of a vendor outage is weakened by the successful control request through the same NAT. It is not disproved for every time or request. After the change, verify TCP, certificate/hostname validation and the expected application response from the original worker. Test an unrelated destination against the existing deny policy without widening it. A successful TCP handshake alone does not establish authenticated application success.

Falsification: if the intended /32 route is active in the worker's associated table but the connection still fails, collect flow and NAT evidence for a fresh attempt and inspect return traffic or destination filtering. Do not keep adding routes when the failure has moved to TLS or HTTP.

What the interviewer is assessing

Core checks (1 point each):

• Identifies the absent destination route and distinguishes it from DNS and security-group authorization.
• Adds the approved /32 path to the existing verified NAT while preserving private placement and the narrow egress rule.
• Verifies route association, the original TLS/application path and continued denial of unrelated egress.

Stronger (+1 after all core checks): Explains why a fixed-IP route is justified only under the stated vendor contract and must be revisited when that contract changes.

Acceptable alternatives: An already approved outbound proxy or private vendor connection can be used if its actual path and scope are demonstrated; inventing a new endpoint is not a diagnosis.

Red flags: Adds a public IP, opens inbound ports or all egress, changes IAM permissions for a routing failure, or treats DNS success as end-to-end reachability.

Follow-up

The vendor moves to a changing set of addresses. Should the /32 remain hard-coded?

Example response: Revisit the connectivity contract. Use a supported stable private endpoint or an approved egress/proxy mechanism that handles the vendor's changes and preserves destination controls. A subnet route or security-group CIDR rule does not automatically track a hostname. Review the wider path explicitly instead of silently switching to unrestricted egress.