SOA-C02 Networking and Content Delivery Practice Question
A SysOps administrator receives an alert that a VPN connection between a VPC and an on-premises network is down. The VPN uses static routing. After verifying the on-premises side is functioning, what should the administrator check in AWS?
⚠ Common exam trap
It's easy for candidates to assume a VPN tunnel failure must be a routing or BGP issue, but with static routing, the most common cause is a mismatch in the customer gateway IP address, which is a simple configuration check that should be performed first.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Verify that the customer gateway device is configured with the correct IP address.
Since the VPN uses static routing, BGP is not in use, so checking BGP session status (Option A) is irrelevant. Rebooting the virtual private gateway (Option B) is a disruptive action that should not be a first step without identifying the root cause. Ensuring the route table has a route to the virtual private gateway (Option C) is important for traffic flow but does not address the VPN tunnel being down. The correct first step is to verify that the customer gateway device is configured with the correct IP address (Option D), because a mismatch in the public IP address of the on-premises VPN endpoint will prevent the IPsec tunnel from establishing, even if the on-premises side is functioning internally.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check the BGP session status.
Why it's wrong here
In a Site-to-Site VPN with static routing, BGP is not used to exchange routes. The tunnel is built with IPsec parameters, and the BGP session status would be empty or irrelevant. BGP status only matters when the VPN connection is configured for dynamic routing, so checking it would not identify why the tunnel is down. Thus, this is not a useful diagnostic for this scenario.
- ✗
Reboot the virtual private gateway.
Why it's wrong here
A virtual private gateway is an AWS-managed, highly available resource; AWS does not provide any API, console, or CLI call to restart or reboot it. Even if you could interfere with it, the issue is more likely with the customer gateway configuration or network path. The correct troubleshooting approach is to validate the VPN tunnel's configuration and the on-premises public endpoint before attempting a non-existent managed operation. Therefore, rebooting is not a valid action.
- ✗
Ensure the route table has a route to the virtual private gateway.
Why it's wrong here
The VPC route table must have a route to the virtual private gateway for subnet traffic to use the VPN, but the tunnel's operational state is independent of that route. When the tunnel is down, traffic would fail regardless of the route table entries because the IPsec association is not negotiated. The user's alert indicates the VPN connection is down, not that traffic is merely not being routed. So while you should eventually confirm the route exists, it is not the immediate fix for a downed tunnel.
- ✓
Verify that the customer gateway device is configured with the correct IP address.
Why this is correct
The customer gateway device represents the on-premises endpoint of the VPN tunnel, and its public IP address is a required parameter. If the IP address configured in AWS for the customer gateway does not match the actual public IP of the on-premises device—for example if it changed or NATed—the IPsec negotiation cannot succeed. Verifying this critical endpoint configuration is the first step in troubleshooting a downed tunnel because it prevents the security associations from ever being established. This directly addresses the root cause of a failed VPN connection.
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.