8 Comprehensive Security+ Practice and Review

Scope and scenario decisions

The SY0-701 objectives cover five domains: General Security Concepts $(12\%)$, Threats, Vulnerabilities, and Mitigations $(22\%)$, Security Architecture $(18\%)$, Security Operations $(28\%)$, and Security Program Management and Oversight $(20\%)$. The objectives describe multiple-choice and performance-based questions; practice scenarios are not official exam questions.

Domain percentages can help prioritize review, but they do not determine the exact number of questions on an individual exam form. In a scenario, match the response to the available evidence, business impact, and stated security goal. Consider why an appealing alternative does not fit those facts.

Contain threats and preserve evidence

Incident response coordinates preparation, detection, response, and recovery. It calls for action against credible risk while avoiding unsupported conclusions about what happened.

If a payroll administrator enters a password on a page linked from an unexpected email and a sign-in alert shows a new device accessing payroll records, treat the account as credibly compromised. Revoke active sessions and disable or restrict the account to contain further access, while preserving relevant sign-in and system records. The alert alone does not prove that data was stolen.

Do not wait for a scheduled password change, shut down every payroll server without a reason, or announce that theft is definite without evidence. These alternatives either fail to contain the credible risk or claim more than the available evidence establishes.

If a workstation may have sent sensitive files to an unfamiliar external host, preserve relevant endpoint, network, and application records. Document how evidence is collected and handled, and contain the device as appropriate while the investigation proceeds. Reimaging immediately or deleting logs may destroy useful evidence; asking the user to delete files or publicly naming a suspected attacker does not validate what happened. Using multiple relevant log and data sources can support an investigation.

Authorize access and select controls

For employees using personal devices to reach a cloud application, use resource-specific authorization that evaluates identity and device context for each access request. Zero-trust architecture does not grant implicit trust based only on network location. A VPN or private subnet may be part of a design, but neither makes every connected device trustworthy; access from an office IP address does not replace user authentication.

For a file share containing confidential customer records, Least privilege permissions help prevent unauthorized reading, while access logging helps detect and investigate access. These controls have distinct purposes: limiting who can access records and recording their use. A disaster recovery site, privacy notice, awareness poster, unrelated encrypted disk, vulnerability scan, or longer password-expiration period does not directly correct broad permissions and provide access detection.

Match cryptographic tools to security goals

A Digital signature checked using the vendor's trusted public key provides evidence of both origin and integrity for a software update. Encryption primarily protects confidentiality; it does not by itself establish that the vendor produced the file. Storing the file on an encrypted disk likewise does not verify its origin or whether it was altered in transit.

A Hash can indicate that a file differs from a reference value, but that reference must be trustworthy. A hash calculated without a trusted reference—or an unauthenticated hash supplied alongside the file—does not establish who produced it.

Prioritize vulnerabilities and control changes

Vulnerability prioritization should consider more than a severity label. If a scanner finds a critical-severity flaw on both an internet-facing payment server with evidence of active exploitation and an isolated test machine with no sensitive data, prioritize the payment server. Consider exposure, active exploitation, asset importance, and potential business impact—not just the scanner rating or which system is easiest to update.

Confirm impact and apply a tested fix when feasible. If immediate patching is unsafe or impractical, use a suitable interim mitigation and track remediation. A scanner finding is not proof that a system has been compromised, and deferring both fixes until an annual audit ignores their different risks.

If an unapproved firewall change exposes a management interface to the internet, restore a known-good configuration through the authorized process, verify that the exposure is closed, and preserve relevant records even when no compromise is confirmed. Change management accounts for potential impact, approvals, testing, documentation, and rollback plans. Do not leave a risky rule in place simply to wait for the next change window, delete firewall logs, or add undocumented changes to compensate. Records may help determine why the change occurred and whether the exposure was exploited.

Interpret recovery objectives

A Recovery time objective (RTO) of four hours means the target is to restore the critical service within four hours. A Recovery point objective (RPO) of 15 minutes means the organization can tolerate losing no more than 15 minutes of data.

These objectives do not specify antivirus update frequency and do not guarantee recovery. Backups and recovery procedures need to be tested to determine whether the targets are achievable.

Manage external and accepted risks

Before and during a relationship with a payment processor that will access customer information, assess its security and data-handling practices, define obligations in the agreement, and monitor the relationship. Third-party risk management includes due diligence, clear agreements, and ongoing monitoring. Agreements can specify security expectations, incident-notification obligations, and assessment rights. Marketing claims alone are insufficient, and outsourcing processing does not automatically remove the organization's responsibility to manage the risks it introduces. Permanent administrator access is not a substitute for managing those risks.

If a business owner asks to defer a security fix because immediate remediation could interrupt a critical service, document the risk, assess likely impact and available mitigations, and obtain acceptance from an authorized risk owner for a defined period. Risk acceptance should be informed and documented, not an informal workaround. Record the rationale, mitigations, approval, and review or expiration date. Informal acceptance by a system administrator does not establish accountable risk ownership, and a request for more time does not close the vulnerability.

Connect scenario skills

Use scenario facts to select a response and explain why a tempting alternative does not fit. For account-compromise or investigation situations, revisit containment, evidence preservation, and selection of relevant log sources. For access-control situations, review identity, authorization, Least privilege, Zero-trust architecture, and the difference between preventive controls and detective controls.

For cryptography situations, distinguish confidentiality, integrity, authentication, hashing, encryption, and Digital signature. For vulnerability and firewall-change situations, review risk-based prioritization, mitigation, approvals, testing, documentation, and rollback. For recovery situations, distinguish Recovery time objective (RTO) from Recovery point objective (RPO) and relate both objectives to recovery plans and tested backups. For third-party and exception situations, review due diligence, contracts, risk ownership, and documented Risk acceptance.

The NIST Cybersecurity Framework and incident-response guidance can help connect technical controls with organizational risk and response activities. Domain percentages are useful for prioritizing review, but do not determine the exact question count on an individual exam form.