Verify the route before trusting the request.
Review reused credentials, MFA codes, unexpected links and attachments, trusted updates and shared sessions. Counts do not certify account security.
Six original scenarios each contribute one match to the authored key. The count describes these supplied facts, local rules and educational concepts, not your actual conduct, character or a certified digital-citizenship level. Every explanation and this full guide is free at every count.
A shared secret links separate accounts
Reusing one credential means a leak from one service can be tried against another. The lesson is about the relationship between accounts, not a claim that every leak immediately compromises all of them. A longer reused phrase still creates that relationship. Independent credentials and a suitable password manager address the shared-secret pattern. For a fresh exercise, draw three fictional services and mark where one password is reused; then remove one link at a time to see which exposures remain. Use invented labels and no real passwords.
A code request does not authenticate a caller
An unexpected caller may know that a login code was sent without being the legitimate account holder or service. A code is not a harmless explanation of an incident; it is part of authentication. The exercise’s appropriate response withholds it and uses an independently verified account-security route. Do not enter a real code into this practice or share one as evidence. This distinction concerns what the requester has established. A familiar tone, urgency or knowledge of your name does not independently prove the requester’s authority.
Separate the claim from its supplied route
If a message says an account is closing, there are two things to inspect: whether a real account notice exists and whether the supplied login route is legitimate. Opening a known official app or saved service address avoids using the suspicious message itself as the source of authority. A logo and button labelled “secure” can be copied. Verification can reveal that a message is genuine or false; this practice does not ask you to assume either before checking, or to visit any potentially harmful live destination.
An independent contact can clarify an unexpected file
An urgent unexpected attachment is not made trustworthy by the sender label alone. Confirming through a separately known contact can establish whether the person meant to send it and what the project expected. Opening first to inspect appearances reverses that order, and forwarding it widely expands exposure. A confirmed sender still does not create a guarantee that every file is safe, so real organisations may require additional approved checks. Here the question tests the stated verification step and never downloads, executes or analyses an actual attachment.
Trusted updates use the established process
The update item supplies a verified personal-device settings route, saved work and an opportunity to follow the vendor’s normal process. Those conditions distinguish it from an installer offered in an unsolicited chat. Check completion through the trusted route rather than treating a popup’s wording as proof. This is not an instruction to bypass staged testing, backups, permissions or deployment controls on a managed service. The practice describes a decision under its supplied facts; it does not change software or grant new access.
End access when the shared-device task ends
On a shared computer, closing a document may leave its account authenticated. Signing out through the service and checking the session addresses that remaining access. Saving a password for the next person or leaving a code behind introduces another exposure. Different real tools can retain cached material or manage sessions differently, so follow the authorised local procedure as well. This example concerns an account session, not a promise that one click erases every local trace or that all public devices can be made safe.
Rehearse with fictional requests and bounded conclusions
After a missed key, identify the trust assumption: a reused secret, an unverified caller, a message-supplied link, an unexpected file, an untrusted installer or a session left open. Write a short alternative path using only known legitimate routes. Do not test a real suspicious link to complete this exercise. Six authored matches have no established relation to compromise probability, certification, job readiness or actual protective behaviour. The source guidance supports the concepts; it does not validate this bank or guarantee that an account following them will never be attacked.