- Which outcome is most consistent with the protection HTTPS provides?
Answer: The malware can capture the password or session data at the endpoint even though network traffic is protected in transit
When tackling questions about HTTPS and TLS, the critical framework is understanding where protection applies — specifically, that encryption governs data in transit across the network, not data at the endpoints where it originates or terminates.
HTTPS/TLS creates an encrypted tunnel between the browser and the server, preventing eavesdroppers on the network from reading your credentials. However, that encryption only kicks in after the browser has already processed the plaintext input. A keylogger captures your password at the keyboard driver level — before TLS ever touches it. Similarly, malware with browser memory access can extract credentials or session tokens directly from RAM, completely bypassing network-layer protections. This is why B is correct: the malware exploits the endpoint, which TLS was never designed to protect.
A describes something physically impossible. HTTPS encryption happens at the transport layer, well after your keyboard input travels through the OS and into the browser. The keyboard driver and browser both handle plaintext — TLS has no presence there. C is a seductive distractor because TLS does encrypt application data in transit, but it doesn't maintain encrypted storage within browser memory; that memory is accessible to processes with sufficient privileges. D invents a capability TLS simply doesn't have — certificate validation authenticates the server's identity, not the security state of the client endpoint. Malware detection is not part of the TLS handshake.
The study tip here: always ask "at what layer does this protection operate?" HTTPS secures the wire, not the machine. Endpoint security (antivirus, EDR tools) is an entirely separate defense layer.
- What is the most accurate conclusion about the padlock in this situation?
Answer: It confirms an encrypted connection to the named domain, but does not establish that the domain is trustworthy or belongs to the bank
When you see a question about HTTPS padlocks and phishing, the core concept being tested is what TLS encryption actually guarantees — and, critically, what it does not guarantee.
A padlock means your browser successfully negotiated an encrypted TLS connection with the server hosting that domain, and that a certificate authority (CA) confirmed the certificate is valid for that specific domain name. That's it. The encrypted tunnel protects your data in transit — but it says nothing about who controls the domain or what their intentions are. An attacker can register secure-payments-example.net, obtain a perfectly legitimate TLS certificate for it (CAs issue these routinely for any domain the requester controls), and serve a convincing phishing page — all while your browser happily displays the padlock. Answer C captures this precisely: encrypted connection to the named domain, no guarantee of trustworthiness or ownership by the bank.
A is wrong because Domain Validation (DV) certificates — the most common type — require only proof of domain control, not any verification of business identity or legitimacy. Even Organization Validation (OV) certificates don't confirm a site is safe to use. B is wrong because CAs perform zero review of page content or intent; TLS validation is entirely separate from malware or phishing detection. D is wrong in the opposite direction — it dramatically understates what HTTPS provides. TLS absolutely does encrypt credentials in transit; the problem is simply that they're being sent to the wrong party.
A useful rule of thumb: the padlock answers "is this connection private?" not "is this destination safe?" Keep those two questions separate on exam day.
- Which information can the attacker most reasonably obtain from the captured traffic?
Answer: The destination IP address and traffic timing, but not the protected HTTP content carried inside TLS
When you see a question about network eavesdropping on encrypted connections, anchor your thinking to the TLS/HTTPS layered model: encryption protects application-layer content, but lower-layer metadata remains visible to anyone who can observe packets on the network.
HTTPS wraps HTTP inside TLS, which encrypts the request body, headers, URL paths, cookies, and response content before transmission. What TLS cannot hide is the IP layer beneath it — specifically, the destination IP address and port (how else would routers know where to send packets?). An attacker passively capturing traffic can therefore see which server you're communicating with, packet sizes, and timing patterns. They cannot decrypt the protected payload without the session keys, which are negotiated using asymmetric cryptography during the TLS handshake and never transmitted in plaintext. This makes B correct.
A is wrong because it describes HTTP behavior, not HTTPS. Public Wi-Fi does make traffic visible to nearby devices, but HTTPS encryption means that visibility yields ciphertext, not readable passwords or amounts. C is wrong in the opposite direction — it partially acknowledges encryption but incorrectly claims URL paths and request bodies are exposed. URL paths are part of the HTTP request, which sits inside TLS and is therefore encrypted. D goes too far in the other direction: HTTPS does not conceal destination IP addresses or packet sizes; those are necessarily visible for routing to function.
A useful rule of thumb: HTTPS encrypts content, not metadata. Destination IP, timing, and packet volume are always observable — remember this distinction, because exam questions frequently test whether you conflate traffic visibility with content exposure.
- What is the most significant risk?
Answer: The attacker can modify the HTTP-delivered script, which can then alter page behavior or access data available to that page
When an HTTPS page loads resources over plain HTTP, you're in the territory of mixed content — a critical web security concept. The key question to ask is: what can an attacker who controls the network actually do with an unencrypted resource?
Because the JavaScript library travels over HTTP, it has no integrity protection. A network attacker performing a man-in-the-middle attack can intercept that HTTP response and inject arbitrary code before it reaches the browser. Since JavaScript runs in the context of the parent page, that injected script inherits full access to the page's DOM, cookies, form fields, and any sensitive data the HTTPS page contains. This makes A the correct answer — a tampered script is effectively a complete compromise of the page, regardless of the main document's encryption.
Choice B describes something that doesn't exist. TLS session keys are never exposed by the content of a page or its sub-resources. Loading one HTTP resource doesn't reveal cryptographic secrets for the HTTPS connection — these are completely separate mechanisms.
Choice C is backwards. Scripts are more dangerous than images or styles precisely because they execute code. Mixed content rules are actually stricter for scripts (called "active mixed content") than for passive resources like images. Scripts absolutely do not inherit the encryption of the parent document.
Choice D is wrong on two counts: TLS only authenticates and encrypts the resources delivered over HTTPS. It provides zero protection for HTTP sub-resources, and an attacker can do far more than merely observe the request — they can modify the response.
Study tip: Remember the phrase "active mixed content = full page compromise." If a script loads over HTTP inside an HTTPS page, the attacker owns the whole page.
- Which statement best characterizes the protection in this system?
Answer: HTTPS protects the forms in transit, but separate controls are needed for database storage, logs, backups, and server access
When a question describes a system with multiple data handling stages, your job is to evaluate each stage independently — transit, storage, logs, backups, and access controls are all separate attack surfaces that each require their own protections.
HTTPS (which uses TLS) is a transport-layer control. It encrypts data while it moves between a client and server. Once that data arrives at the server and TLS terminates, the encryption is gone — the server decrypts it so it can actually process the content. What happens to that data afterward is entirely outside HTTPS's scope. So in this scenario, HTTPS does its job correctly during transit, but the unencrypted database and plaintext logs represent real, separate vulnerabilities that HTTPS was never designed to address. A captures this precisely: transit protection exists, but storage-at-rest encryption, log sanitization, backup controls, and access management are all independently necessary.
B is based on a fundamental misconception — TLS does not leave a "cryptographic mark" on data after delivery. Once decrypted at the server, the data is plaintext. There is no residual encryption.
C invents a distinction that doesn't exist. TLS has no automatic applicability to databases over flat files; neither storage type inherits any protection from transport encryption.
D goes too far in the wrong direction. Partial protection is still meaningful. HTTPS genuinely prevents interception during transit — that's a real security gain, even if storage is unprotected.
The study tip here: on security exams, never let one strong control imply coverage of others. Ask yourself, "at what point does this control start and stop?" Each data lifecycle phase needs its own answer.
- Which statement best describes the resulting security risk?
Answer: The attacker may terminate one encrypted connection and create another, allowing access to or modification of payroll traffic
When you see a question involving certificate warnings and intercepted connections, think about what TLS actually protects — and what it requires to work. TLS encryption is only meaningful when you've verified who you're encrypting to. A certificate-name mismatch warning is your browser telling you it cannot confirm the server's identity, which is precisely the condition an attacker exploits in a man-in-the-middle (MITM) attack.
Here's why B is correct: when an attacker sits between the browser and the payroll server, they can terminate the browser's TLS session on their own machine, read or modify the plaintext data, then re-encrypt it and forward it to the real server. The employee sees a functioning connection; the payroll server receives seemingly normal requests — but the attacker has full visibility into credentials, salary data, and any changes submitted. By ignoring the mismatch warning, the employee essentially handed the attacker a valid interception point.
A is dangerously wrong — it's the most tempting trap. TLS encryption does protect data, but only when certificate validation succeeds. Without validation, you don't know whose key you're encrypting to, so the encryption protects the attacker's tunnel, not yours. C is wrong because confidentiality and integrity are both compromised, not just availability — the attacker can read and alter data. D incorrectly shifts risk entirely to the server; in reality, the employee's submitted data (passwords, banking details) is the primary exposure.
Remember this pattern: encryption without authentication is not security. On exam questions, anytime certificate validation is bypassed, treat the connection as unencrypted from a trust perspective.
- Which attack remains possible before a validated HTTPS connection is established?
Answer: The attacker can suppress or alter the unprotected redirect and attempt to keep the user on an HTTP version of the site
When a browser visits a site over HTTP before any HSTS policy is in place, that initial request travels completely unprotected — and that's the vulnerability this question is testing. Think about what an on-path attacker (someone between you and the server) can actually do versus what the underlying protocols actually allow.
The redirect from HTTP to HTTPS is just a plain HTTP response (typically a 301 or 302). Because it's unencrypted and unauthenticated, an attacker sitting on a hostile network can intercept it and do one of two things: strip it entirely or replace it with a response that keeps the user on HTTP. This is the classic SSL stripping attack, and it's exactly what D describes — the attacker suppresses or alters the unprotected redirect before a secure channel is ever established. HSTS exists precisely to prevent this, but only after a policy has been cached or preloaded.
Answer A is wrong because TLS certificates are issued by Certificate Authorities through a rigorous validation process entirely independent of HTTP responses. An attacker modifying a redirect cannot influence CA trust chains whatsoever.
Answer B is wrong because HTTPS security is independent of how the session started. Once a valid TLS handshake completes with a trusted certificate, the encrypted channel is fully secure regardless of prior HTTP activity.
Answer C is wrong and reflects a fundamental misunderstanding of cryptography. The plaintext HTTP request contains no TLS private key material — private keys never leave the server, and observing HTTP traffic gives an attacker nothing useful for breaking TLS.
Study tip: When you see questions about HSTS, always ask "has the policy been established yet?" If not, that first HTTP hop is exposed — and SSL stripping is the canonical threat to remember.
- Which assessment of this design is most accurate?
Answer: TLS protects the client-to-load-balancer segment, but traffic on the internal HTTP segment can be read or altered there
When a load balancer terminates TLS, it creates two separate communication legs, not one continuous encrypted tunnel. Understanding this split is the key to answering any question about TLS offloading or SSL termination. Ask yourself: where does encryption start, and where does it end?
In this design, encryption exists only between the client and the load balancer. The load balancer decrypts the request, then forwards it as plain HTTP to the application server. That internal segment is unprotected, meaning anyone with access to that network — a compromised host, a misconfigured switch, or a malicious insider — can read or modify the traffic in transit. Answer C correctly identifies this boundary: TLS covers the first leg, but the internal HTTP segment is exposed.
Answer A is wrong because the padlock icon reflects only the client's connection to the load balancer. It makes no claim whatsoever about what happens after decryption. The padlock is scoped to one hop, not the entire request lifecycle. Answer B inverts reality — TLS certificates are not transferable objects that travel with the data. Once the load balancer decrypts traffic, the certificate's protection ends there; nothing is "transferred" to the application server. Answer D is a classic trap: private or internal networks are not automatically encrypted. HTTP is HTTP regardless of whether the network is public or private; it sends data in plaintext.
As a study habit, always trace the full path of data in architecture questions — from client to final destination — and identify every segment where encryption does or does not exist. Never assume a single padlock secures the entire chain.
- Why are the application's login and authorization checks still necessary?
Answer: Server-authenticated TLS normally validates the server to the client, but it does not identify the user or decide which records the user may access
When you see a question mixing TLS with application-layer security, ask yourself: what layer handles what? TLS and application logic operate independently, and confusing their responsibilities is a classic exam trap.
TLS in server-authenticated mode does one specific job — it verifies to the client that the server is who it claims to be (via certificate) and establishes an encrypted channel. That's it. TLS says nothing about who the human on the other end is or what they're allowed to do. Those concerns belong to the application layer. This is exactly why A is correct: the login check identifies the user, and the authorization check decides which records that user may see — neither of which TLS handles.
B is wrong because TLS does not use IP addresses to identify users. IP addresses aren't part of TLS authentication at all, and the idea that a password "translates" an IP identity is fabricated — it doesn't reflect how either protocol works.
C is wrong on two counts. First, server-authenticated TLS does not authenticate both parties — only the server is authenticated (there are no client certificates here). Second, application checks have nothing to do with the encryption algorithm's strength; they are identity and access controls, not cryptographic enhancements.
D reverses the definitions entirely. TLS provides authentication (of the server), not authorization. Authorization — deciding what an authenticated entity may access — is an application concern. Saying TLS provides authorization "without authentication" is backwards and nonsensical.
A good study rule: always separate who encrypts the channel (TLS) from who authenticates the user and who enforces permissions (the application). These are distinct layers with distinct responsibilities.
- Which conclusion is most accurate?
Answer: The token is protected while crossing the network, but HTTPS does not prevent endpoints or their logs from retaining the full URL
When you see a question about HTTPS and sensitive data, train yourself to separate what TLS protects from where TLS applies. TLS encrypts data in transit between two endpoints — it says nothing about what happens once data arrives at either end.
That framing makes D the clear winner. The token is fully encrypted while traveling across the network, so a passive eavesdropper captures only ciphertext. But once the request reaches the server, the server decrypts it completely — full URL, query string, and all. That decrypted URL lands in access logs. Simultaneously, the browser records the full URL in its history the moment you navigate there. Neither of those storage events involves the network, so TLS offers zero protection against them.
A is wrong because it inverts how TLS works. TLS encrypts everything in the HTTP request — including the path and query string — from the client to the server. A passive network observer sees none of it. The vulnerability here is at the endpoints, not on the wire.
B is wrong because it dramatically overstates TLS's scope. A valid HTTPS certificate guarantees an encrypted channel; it has no mechanism to reach into a browser's local storage or a server's log files and protect data there.
C is wrong on two counts: TLS does not touch browser history at all, and a network attacker who captures encrypted packets cannot decrypt them simply because the server can — the server's private key isn't exposed to the attacker.
Study tip: Any time a question mentions "HTTPS protects X," ask yourself where X lives. If it's a log file, browser cache, or local database, HTTPS is irrelevant — it only protects the wire.
