Cyber Security Quiz: Password Managers And Mfa Tools
10 questions · exam conditions
0:00
Password Managers And Mfa ToolsQuestion 1 of 10

An employee follows a link in an email to a cloud-storage sign-in page. The page looks correct, but the password manager does not offer the saved credential. The employee confirms that the displayed domain differs from the legitimate domain by one character. The page instructs users to copy and paste passwords if autofill fails.

Which action best uses the password manager as a defensive control in this situation?

Paste the saved password manually, but approve the MFA request only if the page continues to appear legitimate.
Close the page and open the service through the password manager's saved URL or a previously verified bookmark.
Reset the saved password from the displayed page, because autofill failures commonly occur after password expiration.
Add the displayed domain to the saved entry, but first compare the page's certificate issuer with the legitimate site.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Password Managers And Mfa Tools

Practice Password Managers And Mfa Tools in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Password Managers And Mfa Tools, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An employee follows a link in an email to a cloud-storage sign-in page. The page looks correct, but the password manager does not offer the saved credential. The employee confirms that the displayed domain differs from the legitimate domain by one character. The page instructs users to copy and paste passwords if autofill fails.

Which action best uses the password manager as a defensive control in this situation?

  1. Paste the saved password manually, but approve the MFA request only if the page continues to appear legitimate.
  2. Close the page and open the service through the password manager's saved URL or a previously verified bookmark. (correct answer)
  3. Reset the saved password from the displayed page, because autofill failures commonly occur after password expiration.
  4. Add the displayed domain to the saved entry, but first compare the page's certificate issuer with the legitimate site.
Explanation: When a password manager refuses to autofill, treat that silence as a security alarm — not a technical glitch. Password managers bind saved credentials to exact domain names, so a mismatch between the stored domain and the page's domain causes autofill to silently fail. This is precisely why autofill is a powerful anti-phishing control: it cannot be socially engineered the way a human can. The correct move is B: close the suspicious page entirely and navigate to the service using the URL already stored in your password manager or a verified bookmark. This eliminates all attacker-controlled context and guarantees you land on the legitimate domain. The password manager's refusal to autofill was the warning — trusting that warning and escaping the attacker's environment is the right response. A is dangerous because pasting your password manually bypasses the domain-verification protection that autofill provides. You'd be handing credentials directly to the phishing site, and approving an MFA request afterward only confirms the attacker's session, not yours — this is a classic adversary-in-the-middle scenario. C compounds the threat. Resetting a password on a phishing page gives the attacker both your old and new credentials. Autofill failures are almost never caused by password expiration; that framing is a social engineering lure embedded in the page itself. D sounds technical and cautious, but adding a phishing domain to your saved entry permanently corrupts your credential store. Certificate checks don't validate domain legitimacy when the domain itself is fraudulent. Study tip: On security exams, whenever autofill fails, the defensive answer is always leave the page — never work around the control the manager just applied for you.

Question 2

A user is replacing a phone that contains a TOTP authenticator app. The old phone still works, and the user can currently sign in to every protected account. Some accounts issue a new TOTP secret when MFA settings are changed.

Which migration procedure best minimizes the risk of being locked out or leaving an unmanaged authenticator active?

  1. Use each account's MFA workflow to enroll or transfer the new phone, verify it, save updated recovery codes, and then remove the old phone. (correct answer)
  2. Wipe the old phone first, install the same authenticator on the new phone, and request account recovery if codes do not synchronize.
  3. Photograph every enrollment QR code, place the images in cloud storage, and scan them after configuring the replacement phone.
  4. Keep the old phone permanently as the primary authenticator and use the new phone only to store account passwords.
Explanation: When migrating a TOTP authenticator, you're managing two simultaneous risks: getting locked out of accounts and leaving an old, unmonitored device capable of generating valid codes. The safest procedure addresses both risks deliberately and in the right order. The ideal approach — captured in A — is to use each account's official MFA enrollment workflow while the old phone still works. This lets you verify the new device generates correct codes before making any irreversible changes. Saving updated recovery codes protects against future lockouts, and explicitly removing the old phone from each account ensures no unmanaged authenticator remains active. This ordered sequence (enroll → verify → save codes → deactivate old device) eliminates both risks cleanly. B gets the order dangerously backwards. Wiping the old phone before the new one is confirmed destroys your fallback, virtually guaranteeing lockouts. Relying on "account recovery" is a last resort, not a migration strategy — some accounts make recovery extremely difficult. C introduces a serious security vulnerability. Storing QR code images (which encode the raw TOTP secret) in cloud storage permanently exposes those secrets. Anyone who accesses that storage can generate valid codes indefinitely, completely defeating MFA's purpose. D avoids migration entirely and creates a confused, insecure setup. Keeping the old phone as the primary authenticator while the new phone holds passwords splits credentials across devices with no clear security benefit, and the old phone becomes a liability if lost or stolen later. A solid study tip: on MFA questions, always evaluate procedures by asking two things — does this prevent lockout, and does this prevent secret exposure? Any answer that fails either test should be eliminated.

Question 3

A user stores both a randomly generated account password and the account's TOTP seed in the same password manager. The vault is unlocked locally with a master password and device biometrics. At sign-in, the service receives the saved password and a current TOTP code.

Which statement most accurately describes this configuration?

  1. The device biometric becomes a remote inherence factor, so the service validates three independent authentication factors.
  2. The account no longer uses MFA, because two credentials stored in one application are always treated as one factor.
  3. The service validates two factor types, but compromise of the unlocked vault could expose both account credentials. (correct answer)
  4. The configuration prevents real-time phishing, because TOTP codes generated by password managers cannot be relayed.
Explanation: When analyzing multi-factor authentication (MFA) questions, focus on where factor validation actually occurs — the service authenticating you versus the local application unlocking your credentials. These are two separate trust boundaries. Here, the password manager holds both the account password (something you know) and the TOTP seed (used to generate something you have). When you sign in, the remote service receives and validates both: a static password and a time-based one-time code. That's genuinely two factor types reaching the service — knowledge and a possession-derived token. So C is correct. However, if an attacker compromises your unlocked vault, they can extract both the password and the TOTP seed, meaning a single point of failure can collapse both credentials simultaneously. A is wrong because device biometrics unlock the local vault — they're validated by your device, never sent to or verified by the remote service. The service never sees or evaluates the biometric, so it cannot count as a remote authentication factor. B is wrong because storing two credentials in one application doesn't automatically merge them into one factor. Factor type is determined by the nature of the credential (knowledge, possession, inherence), not by where it's stored. The service still receives and validates two distinct factor types. D is wrong because TOTP codes generated by a password manager can absolutely be relayed. Real-time phishing attacks capture a valid TOTP code during its 30-second window and replay it immediately — the generation source doesn't matter. Remember: storage location affects security posture, not factor classification. Exam questions often conflate the two as a trap.

Question 4

An organization wants employees to keep personal credentials private while allowing recovery of business credentials when an employee forgets a vault password or leaves unexpectedly. The security team is evaluating password-manager deployment models.

Which design best meets both requirements?

  1. Give administrators every employee's master password and require employees to change it whenever personal credentials are added.
  2. Use one organization-wide vault account so administrators and employees can recover all business and personal entries.
  3. Use organization-controlled recovery for managed business vaults while keeping personal vaults separate and outside that recovery scope. (correct answer)
  4. Disable all recovery capabilities and require employees to send encrypted exports of both vault types to administrators each month.
Explanation: When evaluating password manager deployment models, you need to balance two competing requirements simultaneously: organizational recovery capability and personal privacy. Questions like this test whether you understand that these goals aren't mutually exclusive — they just require careful scoping. The design that satisfies both requirements is C. By maintaining separate vaults — one organization-controlled for business credentials and one personal vault outside that scope — employees retain full privacy over personal accounts while administrators can still recover business credentials when someone forgets their password or leaves unexpectedly. This is the principle of least privilege applied to vault architecture: the organization gets exactly the access it needs, nothing more. A fails because requiring employees to share their master password with administrators directly violates personal credential privacy. Even with a policy requiring password changes, there's always a window of exposure, and this approach fundamentally undermines trust. B compounds the problem further — a single shared organizational vault merges business and personal credentials entirely, giving administrators unrestricted visibility into personal accounts. This is both a privacy violation and a single point of failure if that account is compromised. D sounds security-conscious but actually destroys usability and introduces new risks. Monthly encrypted exports create stale credential snapshots, burden employees, and don't provide real-time recovery when someone leaves unexpectedly. A useful strategy here: when a question lists two distinct requirements, mentally check each answer against both requirements before choosing. Distractors like A and B usually satisfy one requirement (recovery) while completely ignoring the other (privacy). Always ask yourself, "Does this solution respect the full scope of the problem?"

Question 5

A legacy website accepts passwords of at most 12 alphanumeric characters and requires answers to two security questions. It accepts arbitrary alphanumeric answers rather than verifying real biographical information. The user already has unrelated credentials for several other sites.

Which password-manager strategy provides the best defense within these constraints?

  1. Reuse an existing strong password, but assign different truthful security-question answers so the complete credential set remains unique.
  2. Generate a unique random 12-character password and unique random answers, then store all three values in the password manager. (correct answer)
  3. Create a memorable 12-character password and provide truthful answers so account recovery remains possible without the password manager.
  4. Use a common base password with a site abbreviation and store only the security-question answers in the password manager.
Explanation: When evaluating password-manager strategies, you should think across three dimensions simultaneously: credential uniqueness, secret entropy, and what gets stored. A breach at one site should never compromise another, and every stored value should be random and unpredictable. Generating a unique random 12-character password alongside two unique random security-question answers — and storing all three in the password manager — satisfies every dimension at once. The site's 12-character alphanumeric ceiling is respected, nothing is reused, and because the answers are arbitrary alphanumeric strings (the site doesn't verify real biographical data), randomizing them is entirely valid. This is why B is correct. A fails because reusing an existing password — even a strong one — violates the uniqueness principle. If that password leaks elsewhere, this account is immediately at risk. Unique security-question answers don't compensate for a shared password. C introduces two serious weaknesses: a memorable password is by definition lower-entropy than a random one, and truthful answers to security questions are discoverable through social engineering, data aggregation, or other breaches. Prioritizing recoverability over security defeats the purpose of a password manager. D is a classic "base + modifier" pattern, which attackers actively exploit. Once the base is known, an attacker can systematically guess site abbreviations. Storing only the security-question answers while using a predictable password gives you the worst of both worlds. Study tip: On security questions, treat them as a second password field — randomize and store them just like the password itself. Any answer with real biographical meaning is a liability.

Question 6

Four administrators require access to a legacy appliance that supports only one local administrator account. The organization uses an enterprise password manager with named-user access, group collections, access logs, and immediate revocation. One administrator is leaving the organization.

Which approach best limits exposure while accommodating the appliance's shared-account restriction?

  1. Send the password through encrypted email to each administrator and delete each message when the administrator leaves.
  2. Let one administrator memorize the password and provide it verbally whenever another administrator needs temporary access.
  3. Create separate copies of the entry in each administrator's private vault and delete the departing user's copy afterward.
  4. Share one entry through a least-privilege group, revoke the departing user, review logs, and rotate the appliance password. (correct answer)
Explanation: When a question describes a shared credential scenario, focus on the four pillars of access control: least privilege, auditability, revocation, and credential hygiene. The goal is never just hiding a password — it's ensuring every action is traceable and every departure is clean. Option D does all of this correctly. Storing one shared entry inside a least-privilege group means each administrator accesses the same credential through their own named-user session, so the audit log ties every login event to a specific person. When the administrator leaves, you revoke their group membership, review the logs for any suspicious activity during their tenure, and rotate the appliance password — eliminating any residual knowledge they carry out the door. This is the complete, professional lifecycle. Option A fails because encrypted email is a dead end for accountability. Once the password lands in someone's inbox, you lose visibility into when and how it's used. Deleting the email after departure doesn't erase the administrator's memory or any copies they may have made. Option B is arguably the worst approach: verbal transmission creates zero audit trail, introduces inconsistency, and makes the entire security posture dependent on one person's availability and trustworthiness. This is security theater. Option C is a common-looking trap. Creating separate vault copies feels like least privilege, but it fragments the credential — now you have four independent copies to track. Deleting the departing user's copy doesn't guarantee they didn't export or screenshot it, and rotating the password isn't mentioned. Study tip: On security exam questions, always look for the answer that combines revocation + audit logs + credential rotation — that trio almost always signals the correct, complete answer.

Question 7

A password-manager provider reports that attackers copied customers' encrypted vault files. The provider states that vault encryption was not bypassed. A customer used a unique, randomly generated master passphrase and the recommended key-derivation settings, but the vault contains credentials for email, banking, and administrative services.

Which response most appropriately addresses the remaining risk from the copied vault?

  1. Change only the master passphrase, because doing so also re-encrypts every previously copied version of the vault.
  2. Enable MFA only on the password-manager account, because MFA prevents attackers from decrypting an offline vault copy.
  3. Change the master passphrase and rotate stored credentials, prioritizing email, financial, and administrative accounts. (correct answer)
  4. Wait for evidence of account misuse, because strong vault encryption makes credential rotation unnecessary after any copy.
Explanation: When a vault file is stolen but encryption remains intact, you're dealing with an offline attack scenario — the attacker possesses the encrypted data and can attempt to crack it indefinitely without any server-side defenses. The key question becomes: what risks persist even if the vault never gets cracked? The answer is that the vault might eventually be cracked — through future computational advances, brute force, or previously unknown vulnerabilities — and the credentials inside would still be valid. This is why C is correct. Changing the master passphrase limits the window for cracking the copied vault, but rotating stored credentials is equally critical: even if attackers eventually decrypt an old vault copy, those credentials would be stale and useless. Prioritizing email, financial, and administrative accounts makes sense because those enable cascading damage (email resets other accounts, admin access is high-privilege). A is wrong on a factual basis — changing your master passphrase does not retroactively re-encrypt the vault copy the attacker already downloaded. That stolen copy remains encrypted under the original passphrase forever. B is wrong because MFA on the password-manager account protects login to the service, not decryption of an offline vault file. An attacker working locally with the vault copy never touches that MFA prompt. D is dangerously passive. Waiting for evidence of misuse means you're reacting after damage occurs. Strong encryption reduces risk but doesn't eliminate it — especially over long time horizons. Study tip: On security-response questions, distinguish between service-side controls (MFA, account locks) and data-side risks (offline decryption). Stolen encrypted files bypass service-side protections entirely.

Question 8

A company is selecting MFA for executives who face both SIM-swap attacks and real-time phishing proxies. The available options are SMS codes, TOTP authenticator codes, number-matching push notifications, and FIDO2 security keys protected by a local PIN.

Which option provides the strongest protection against both identified attack methods?

  1. FIDO2 security keys, because authentication is bound to the legitimate site's origin and does not rely on the phone number. (correct answer)
  2. TOTP authenticator codes, because they avoid the mobile carrier and cannot be submitted through a phishing proxy.
  3. Number-matching push notifications, because matching the displayed number proves that the requesting site is legitimate.
  4. SMS verification codes, because the short validity period prevents a SIM-swap attacker from using intercepted messages.
Explanation: When evaluating MFA strength, always ask two questions: Can the credential be intercepted in transit? and Can it be used on a fake site? Both SIM-swap attacks and real-time phishing proxies exploit the same fundamental weakness — they steal a credential that is valid independent of the site you're actually on. FIDO2 security keys defeat both attacks through cryptographic origin binding. During registration, the key records the exact origin (domain) of the legitimate site. When authenticating, the browser passes the origin to the key, and the key simply refuses to sign a challenge from any other domain — including a phishing proxy sitting in the middle. There's no phone carrier involved, so SIM-swapping is irrelevant. A is correct. B is wrong because TOTP codes are phishable. A real-time proxy can prompt you to enter your TOTP, immediately relay it to the legitimate site, and complete the login before the 30-second window expires. The carrier avoidance is real, but the phishing-proxy vulnerability remains. C is wrong because number-matching reduces accidental push approvals, but it does nothing when a phishing proxy is in play. The proxy triggers a legitimate push notification, the number matches legitimately, and you approve — handing the attacker an authenticated session. D is wrong on both counts. SMS codes are the weakest option here: SIM-swap attackers intercept them directly, and phishing proxies can relay them in real time just like TOTP codes. Study tip: On MFA questions, "phishing-resistant" is a precise term — only credentials bound to a cryptographic origin (like FIDO2) truly qualify. If a human can type it into a fake site, it can be phished.

Question 9

A user has a passkey for portal.example.com stored in a password manager that synchronizes passkeys across approved devices. The user visits portal-examp1e.com, a visually convincing phishing site, and selects the option to sign in with the existing passkey.

What should normally happen if the browser and password manager correctly implement passkey origin checks?

  1. The passkey should authenticate because synchronization makes the credential valid on any HTTPS site requesting it.
  2. The legitimate passkey should not be offered for that origin, so it cannot authenticate the phishing site as the real portal. (correct answer)
  3. The passkey should authenticate only after the user enters the legitimate portal's password as an additional knowledge factor.
  4. The passkey should generate a TOTP code that the phishing site can relay once but cannot reuse afterward.
Explanation: When you see questions about passkeys and phishing, the core concept to focus on is origin binding — the cryptographic property that makes passkeys fundamentally different from passwords. Passkeys are WebAuthn credentials that are cryptographically tied to a specific origin (the exact domain they were created for). When your browser or password manager attempts to use a passkey, it checks whether the current site's origin matches the origin stored with the credential. If they don't match — even by a single character — the passkey simply won't be offered. This means a passkey created for portal.example.com is invisible to portal-examp1e.com. The phishing site receives nothing, and authentication cannot proceed. That's why B is correct: the legitimate passkey is never offered for the wrong origin, making it useless to the attacker. A reflects a common misconception about synchronization. Cross-device sync means the credential follows you to your approved devices — it doesn't relax the origin check. The passkey remains bound to portal.example.com regardless of where it's stored. C describes a behavior that doesn't exist in the passkey standard. Passkeys are designed to replace passwords, not supplement them with a fallback knowledge factor during an origin mismatch. D conflates passkeys with TOTP (time-based one-time passwords). These are entirely different technologies. Passkeys don't generate TOTP codes — they use asymmetric cryptography and challenge-response signing, with no shareable code produced at all. Your study tip: remember that passkeys' phishing resistance is architectural, not behavioral. The user cannot accidentally hand over the credential because the browser enforces the origin check before the user even sees the option.

Question 10

An employee receives six unexpected MFA push notifications within two minutes. The final notification includes a number-matching challenge. The employee has not attempted to sign in, and the organization normally generates a push only after a correct password is submitted.

What is the most appropriate response?

  1. Approve one request with number matching, then inspect the account's sign-in history to determine which request was legitimate.
  2. Ignore the requests without reporting them, because MFA has already prevented the attacker from completing authentication.
  3. Disable MFA temporarily to stop the notifications, then continue using the existing password after the prompts have ended.
  4. Deny the requests, report the event, change the password through a trusted route, and revoke unrecognized sessions. (correct answer)
Explanation: When you see a scenario involving unexpected MFA push notifications, you're being tested on your understanding of MFA fatigue attacks — a social engineering technique where attackers flood a victim with push requests hoping the user approves one out of frustration or confusion. Your instinct should immediately be: the attacker already has the password, and the MFA layer is the last barrier standing. That's precisely why D is correct. Denying the requests prevents the attacker from slipping through. Reporting the event alerts your security team to an active credential compromise. Changing the password through a trusted route (not a link in a suspicious email) eliminates the attacker's stolen credential. Revoking unrecognized sessions ensures the attacker can't persist through any session token they may have already established. This is the complete, defense-in-depth response. A is dangerously wrong — approving any push request, even the number-matching one, authenticates the attacker into your account. Number matching makes fatigue attacks harder, but approving it still grants access. There is no "legitimate" push here because you never initiated a sign-in. B is a false sense of security. MFA is blocking the attacker right now, but the password is already compromised. Ignoring and not reporting leaves the door cracked — the attacker simply tries again later, or waits. C is catastrophically backward. Disabling MFA removes the only protection currently working, and keeping the compromised password guarantees eventual breach. For exam strategy, remember: whenever MFA pushes arrive unsolicited, treat it as confirmed password compromise — the response must address both the active attack and the underlying credential.