Application-Layer Security Blocks the cURL Request

200-901 By islever Editorial Last updated

Short answer

C Application-layer security features on the remote server block the connection while ping and a Telnet TCP socket still succeed.

Question

Refer to the exhibit. A developer is using cURL to test connectivity to a webpage. The request times out after 10 seconds. The developer tested connectivity by using Ping and can open a TCP socket to the remote server by using Telnet. Other users confirm that they can access the webpage from their device. The developer has SSH access to the remote server and runs commands to troubleshoot. What causes the issue? - Exhibit: Application-Layer Security Blocks the cURL Request
  1. Connectivity from the remote server back to the client is down.
  2. Firewall rules on the remote server block the client on port 443.
  3. Application-layer security features on the remote server block the connection. Correct Answer
  4. HTTPS proxy configured on the remote server blocks the connection.

Key Takeaways

Isolate the layer: reachability (ping) and the TCP handshake (Telnet) prove the network path and the port are usable, so the block must be happening in the application layer, not in routing or a plain port firewall.

Ping succeeds and a TCP socket to the server opens with Telnet, other users reach the page, and the developer has SSH access, so Layer 3 and Layer 4 connectivity are fine. The failure is specific to the HTTPS application exchange, which points to application-layer security on the remote server blocking the cURL request.

Common mistake: Choosing the port-443 firewall because HTTPS is the failing protocol; the successful Telnet TCP socket shows the port is reachable, so a simple port block is ruled out.

Expert Analysis

Why the Answer Is Correct

Ping proves the host is reachable, and opening a TCP socket with Telnet proves the transport and the target port are usable, while other users can load the page from their own devices. Since the network layer and the TCP layer work for this client, the remaining difference is the application-layer exchange: the remote server is applying application-layer security that rejects this particular connection, which is option C.

Why the Other Options Are Wrong

Option A, that connectivity from the server back to the client is down, is contradicted because other users reach the page and the client itself establishes a TCP socket; a return-path failure would also break the Telnet socket. Option B, a firewall rule on the server blocking the client on port 443, is inconsistent with the successful Telnet TCP socket. Option D, an HTTPS proxy on the far server blocking the connection, adds a component the scenario never describes and is not needed to explain a tool-specific timeout.

Community Comment Notes

Most commenters selected the application-layer answer, reasoning that the server's security can block a cURL request even though ping and a Telnet socket succeed, and that this affects the application layer specifically. One commenter argued for the port-443 firewall, but the working TCP socket undercuts that explanation and the majority view stands.

Official Reference

https://www.rfc-editor.org/rfc/rfc7230

This link opens the official vendor documentation in a new tab.

Exam Strategy

Layered elimination: working ping means L3 is fine, a working TCP socket means L4 and the port are fine, so the fault is at L7. Choose the application-layer security option and discard firewall, reverse-connectivity and proxy options.

Frequently Asked Questions

Why is a port-443 firewall not the cause of the cURL timeout?

The developer opened a TCP socket to the remote server with Telnet, which shows the port is reachable, so a simple firewall block on 443 cannot explain the failure.

What does a working ping and Telnet prove in this scenario?

They show the network path and the transport connection are fine for this client, which shifts the fault to the application layer where the HTTPS exchange is blocked.

More 200-901 FAQ →

Community Votes

C
83%
B
17%

83% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 4

  1. Muste 👍 3 Answered C
    The server may have increased security that is blocking the cURL request2. Even though the developer can ping the server and open a TCP socket with Telnet, the application layer security could still block specific types of connections, like cURL12.
  2. daniii89 👍 1 Answered B
    Think its B: Firewall rules on the remote server block the client on port 443. • The server is up and running since other users can access the webpage. • The client can connect via Telnet and SSH, meaning general network connectivity is fine. • The issue is specific to HTTPS traffic (port 443), suggesting that a firewall rule is blocking the client’s IP.
  3. dexcript 👍 1 Answered C
    Curl is using certification key, so there is some sort of TLS Client Authentication configured in the Remote Server. My answer would be C.
  4. kymoni 👍 1 Answered C
    C. Application-layer security features on the remote server block the connection.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Benefits of Edge Computing Architecture

S-grade

Capability of Model-Driven Programmability

S-grade

AXL API Configures Phone Books and Contacts

S-grade

OAuth Authentication for an Administrator API

S-grade

Practice All 200-901 Questions

Access 105 questions with complete answers and detailed explanations.

View Full 200-901 Practice Test →

← Back to 200-901 Study Guide