Question 1
A company hosts an application server in a private subnet behind a NAT gateway. Partners on the public internet now need to open HTTPS connections directly to that server. Why does the existing NAT gateway not satisfy this new requirement?
A. A NAT gateway only allows connections initiated from inside the VCN; it never accepts connections initiated from the internet.Correct answer
Correct: NAT is one-way by design — it translates outbound-initiated flows and their return traffic, and offers no way for an external host to initiate a session inward.
B. A NAT gateway accepts inbound connections but only on ports below 1024, so HTTPS on port 443 is rejected.
Invents a port restriction. The limitation is directional, not port-based, and 443 is in fact below 1024's exclusion logic only in this fabricated rule.
C. A NAT gateway supports inbound traffic only after a stateless security list rule is added to the private subnet.
Assumes a security rule can change routing behaviour. Security lists filter traffic that the gateway can already carry; they cannot make a NAT gateway accept inbound-initiated sessions.
D. A NAT gateway forwards inbound traffic only when the private subnet is also attached to a Dynamic Routing Gateway.
Confuses on-premises connectivity with internet ingress; a DRG carries private VPN/FastConnect traffic and does not enable inbound internet flows through a NAT gateway.
Explanation
NAT is inherently unidirectional: the gateway maps outbound-initiated connections from private resources and permits only the corresponding return packets, so no host on the internet can start a session toward the private instance (Networking overview). Accepting partner-initiated HTTPS requires a public-facing entry point such as a public load balancer, or moving the workload to a public subnet with an internet gateway. Port thresholds, stateless security rules, and DRG attachments all describe unrelated mechanisms and none of them makes NAT bidirectional.