While troubleshooting a broken encrypted session between a city workstation and a cloud case portal, an engineer needs to reason about which networking layer typically provides confidentiality services for that session. Which approach best applies OSI/TCP-IP models?
Select an answer to reveal the explanation.
Short Explanation
Layer models are the map when an encrypted session breaks—you find whether the problem is crypto at the session/app edge or something lower. Guessing at cables or rebooting at random wastes the afternoon.
Full Explanation
Diagnosing a broken encrypted session between a city workstation and a cloud case portal benefits from OSI/TCP-IP layer reasoning. Confidentiality for many web and API sessions is provided by TLS associated with the upper layers (commonly described at the application/transport boundary), while lower layers handle framing, addressing, and routing. Locating whether failure is certificate validation, cipher negotiation, or a lower-layer connectivity problem prevents random changes and focuses remediation on the correct service.
Assuming confidentiality always lives only in the physical cable jacket confuses physical protection with session crypto. Restarting random switches without a layered hypothesis wastes time and may not touch the TLS fault. Concluding the network layer never participates in security discussions ignores IPsec and routing/filtering roles even when this particular session’s confidentiality is TLS-based.
Exam caveat: CISSP Domain 4 expects fluency placing security services on reference models; TLS confidentiality is an upper-layer pattern distinct from link or physical concerns.
Operational check: verify DNS and reachability (lower layers), then TLS handshake, certificate trust, SNI, and cipher results (session crypto); capture only what policy allows; compare working and failing clients; fix the failing layer rather than rebooting unrelated infrastructure.