1D0-61A · Question #54
Marcella is looking for a very unique product online. She has found one on the XYZ Company's Web site, which is designed well and appears to be legitimate. As she navigates through the checkout…
The correct answer is C. Because the link does not use SSL/TLS encryption and therefore the information. Option C is correct because a legitimate checkout page that collects sensitive financial data must use SSL/TLS encryption (indicated by https:// in the URL and a padlock icon). If the URL shows http:// instead of https://, the credit card data is transmitted as unencrypted…
Question
Marcella is looking for a very unique product online. She has found one on the XYZ Company’s Web site, which is designed well and appears to be legitimate. As she navigates through the checkout process, she reaches the checkout page with this URL, which asks her to enter her credit card information:
Why should Marcella cancel her online transaction instead of proceeding?
Options
- ABecause the site uses 128-bit encryption, which is illegal for companies that are located
- BBecause the link contains abbreviations and is not completely readable, so Marcella is
- CBecause the link does not use SSL/TLS encryption and therefore the information
- DBecause the link uses SSL/TLS encryption, which Marcella knows is not compatible with
How the community answered
(34 responses)- B3% (1)
- C94% (32)
- D3% (1)
Explanation
Option C is correct because a legitimate checkout page that collects sensitive financial data must use SSL/TLS encryption (indicated by https:// in the URL and a padlock icon). If the URL shows http:// instead of https://, the credit card data is transmitted as unencrypted plaintext, making it trivially interceptable by attackers performing a man-in-the-middle attack.
Why the distractors are wrong:
- A is fabricated - 128-bit encryption is not illegal for any company; stronger encryption is actually encouraged and standard practice.
- B misidentifies the threat - abbreviated or long URLs can be a phishing red flag, but that alone doesn't mean your payment data is insecure; the encryption status is the critical issue here.
- D is the opposite of reality - SSL/TLS is universally supported across all modern browsers and operating systems; incompatibility is not a real concern.
Memory tip: Look for the S in https:// - think "S = Secure." Any page asking for a credit card, password, or personal data that lacks that S is a hard stop. If it's not HTTPS on a checkout page, walk away.
Topics
Community Discussion
6C is the right answer. The checkout URL uses plain HTTP instead of HTTPS, which means there is no SSL/TLS encryption protecting the data in transit, and entering a credit card number on that page sends it across the wire in cleartext where anyone in the middle can grab it.
No https in the URL means your card data travels unencrypted. Saw almost this exact scenario on my exam and froze for a sec, then remembered my instructor drilling "look at the protocol first, everything else is noise," and C clicked instantly.
Thought B distracted me, but http in that URL means no encryption at all.
Exactly right, Orla, and for exam purposes lock in the mnemonic "S is for Secure" because HTTPS wraps HTTP in TLS on port 443, while plain HTTP sits wide open on port 80, which is a Domain 1 confidentiality concept that shows up on nearly every blueprint variant.
C is your answer, and the giveaway is that any checkout URL transmitting payment data must begin with https, not http, because the "s" confirms an active SSL/TLS session that encrypts data in transit. Without it, Marcella's credit card number travels in plaintext and can be intercepted by anyone performing a man-in-the-middle attack on the network.
The HTTPS requirement is solid, but worth clarifying that HTTPS alone just confirms transport encryption, it does not verify the server is actually who it claims to be without also checking that the certificate is valid, unexpired, and issued by a trusted CA.