SY0-701 Exam Results

An application allow list is a security technique that specifies which applications are authorized to run on a system and blocks all other applications. An application allow list can best protect against an employee inadvertently installing malware on a company system because it prevents the execution of any unauthorized or malicious software, such as viruses, worms, trojans, ransomware, or spyware. An application allow list can also reduce the attack surface and improve the performance of the system. References: CompTIA Security+ Study Guide: Exam SY0-701, 9th Edition, Chapter 11: Secure Application Development, page 551 1

Encryption is a reversible process that transforms cleartext data into ciphertext to protect confidentiality. It uses cryptographic keys to both encrypt and decrypt data, ensuring that only authorized parties can access the original data.

Hashing, on the other hand, is a one-way function that converts data into a fixed-length hash value or checksum. Hashing is primarily used to verify data integrity by detecting changes, since any modification in the input will produce a different hash output. Unlike encryption, hashing cannot be reversed to obtain the original data.

While encryption can protect data both at rest and in transit, hashing does not protect data confidentiality but supports integrity verification. Public-key exchange is a cryptographic mechanism within asymmetric encryption but is unrelated to hashing key usage.

This distinction is thoroughly explained in the Cryptography chapter of the SY0-701 syllabus【6:Chapter 7†CompTIA Security+ Study Guide】.

Ensuring that other team members understand how a script works is essential to prevent a single point of failure. If only one person knows how the script operates, the organization risks being unable to maintain or troubleshoot it if that person is unavailable. Sharing knowledge ensures continuity and reduces dependence on one individual.

Reducing implementation cost and remediating technical debt are secondary considerations in this context.

Identifying complexity is important, but the main benefit is to avoid a single point of failure​​.

Zero Trust is based on the principle of “never trust, always verify.” Option B is correct because access is granted only after strong identity verification, policy evaluation, and continuous monitoring. Zero Trust rejects the old perimeter assumption that users or devices inside the internal network should automatically be trusted. Access decisions should consider identity, device posture, location, sensitivity of the resource, session risk, and ongoing behavior. MFA is commonly used in Zero Trust, but option C is too narrow because Zero Trust applies beyond remote access and beyond MFA alone. Role-based limitations and periodic reviews are useful, but option D does not capture continuous verification. Option A is the opposite of Zero Trust because it assumes internal trust after initial authentication.