SCS-C02 Infrastructure Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Configure TLS on the applications

  Why it's wrong here

  TLS only encrypts the specific application protocols that implement it, such as HTTPS or LDAPS, and does not protect UDP traffic, syslog, NTP, or other IP-based communications crossing the Direct Connect link. Even if every application were individually enabled with TLS, the underlying network path between on-premises and the VPC would remain unencrypted, leaving metadata and non-application traffic exposed. This approach fails the requirement to secure the connection itself, rather than just the payloads of a few higher-layer protocols.

• ✓

  Set up an IPsec VPN over the Direct Connect private VIF

  Why this is correct

  Setting up an IPsec VPN over the Direct Connect private VIF encapsulates all IP traffic between your on-premises network and the VPC, providing network-layer confidentiality and integrity while still using the private, low-latency Direct Connect path. IPsec operates at Layer 3, so it secures every protocol and service traversing the link, not just specific applications, and it is the standard way to add encryption because Direct Connect does not encrypt traffic natively. The VPN tunnel rides inside the private VIF, so you retain the dedicated bandwidth and avoid the public internet.

• ✗

  Use a site-to-site VPN over the internet instead of Direct Connect

  Why it's wrong here

  Replacing Direct Connect with an internet-based site-to-site VPN forfeits the dedicated connection's benefits, including consistent throughput, lower latency, and greater reliability, because traffic now crosses the public internet where performance is variable and packet paths are uncontrolled. Although IPsec does encrypt the traffic, the public path introduces additional attack surface and potential for ISP outages or throttling. This option also sidesteps the requirement to secure the existing Direct Connect link rather than solving it; the goal is to encrypt the private connection, not to abandon it for a less deterministic network.

• ✗

  Enable encryption on the Direct Connect private VIF

  Why it's wrong here

  AWS Direct Connect private VIFs are carried over an unencrypted physical link and do not have a console or API setting to enable encryption on the VIF itself. Even though MACsec (IEEE 802.1AE) can be enabled on a dedicated Direct Connect connection to encrypt traffic at Layer 2, it applies to the entire physical link and is not a private-VIF feature; it also requires dedicated connections with compatible hardware. Attempting to 'enable encryption on the private VIF' is not a supported operation, so the correct approach is to overlay IPsec over the VIF or use MACsec on the underlying dedicated connection.

Go deeper

Related to this question