Scenario: A Citrix Administrator manages an environment that has an externally accessible website. The administrator would like to provide end-to-end encryption and use features such as caching and…

Grace U.Jun 11, 2026

Option C, SSL front-end and SSL backend, is the one you want here. The key phrase in the scenario is "end-to-end encryption," which tells you right away that traffic must stay encrypted all the way from the client through the ADC and on to the backend server, not just halfway. The reason you choose SSL over SSL_TCP is that SSL (at layer 7) allows the ADC to inspect and act on HTTP traffic, which is exactly what unlocks features like caching and compression. SSL_TCP is a layer 4 passthrough, so the ADC cannot read the content, and those features simply do not work with it.

Toby R.Jun 26, 2026

SSL front-end, SSL backend is the right call here. You need SSL on both ends to get true end-to-end encryption, and keeping it as SSL (not SSL_TCP) is what gives you access to the HTTP-layer features like caching and compression that SSL_TCP would bypass.

Fatima Z.Jun 18, 2026

Option A is the classic gotcha because "caching and compression" scream HTTP-layer features and you might stop right there, but the scenario also demands END-TO-END encryption, which means the backend leg must stay encrypted too, not drop to plain HTTP. SSL front-end plus SSL backend, choice C, is the only one that keeps your traffic locked up from client to server while still letting the ADC do its Layer 7 magic in the middle.

Samuel O.Jun 26, 2026

The key word in this scenario is "features such as caching and compression," because those are Layer 7 HTTP features that the ADC can only apply when it can actually read the HTTP headers, meaning the traffic has to be decrypted before it hits the ADC's processing engine. SSL_TCP is a pass-through protocol, so options B and D are out immediately since the ADC never unwraps the payload and therefore cannot cache or compress anything. Option A gets you there halfway, the ADC can inspect and optimize the traffic, but you lose encryption on the backend segment, which breaks the end-to-end requirement. So C is the only choice that gives you SSL termination at the front for Layer 7 feature access, then re-encrypts on the way to the server. Quick question though: does anyone know off the top of their head whether the SSL profile on the backend virtual server in option C needs to match the cipher suite of the frontend, or can you configure them independently? Asking because I ran into a situation in a real deployment where the backend server only supported older TLS and it caused handshake failures that were not obvious at first glance.

Mateus R.Jun 26, 2026

Think of the ADC like a post office sorting room. If every package arrives sealed and you send it out sealed without opening it, you can never sort, repackage, or optimize anything inside, that is SSL_TCP, a pure pass-through where the appliance never sees the payload. The moment you need the ADC to actually read and manipulate the contents, say to compress a big attachment or cache a repeated catalog page, it has to open the envelope on the way in and reseal it on the way out, and that is exactly what SSL front-end with SSL backend does: terminate the client session, apply your layer 7 goodies, then re-encrypt toward the server so the "end-to-end" promise is kept. Option A breaks that promise because the backend leg goes out in plaintext HTTP, and options B and D use SSL_TCP which treats traffic as an opaque pipe and therefore cannot touch caching or compression at all. Funny story, I actually second-guessed myself on this one during the real exam because I kept thinking "end-to-end" automatically meant some kind of tunnel mode, which made SSL_TCP sound tempting. Then I remembered my post office analogy and realized a tunnel that nobody can open is useless if you need to do work inside it. Went with C, moved on, and it was the right call.