Courseiva
Trust and security with Google CloudmediumMultiple ChoiceObjective-mapped

Cloud Digital Leader Trust and security with Google Cloud Practice Question

An enterprise's security team is implementing a strategy to protect against 'credential stuffing' attacks — where attackers use lists of username/password combinations from previous data breaches to try to log in to the company's applications. Which authentication control most effectively mitigates this threat?

⚠ Common exam trap

The GCDL exam often tests the misconception that password hashing (like bcrypt) or encryption protects against credential stuffing, but candidates must recognize that the attacker already has the plaintext passwords from a prior breach, so hashing the database is irrelevant to this attack vector.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Multi-Factor Authentication (MFA/2SV), which requires a second verification factor beyond the password that attackers don't have even when they possess the stolen credentials

Multi-Factor Authentication (MFA/2SV) is the most effective control against credential stuffing because it requires an additional verification factor (e.g., a one-time code from an authenticator app, a hardware token, or a biometric) that the attacker does not possess, even if they have valid username/password pairs from a breach. This renders the stolen credentials useless for authentication, as the attacker cannot complete the second factor challenge. In Google Cloud, this is commonly enforced via Identity Platform or Cloud Identity with security keys or TOTP.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Requiring longer, more complex passwords to make credentials harder to guess

    Why it's wrong here

    Credential stuffing does not involve guessing or brute-force; the attacker already possesses valid username/password pairs obtained from prior breaches of other services. Password complexity requirements increase the search space for offline guessing or dictionary attacks, but they have zero effect when the exact password is already in the attacker's possession and being replayed verbatim. Even a 64-character complex password is worthless if the user reused it on a breached site and the attacker has that exact string, so imposing length/complexity rules does not address the core failure of password reuse.

  • Multi-Factor Authentication (MFA/2SV), which requires a second verification factor beyond the password that attackers don't have even when they possess the stolen credentials

    Why this is correct

    MFA is the definitive defense against credential stuffing. The stolen credentials work for the first factor (password), but the attack fails at the second factor (authenticator app TOTP, push notification, hardware security key). Attackers would need both the credentials AND access to the user's second factor device — a much higher bar.

  • Encrypting passwords in the company's database using bcrypt to prevent the stolen passwords from being usable

    Why it's wrong here

    Encrypting/hashing passwords in the company's own database protects against an attacker stealing the company's database. Credential stuffing uses credentials stolen from other breached sites where users reused passwords. The company's own password storage is not the attack vector.

  • Implementing HTTPS on the login page to prevent credentials from being intercepted in transit

    Why it's wrong here

    HTTPS encrypts the login submission in transit, preventing network eavesdroppers from capturing credentials over Wi-Fi or between a client and the server. However, credential stuffing uses credentials that were already stolen from other sites' databases; the attacker does not intercept anything during the targeted login session. Because the attacker submits the previously stolen credentials programmatically over the same encrypted channel, HTTPS cannot distinguish a replay from a legitimate login and provides no defense against the reused credential being valid.

About these practice questions

This GCDL question is part of Courseiva's 829-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.