Free Summarize Security Measures practice questions

Authorization decides what an authenticated account may do. The user signed in successfully, so authentication already passed and the failure is in permissions: group membership, the folder's ACL, or the share-versus-NTFS combination where the most restrictive setting wins. Authentication answers 'who are you?' with passwords and MFA, and it is clearly working. Accounting records what happened and who did it in logs and audit trails; it never grants or denies access. Availability is part of the CIA triad and describes whether the resource is up and reachable; the folder is reachable and is refusing this specific user, so availability is not the issue. When a user can log in but cannot reach a resource, start with authorization rather than a password reset.

An authenticator app generates one-time codes or push approvals directly on the device using a shared secret, so it works offline without needing cellular service. It is generally stronger than SMS because it avoids risks tied to phone numbers, such as SIM swapping or message interception. SMS sends a code by text message, which is convenient but weaker because phone numbers can be ported or intercepted, and it requires a cellular signal to receive the message. A voice call reads a code over an automated call and shares the same weaknesses as SMS, since it depends on phone routing and the phone number, and it also requires a signal. An email code is sent to the user's inbox and can be a weak second factor, especially if the email account uses the same password or is already signed in on the same device; it also requires network connectivity to retrieve. The authenticator app best meets both requirements of offline operation and stronger resistance to phone-number attacks, which is why it is commonly paired with SSO deployments to protect the central account.

Just-in-time (JIT) access grants elevated rights only when a user needs them and only for a short window, typically tied to an approval process, a defined role, and logging. This reduces the risk of standing admin accounts that could be abused if compromised, because the technician remains a standard account until elevation is temporarily granted. Single sign-on allows a user to log in once and reach many approved apps without re-entering credentials; it addresses password sprawl rather than temporary privilege elevation. Zero Trust networking is a broader policy mindset that never assumes access is safe simply because a user is on the internal network or already authenticated, checking trust signals with each request; while related to limiting access, it does not specifically describe time-limited admin elevation. Data loss prevention focuses on stopping sensitive data from leaving approved systems through email, USB, or cloud sharing, which is unrelated to granting temporary administrative rights. JIT is often part of a broader Privileged Access Management (PAM) program that controls, monitors, and records privileged actions to support accountability and reduce the value of stolen credentials.

Most systems check deny entries before allow entries, so a single explicit deny can block access even when another group grants the user allow rights. Because the user belongs to a group with an explicit deny on the folder, that deny takes precedence over the modify permission granted by the other group, resulting in blocked access. The statement that allow permissions always override deny is the opposite of how effective permissions are calculated; deny generally wins in these conflicts. The claim that share permissions do not apply to local users is incorrect, because share permissions apply to network access regardless of the account type, and when share and file permissions differ the most restrictive combination wins. The idea that inherited permissions cannot be combined with groups is also false, since folders commonly use inheritance where subfolders and files copy permissions from the parent, and those inherited entries combine with group memberships to produce the final effective permissions. Understanding that deny is evaluated first and that effective permissions are the net result of all allows, denies, and inherited entries is essential when troubleshooting access failures.

Remote wipe allows IT to remove corporate data, and sometimes the entire device contents, when a phone or laptop is lost or stolen, preventing later access to email profiles, attachments, and synced work documents. This is the action that directly addresses the risk of an exposed lost device. A compliance check confirms that a device meets minimum requirements, such as having a passcode, encryption, or an up-to-date OS, before it can access company resources; it verifies device health but does not remove data from a lost device. A configuration profile pushes settings, security policies, and app rules to an enrolled device, which is part of ongoing management rather than an emergency response to a lost phone. Device enrollment is the initial process of registering a device into company management so it can receive policies and support actions; it is a prerequisite that must already be completed, not the tool used to protect data after loss. Because the phone was already enrolled and had a required PIN and encryption, a stranger cannot quickly open it, and triggering a remote wipe removes the corporate data even when the device is out of reach.

Data loss prevention (DLP) focuses on what users do with data and where that data can go, covering data in motion such as email and chats, data at rest in storage, and data in use through copy, paste, print, or upload actions. DLP can block outgoing email that matches sensitive patterns like credit card numbers and can warn or block when a user copies protected files to a USB drive, which is exactly the described requirement. Mobile device management (MDM) enforces settings on work phones and laptops, such as requiring a PIN, encryption, or remote wipe, but it manages devices rather than inspecting and controlling the flow of sensitive content. Identity and access management (IAM) is the broader system that manages identities, access rules, and sign-in controls across applications; it decides who can authenticate and what they are authorized to do, not what happens to data after access is granted. Single sign-on (SSO) lets a user authenticate once to reach many apps and reduces password sprawl, but it does not inspect content or prevent data exfiltration. DLP works best when supported by good data labeling and classification and by user training that reduces workarounds.

With single sign-on, the central identity account becomes the control point that unlocks many services, so it becomes a high-value target. Applying stronger MFA to that main account, especially an authenticator app or hardware token for admins and remote access, directly reduces the risk of an attacker compromising the account that grants access to everything. Disabling password complexity requirements weakens authentication and makes the central account easier to compromise, which increases rather than reduces the risk. Storing separate passwords inside each application defeats the purpose of SSO, reintroduces password sprawl, and undermines the centralized control and easier offboarding that SSO provides. Allowing shared accounts removes accountability because access logs can no longer trace actions to a single person, and shared credentials increase the chance of leakage; this weakens security instead of protecting the central account. To keep SSO safe in practice, organizations typically combine stronger MFA on the main account, monitoring of sign-in logs so unusual patterns trigger review, and clear account recovery rules, since recovery becomes a potential path into every connected service.

Under a Zero Trust model, the system does not assume access is safe just because credentials are correct; it evaluates trust signals such as device compliance for each access request. Because the account works from the managed office laptop but fails from the unmanaged home laptop, the most likely cause is that conditional access blocked the sign-in when the home device failed a compliance check, such as lacking enrollment, encryption, or an up-to-date OS. A password that expired on the office device would prevent access from that device too, but the office laptop is working, so this does not fit. If the application's file ACLs were removed, the user might authenticate but be blocked inside the app on any device, which does not match a symptom tied specifically to one untrusted device. If the user were deleted from the directory service, authentication would fail everywhere, including the office laptop, so that cannot be the cause. This scenario illustrates why a valid password does not guarantee access: the device layer, the network layer, and the application layer each act as separate checkpoints, and a compliant device is a common conditional access requirement before a sign-in is allowed.

The card plus PIN model adds a second factor so that a stolen card alone is less useful, because an attacker would also need to know the PIN to gain entry. Smart cards are chip-based credentials that can support stronger authentication methods, including cryptographic checks, which makes copying harder, and pairing the card with a PIN further protects higher-risk areas such as data centers and labs. The claim that it eliminates the need to revoke credentials is false; revocation remains a critical part of the credential lifecycle, and access should still be disabled immediately after termination, loss, or role change. The statement that it removes the need for access logs is incorrect, because logs are essential for audits and investigations regardless of the credential type, and smart card systems tie each credential to a unique identity to support accountability. Allowing one credential to be shared by a team would reduce accountability and break the log trail, which is the opposite of a security benefit. Requiring both something you have, the card, and something you know, the PIN, strengthens authentication for spaces where the impact of unauthorized entry is high.

A propped-open door to a network closet is a live access risk, not just a paperwork issue, because anyone can walk in and tamper with switches, cabling, or equipment while the door is open. The proper first action is to secure the door and treat the situation as an active security concern, then follow up by checking access logs, pulling camera footage if timing looks suspicious, and documenting the incident. Leaving the door propped and only emailing facilities allows the exposure to continue and prioritizes convenience over security; if airflow is genuinely needed, that should be requested as a facilities fix rather than a security bypass. Re-keying the entire floor is an expensive and disruptive response used after a lost mechanical key, and it does not address a propped electronic door, so it is not the appropriate first step here. Issuing new badges to the whole team addresses credential compromise, not an unsecured door, and does nothing to close the immediate physical opening. Restricted areas should narrow access step by step, and a propped door defeats the entire layered defense-in-depth design, so restoring the barrier immediately is the priority.