Practice Test #3
Simulate the real exam experience with 90 questions and a 90-minute time limit. Practice with AI-verified answers and detailed explanations.
90Questions90
Simulate the real exam experience with 90 questions and a 90-minute time limit. Practice with AI-verified answers and detailed explanations.
AI-Powered
Every answer is cross-verified by 3 leading AI models to ensure maximum accuracy. Get detailed per-option explanations and in-depth question analysis.
Which of the following is required for an organization to properly manage its restore process in the event of system failure?
IRP (Incident Response Plan) guides how to detect, respond to, contain, eradicate, and recover from security incidents (e.g., malware, intrusion). While it may include limited recovery actions, its primary focus is incident handling and evidence/forensics, not comprehensive system restoration after general system failure or disaster. Choose IRP when the question centers on cyberattacks and response phases.
DRP (Disaster Recovery Plan) is specifically required to manage the restore process after system failure. It documents recovery procedures, restoration order, roles, communications, and validation steps to bring IT services back online. DRP operationalizes backup usage and rebuild processes and is tested to ensure recovery meets business needs. This is the best match for “properly manage its restore process.”
RPO (Recovery Point Objective) defines the maximum acceptable amount of data loss measured in time (e.g., “no more than 15 minutes of data”). It influences backup frequency and replication design, but it is not the plan or procedure for restoring systems. RPO is a requirement/metric used within a DRP/BCP, not a standalone mechanism to manage restoration.
SDLC (Software Development Life Cycle) is a structured approach to designing, building, testing, deploying, and maintaining software. It can improve reliability and reduce failures through secure coding and change control, but it does not provide the operational runbooks and recovery procedures needed to restore systems after a failure. SDLC is about development governance, not disaster recovery execution.
Core concept: This question tests business continuity and disaster recovery planning—specifically what an organization needs to manage the restore process after a system failure. “Restore process” implies recovering systems, data, and services to an operational state, which is the primary purpose of a Disaster Recovery Plan (DRP). Why the answer is correct: A DRP is the documented, tested set of procedures and resources used to recover IT infrastructure and resume critical services after an outage, disaster, or major system failure. It defines how backups are used, how systems are rebuilt (bare-metal restore, image restore, infrastructure-as-code), the order of restoration (prioritization of critical services), roles and responsibilities, communication paths, vendor contacts, and validation steps to confirm systems are functioning correctly. Without a DRP, restores may be ad hoc, inconsistent, and too slow to meet business requirements. Key features/best practices: A strong DRP includes recovery strategies (hot/warm/cold sites; cloud DR), runbooks, dependency mapping (e.g., identity services before applications), backup/replication methods, and testing (tabletop exercises and full failover tests). It aligns with business requirements expressed as RTO (how fast to restore) and RPO (how much data loss is acceptable). Framework-wise, DRP practices map well to NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) and ISO 22301 (business continuity management). Common misconceptions: RPO is important for restore planning, but it is a metric/requirement, not the plan/process itself. An IRP focuses on handling security incidents (containment/eradication) rather than restoring business services after failure. SDLC governs how software is built and maintained, not how to recover operations after an outage. Exam tips: When you see “restore,” “recover,” “failover,” “backup restoration,” or “resuming operations after outage,” think DRP/BCP. If the scenario emphasizes “security incident response steps,” think IRP. If it asks for “maximum tolerable data loss,” that’s RPO; for “maximum tolerable downtime,” that’s RTO.
A company’s web filter is configured to scan the URL for strings and deny access when matches are found. Which of the following search strings should an analyst employ to prohibit access to non-encrypted websites?
"encryption=off" is not a standard or universal indicator of non-encrypted web traffic. It might appear as a custom query-string parameter on a specific website (e.g., ?encryption=off), but most HTTP sites will not contain this text in the URL. Using this string would miss the vast majority of non-encrypted websites and is therefore ineffective for enforcing HTTPS-only browsing.
"http://" directly identifies the HTTP scheme, which is non-encrypted plaintext web traffic. Because the web filter scans URLs for strings, matching and denying URLs that begin with or contain "http://" is the most straightforward way to block access to non-encrypted websites. This aligns with the fundamental distinction between HTTP (no TLS) and HTTPS (TLS-encrypted).
"www.*.com" is not an encryption-related indicator; it is an attempt at a wildcard domain pattern. It would also be overly broad and could block many legitimate sites regardless of whether they use HTTPS. Additionally, many valid websites do not use "www" and many are not in the .com TLD, so it is both inaccurate and unrelated to the goal of blocking non-encrypted access.
":443" refers to the common TCP port for HTTPS, but it is not a reliable string to detect encryption in a URL. Most users do not explicitly specify ":443" in URLs, so the filter would miss most HTTPS/HTTP cases. Also, port numbers do not guarantee encryption—services can run on 443 without TLS, and HTTPS can be served on nonstandard ports.
Core concept: This question tests recognizing encrypted vs. non-encrypted web traffic by URL scheme and how a basic URL-string-matching web filter can enforce secure browsing. In web URLs, the scheme (also called protocol) indicates how the browser should connect: HTTP is plaintext, while HTTPS uses TLS to encrypt data in transit. Why the answer is correct: To prohibit access to non-encrypted websites, the analyst should block URLs that use the non-encrypted scheme. The clearest string to match is "http://" because it explicitly indicates an HTTP URL, which does not provide confidentiality or integrity protections. A filter that denies access when it finds "http://" will prevent users from visiting sites via plaintext HTTP. Key features and best practices: Blocking "http://" is a simple control that aligns with the broader best practice of enforcing TLS for web browsing (often paired with redirecting HTTP to HTTPS, HSTS, and TLS inspection where appropriate). In enterprise environments, web proxies/secure web gateways commonly enforce HTTPS-only policies, block downgrade attempts, and may also block known-bad categories. However, because this question states the filter scans the URL for strings, the most reliable indicator available at the URL level is the scheme prefix. Common misconceptions: Many people associate encryption with port 443, but the presence or absence of ":443" in a URL is not a reliable indicator of encryption. HTTPS commonly uses 443, but users typically do not include the port in the URL, and other services can run on 443 without being HTTPS. Similarly, "encryption=off" is not a standard URL component and would only match a specific query parameter if a site happened to use it. "www.*.com" is a wildcard-like pattern that would overblock and is unrelated to encryption. Exam tips: For Security+ questions about encrypted web access, remember: HTTP (port 80) is plaintext; HTTPS (port 443) uses TLS. When the control is URL string matching, look for the scheme (http:// vs https://) rather than ports or nonstandard parameters. Also note that blocking HTTP does not guarantee the destination is trustworthy—only that the transport is encrypted.
During a security incident, the security operations team identified sustained network traffic from a malicious IP address: 10.1.4.9. A security analyst is creating an inbound firewall rule to block the IP address from accessing the organization’s network. Which of the following fulfills this request?
This denies inbound traffic from any source (0.0.0.0/0) to destination 10.1.4.9/32. That would block traffic headed to 10.1.4.9, effectively protecting that specific destination host (if it is inside your network). It does not block traffic originating from 10.1.4.9, so it fails the requirement to stop the malicious IP from accessing the organization.
This denies inbound traffic with source 10.1.4.9/32 to any destination (0.0.0.0/0). That matches the requirement: block the malicious IP from reaching any internal system. Using /32 targets only that single host, and using any destination ensures the attacker cannot access any address behind the firewall.
This is the opposite of what is needed: it permits inbound traffic from source 10.1.4.9/32 to any destination. During an incident, a permit rule would explicitly allow the malicious host to continue communicating with internal targets, increasing risk and undermining containment efforts.
This permits inbound traffic from any source to destination 10.1.4.9/32. It not only fails to block the malicious IP, but it also explicitly allows traffic to 10.1.4.9. Like option A, it focuses on the destination being 10.1.4.9 rather than blocking 10.1.4.9 as the source of malicious inbound traffic.
Core Concept: This question tests firewall/ACL logic: direction (inbound), action (deny), and correct placement of IPs in source vs. destination fields. Inbound rules evaluate traffic entering the organization from external sources, so the malicious host must be matched as the source address. Why the Answer is Correct: To block a malicious IP (10.1.4.9) from accessing the organization’s network, the inbound rule must deny packets whose source is 10.1.4.9, regardless of which internal destination they target. Option B does exactly that: it denies inbound IP traffic with source 10.1.4.9/32 to destination 0.0.0.0/0 (any). In practical terms, this prevents that host from initiating connections to any address reachable behind the firewall. Key Features / Best Practices: - Use a /32 mask for a single host block. - Place the malicious IP in the source field for inbound filtering. - Use “any” destination (0.0.0.0/0) when you want to block access to all internal targets. - Ensure rule ordering: in many ACL implementations, rules are processed top-down, first match wins. A broader “permit any” above the deny would negate the block. - Consider logging on the deny rule during an incident to support detection/forensics, but be mindful of log volume. Common Misconceptions: A common mistake is swapping source and destination. Option A denies traffic destined to 10.1.4.9, which would protect that host (if it were internal) rather than block it as an attacker. Another trap is choosing “permit” rules (C or D), which would explicitly allow the malicious traffic. Exam Tips: - For inbound rules: attacker is typically the source; your network is the destination. - “Block an IP from accessing us” usually means deny where source = attacker. - Read CIDR carefully: /32 = single IP; /0 = any. - Always sanity-check: does the rule stop traffic coming from the bad IP, or does it stop traffic going to it?
A technician is deploying a new security camera. Which of the following should the technician do?
Configuring the correct VLAN is a strong security architecture practice (segmentation of IoT/cameras, limiting lateral movement, applying ACLs). However, it’s not the most fundamental first step for “deploying a new security camera.” You typically perform a site survey first to determine placement and connectivity needs, then implement the VLAN and firewall rules once you know the camera’s network path and recording architecture.
A vulnerability scan can help identify outdated firmware, weak services, or misconfigurations after the camera is deployed. It is not usually the primary action during initial deployment because embedded/IoT devices can be sensitive to scanning, and scanning doesn’t solve the core deployment challenge of ensuring proper coverage, lighting, and placement. Scanning is better categorized as validation/operations after installation.
Disabling unnecessary ports/services (e.g., Telnet, UPnP, unused management interfaces) is a best practice for hardening cameras and reducing attack surface. Still, the question focuses on deploying a new camera, where the most critical initial activity is ensuring the camera will meet surveillance objectives in its physical environment. Hardening is important but typically follows placement and connectivity planning.
A site survey is the correct step because it ensures the camera will provide effective coverage and usable footage. It evaluates field of view, blind spots, lighting, mounting location, tamper risks, and practical needs like power/PoE, cable routes, and wireless signal. In Security+ terms, it’s part of designing and implementing physical security controls to meet security requirements before final configuration.
Core Concept: Deploying a physical security control (a security camera) requires planning for placement, coverage, lighting, power, mounting, and network connectivity. In Security+ terms, this aligns with physical security design and secure architecture considerations, where you validate that the control will meet the security objective (visibility/deterrence/forensics) before and during installation. Why the Answer is Correct: Conducting a site survey is the most appropriate action when deploying a new security camera because it determines the optimal location and configuration to achieve required coverage and image quality. A site survey evaluates line-of-sight, field of view, potential obstructions, lighting conditions (day/night, glare, backlighting), mounting height/angle, environmental exposure (weather, vibration), and tamper risks. It also confirms practical requirements such as cable runs, PoE availability, wireless signal strength (if applicable), and whether the camera placement complies with policy and privacy requirements. Key Features / Best Practices: A proper camera site survey includes verifying coverage of critical assets and entry/egress points, avoiding blind spots, ensuring sufficient illumination or IR capability, confirming retention and resolution requirements for identification, and planning secure network placement (e.g., camera VLAN, ACLs, NVR placement). It also considers physical hardening (tamper-resistant housings, protected conduit) and operational needs (maintenance access, cleaning, signage). Common Misconceptions: Configuring a VLAN and disabling ports are valid hardening steps, but they come after you know where and how the camera will be installed and connected. A vulnerability scan is not the first step in “deploying” a camera; it’s typically part of ongoing security assessment once the device is installed and reachable, and it may be limited by vendor support and risk of disrupting embedded devices. Exam Tips: For questions about installing physical security devices (cameras, badge readers, sensors), look for planning actions like “site survey” or “walkthrough” as the first and best step. Network segmentation and device hardening are important, but the exam often tests sequencing: validate physical placement and requirements first, then implement network/security configurations and monitoring.
A security analyst is reviewing alerts in the SIEM related to potential malicious network traffic coming from an employee’s corporate laptop. The security analyst has determined that additional data about the executable running on the machine is necessary to continue the investigation. Which of the following logs should the analyst use as a data source?
Application logs record events generated by a specific application (e.g., web server access logs, database logs, email server logs). They can help if the suspicious activity is clearly tied to that application’s own logging, but they generally do not provide comprehensive OS-level details about arbitrary executables, parent/child processes, or file hashes across the endpoint.
IPS/IDS logs provide detections based on network signatures, anomalies, or policy violations. They are excellent for identifying potentially malicious network traffic and indicators of compromise on the wire, but they typically cannot attribute the traffic to a specific executable on the host without additional endpoint telemetry or advanced network-to-host correlation data.
Network logs (e.g., NetFlow, firewall logs, proxy logs, DNS logs) show source/destination IPs, ports, protocols, domains, and sometimes URLs. They help confirm what the laptop communicated with and when, but they usually do not identify the exact process/executable responsible for generating the traffic on the endpoint.
Endpoint logs (EDR/agent logs, Sysmon, OS security auditing, auditd) capture host-based telemetry such as process creation, executable path, hashes, command-line arguments, user context, and process trees. This is the most direct data source to identify and investigate the executable running on the corporate laptop that is associated with the suspicious network activity.
Core concept: This question tests selecting the correct log source to obtain process/executable-level telemetry from a specific host. In Security+ terms, that is endpoint visibility (EDR/agent logs, Sysmon, OS auditing), not purely network or perimeter detection. Why the answer is correct: The analyst needs “additional data about the executable running on the machine.” Details about an executable (process name, full path, hash, parent/child process tree, command-line arguments, user context, signature status, loaded modules, persistence mechanisms) are collected on the endpoint. Endpoint logs (from EDR tools like Microsoft Defender for Endpoint/CrowdStrike, or Windows event logs enhanced by Sysmon, or Linux auditd) provide the necessary host-based evidence to correlate the SIEM network alert to a specific process generating the traffic. Key features/best practices: Endpoint telemetry commonly includes process creation events, network connection events mapped to process IDs, file creation/modification, registry changes, and reputation/hash lookups. Best practice is to forward high-value endpoint events to the SIEM and ensure time synchronization (NTP) so process events align with network alerts. For deeper investigation, analysts often pivot on file hash (SHA-256), command line, and parent process to identify initial execution vectors (phishing, drive-by, LOLBins). Common misconceptions: “Network” logs can show suspicious connections but usually cannot reliably identify the exact executable on a host without endpoint correlation. IDS/IPS alerts indicate malicious patterns/signatures on traffic but also lack definitive process attribution. “Application” logs are typically produced by a specific application (e.g., web server, database) and may not capture OS-level process execution details unless the application itself logs that information. Exam tips: When a question asks for information about what is running on a device (process, executable, hash, command line, user context), choose endpoint/EDR/host logs. When it asks about traffic patterns, flows, or packets, choose network/IDS/IPS. If it asks about a specific service’s internal errors or transactions, choose application logs.
Want to practice all questions on the go?
Download Cloud Pass for free — includes practice tests, progress tracking & more.
A systems administrator works for a local hospital and needs to ensure patient data is protected and secure. Which of the following data classifications should be used to secure patient data?
Private can describe information intended to be kept from public disclosure, and patient records are certainly private in a general sense. However, “Private” is not a standard, consistently used classification label in many formal classification schemes tested on Security+. Exams more commonly use “Sensitive” or “Confidential” to indicate regulated personal data requiring strict controls.
Critical typically refers to data or systems essential to mission/business operations where loss of availability or integrity would cause major disruption (e.g., life-safety systems, core EHR uptime). While hospital systems can be critical, the question is about securing patient data specifically, which is primarily a confidentiality and privacy classification issue rather than operational criticality.
Sensitive is the best classification for patient data (PHI/ePHI) because it requires strong confidentiality protections and careful handling due to legal/regulatory requirements and the harm that could result from unauthorized disclosure. This classification commonly triggers encryption, strict access controls, auditing, and DLP—controls appropriate for medical records in a hospital environment.
Public data is intended for anyone to access and generally requires minimal confidentiality controls (e.g., marketing materials, published hospital visiting hours). Patient data is the opposite of public; classifying it as public would lead to insufficient safeguards and would violate privacy expectations and likely regulatory requirements.
Core Concept: This question tests data classification—labeling data based on its confidentiality, regulatory requirements, and business impact if disclosed, altered, or destroyed. In healthcare, patient data (e.g., PHI/ePHI under HIPAA) requires stronger controls than general internal data because unauthorized disclosure can cause patient harm and legal penalties. Why the Answer is Correct: Patient data should be classified as Sensitive because it contains personally identifiable and medical information that must be protected from unauthorized access and disclosure. “Sensitive” is a common classification used in Security+ contexts to indicate data that requires enhanced safeguards (access control, encryption, auditing, and strict handling procedures). In hospitals, PHI/ePHI is the textbook example of sensitive data due to privacy laws and the high impact of a breach. Key Features / Best Practices: A “Sensitive” classification typically drives requirements such as: - Least privilege and role-based access control (RBAC) aligned to job duties (nurses, physicians, billing). - Strong authentication (MFA) and session controls. - Encryption in transit (TLS) and at rest (database/disk encryption), plus key management. - Data loss prevention (DLP) rules to prevent exfiltration via email, web uploads, or removable media. - Logging, monitoring, and audit trails for access to medical records (often required for compliance). - Secure disposal and retention policies (records management). These align with common security frameworks and regulatory expectations (e.g., HIPAA Security Rule safeguards). Common Misconceptions: “Private” sounds correct because PHI is private, but “Private” is not a consistently defined classification label across organizations; it’s often used informally or as a synonym for “confidential/sensitive.” “Critical” refers more to operational importance (availability/mission impact) rather than privacy requirements. “Public” is clearly incorrect because it implies no confidentiality controls. Exam Tips: For Security+ questions, map the scenario to the classification that implies heightened confidentiality controls. Healthcare, finance, legal, and HR records usually fall under “Sensitive/Confidential.” If the question emphasizes privacy/regulatory protection of personal records, choose “Sensitive” over labels that focus on uptime (“Critical”) or broad accessibility (“Public”).
An employee receives a text message that appears to have been sent by the payroll department and is asking for credential verification. Which of the following social engineering techniques are being attempted? (Choose two.)
Typosquatting involves registering or using a look-alike domain name (e.g., payroII.example.com vs payroll.example.com) to trick users into visiting a malicious site. The scenario describes a text message requesting credential verification, not a deceptive domain or URL manipulation technique. Typosquatting could be involved if a link used a similar domain, but that detail is not provided.
Phishing is the general category of attempts to trick users into revealing sensitive information through fraudulent communications. This scenario is phishing in a broad sense, but the exam typically expects the more specific term based on the channel. Because the message is a text message, “smishing” is the best match rather than the generic “phishing.”
Impersonation is present because the attacker is pretending to be the payroll department, leveraging perceived authority and trust to increase compliance. This is a common social engineering tactic used to elicit credentials, MFA codes, or personal data. In real environments, attackers often impersonate HR/payroll because employees expect payroll-related requests and may respond quickly.
Vishing is voice phishing conducted over phone calls or voice systems (live calls, IVR, voicemail). The scenario explicitly states the employee receives a text message, not a call. If the attacker had called claiming to be payroll and asked for credentials, vishing would apply. Here, the correct channel-specific term is smishing.
Smishing is phishing delivered via SMS/text messages or messaging apps. The attacker uses a text that appears to come from payroll and asks for credential verification, which is a classic smishing pattern. Smishing often includes malicious links to fake login portals or prompts the user to reply with sensitive information, exploiting the immediacy and trust users place in mobile messages.
Misinformation refers to false or misleading information spread to influence opinions or cause confusion, often in the context of propaganda or disinformation campaigns. While the text message is deceptive, its goal is credential theft rather than shaping beliefs or narratives. Therefore, misinformation is not the best classification for this credential-harvesting social engineering attempt.
Core concept: This question tests recognition of social engineering delivery methods and tactics. Social engineering often combines (1) a communication channel (email, phone, SMS) with (2) a psychological technique (authority, urgency, impersonation) to trick a user into revealing credentials. Why the answer is correct: The message is a text message, which makes it smishing (SMS phishing). Smishing is specifically phishing conducted via SMS/text platforms, often containing a link to a fake login page or requesting a reply with sensitive information. It also “appears to have been sent by the payroll department,” which is impersonation. Impersonation is when an attacker pretends to be a trusted entity (e.g., payroll, IT help desk, a manager, a vendor) to exploit trust and authority. Requesting “credential verification” is a classic pretext used to harvest usernames/passwords or MFA codes. Key features / best practices: Common indicators include unexpected credential requests, urgency (“verify now”), shortened/obfuscated links, and sender spoofing. Defenses include user awareness training, verifying requests out-of-band (call payroll using a known number), enforcing MFA (prefer phishing-resistant methods like FIDO2/WebAuthn), using conditional access, and implementing mobile device protections (SMS filtering, MDM, and blocking unknown links). Common misconceptions: Many test-takers choose “phishing” because it’s the umbrella term. While true in a broad sense, CompTIA expects the more precise channel-specific term when provided (smishing for SMS, vishing for voice calls). Typosquatting is about look-alike domains/URLs, not the act of texting. Misinformation is about spreading false information to influence beliefs, not credential theft. Exam tips: When you see “text message” or “SMS,” think smishing. When you see “phone call” or voicemail, think vishing. If the attacker pretends to be a department/person (payroll/IT/CEO), add impersonation. Multi-select questions often pair the delivery method with the tactic used to build trust.
Which of the following provides the details about the terms of a test with a third-party penetration tester?
Rules of engagement (RoE) define how a penetration test will be conducted. They document scope and exclusions, authorized tactics, testing windows, communication and escalation procedures, safety constraints (e.g., avoid DoS), and legal authorization. RoE protects both the organization and tester by ensuring the activity is approved, controlled, and aligned with business and operational requirements.
Supply chain analysis evaluates risks introduced by third parties and dependencies (vendors, software components, logistics, service providers). It focuses on identifying and mitigating supplier-related threats (e.g., compromised updates, counterfeit hardware, vendor access risks). It does not provide the operational terms and boundaries for conducting a specific penetration test engagement.
A right to audit clause is a contract provision allowing a customer to audit a vendor’s controls, processes, or compliance (e.g., SOC reports, onsite assessments) to verify security obligations. While related to third-party oversight, it does not specify the detailed conduct of a penetration test (scope, timing, allowed techniques) like rules of engagement do.
Due diligence is the process of evaluating a third party before entering or continuing a business relationship. It includes reviewing security posture, financial stability, compliance, and risk controls. Due diligence may lead to requiring a pentest, but it does not define the specific terms, constraints, and procedures for the pentest itself.
Core Concept: This question tests governance and oversight for third-party security testing. When an organization hires an external penetration tester, the engagement must be formally defined to ensure the test is legal, safe, and aligned with business objectives. The document that captures these specifics is typically called the Rules of Engagement (RoE), often paired with a Statement of Work (SoW) and authorization letter. Why the Answer is Correct: Rules of engagement provide the detailed terms of the penetration test: what systems are in scope, what is out of scope, the testing window, allowed techniques (e.g., social engineering permitted or prohibited), escalation paths, communication requirements, data handling, and when to stop testing. RoE also clarifies legal authorization and constraints to prevent the tester’s actions from being mistaken for malicious activity and to reduce operational risk. Key Features / Best Practices: A strong RoE typically includes: scope (IP ranges, apps, facilities), objectives (validate controls, find exploitable paths), testing type (black/gray/white box), timing and maintenance windows, rate limiting to avoid DoS, prohibited actions (e.g., no production data exfiltration), credential handling, evidence collection, reporting format, severity rating approach, points of contact, incident/emergency stop procedures, and liability/indemnification boundaries. These align with common industry practices referenced in frameworks and guidance such as NIST SP 800-115 (technical guide to information security testing) and standard pentest contracting norms. Common Misconceptions: Learners may confuse RoE with “right to audit” because both involve third parties and oversight, but right-to-audit is about the customer’s ability to audit a vendor’s controls, not the operational details of a pentest. “Due diligence” and “supply chain analysis” are broader vendor risk management activities and do not define the specific conduct of a penetration test. Exam Tips: If the question mentions defining scope, boundaries, permitted tools/techniques, timing, communications, and authorization for a pentest, choose Rules of engagement. If it focuses on evaluating vendor risk, choose due diligence/supply chain analysis. If it focuses on contractual permission to inspect a vendor, choose right to audit clause.
A company decided to reduce the cost of its annual cyber insurance policy by removing the coverage for ransomware attacks. Which of the following analysis elements did the company most likely use in making this decision?
MTTR (Mean Time To Repair/Recover) measures the average time required to restore a system/service after a failure or incident. It’s useful for operational resilience and incident response performance, and it can affect downtime costs. However, it does not directly measure the annual likelihood of ransomware events, which is the key factor in deciding whether to carry or drop annual insurance coverage.
RTO (Recovery Time Objective) is the maximum acceptable downtime for a business process after an outage. It is a business continuity metric used to design DR strategies (hot/warm/cold sites, backups, replication). While ransomware can impact RTO planning, RTO is not an insurance risk frequency metric and is less directly tied to the decision to remove ransomware coverage to reduce premiums.
ARO (Annualized Rate of Occurrence) estimates how many times per year a specific threat event is expected to occur. Insurance and risk-transfer decisions commonly use ARO (often with SLE to compute ALE) to judge whether the expected annual loss justifies the premium. Dropping ransomware coverage to cut annual policy cost most closely aligns with evaluating the annual likelihood/frequency of ransomware incidents.
MTBF (Mean Time Between Failures) is a reliability/availability metric indicating the average time between inherent failures of a system or component. It is commonly used in hardware lifecycle planning and uptime engineering. Ransomware is an intentional threat event, not an inherent equipment failure, so MTBF is not the appropriate analysis element for deciding on ransomware insurance coverage.
Core Concept: This question is about risk analysis elements used to make cost/coverage decisions in cyber insurance. Insurance decisions are typically driven by quantitative or semi-quantitative risk management metrics, especially likelihood/frequency of an event and expected loss. Why the Answer is Correct: ARO (Annualized Rate of Occurrence) estimates how often a specific event (here, ransomware) is expected to occur in a year. When an organization decides to remove ransomware coverage to reduce premium costs, it is effectively accepting/retaining that risk rather than transferring it. A common driver for dropping coverage is a determination that the event’s expected frequency is low enough (low ARO), or that the premium is not justified relative to the expected occurrence and loss. In classic quantitative risk analysis, ARO is a key input to ALE (Annualized Loss Expectancy): ALE = SLE (Single Loss Expectancy) × ARO. Even if ALE isn’t explicitly mentioned, the “annual” nature of the policy aligns strongly with ARO. Key Features / Best Practices: Risk-based insurance decisions should consider: - Likelihood (ARO) and impact (SLE) to estimate annualized loss (ALE) - Control strength (backups, EDR, segmentation, immutable storage) that reduces likelihood/impact - Risk treatment options: avoid, mitigate, transfer (insurance), accept - Residual risk and risk appetite/thresholds approved by leadership Framework alignment: This maps to NIST RMF / NIST SP 800-30 concepts (likelihood and impact) and general enterprise risk management practices. Common Misconceptions: RTO and MTTR are operational recovery metrics and can influence business continuity planning and incident response maturity, but they are not the primary “analysis element” used to decide whether to buy or drop insurance coverage. MTBF is a reliability metric for hardware/systems and is largely unrelated to ransomware insurance decisions. Exam Tips: When you see “annual” and “insurance/risk cost,” think quantitative risk terms: ARO, SLE, ALE. When you see “how quickly to recover,” think RTO/MTTR. When you see “time between failures,” think MTBF.
Which of the following should a security administrator adhere to when setting up a new set of firewall rules?
A disaster recovery plan (DRP) focuses on restoring IT systems after a major outage or disaster (e.g., ransomware, fire, data center failure). It covers recovery strategies, RTO/RPO targets, backups, and restoration steps. While firewall configurations may be included as part of recovery documentation, DRP is not the procedure you follow for routine creation of new firewall rules in normal operations.
An incident response procedure guides detection, containment, eradication, and recovery during a security incident. Firewall rule changes can be part of containment (e.g., blocking an IP or port during an attack), but the question asks about setting up a new set of rules generally. For planned rule changes, the correct governance control is change management; IR is for active or suspected incidents.
A business continuity plan (BCP) ensures critical business functions continue during and after a disruption, often using alternate processes, sites, or workarounds. It is broader than IT and focuses on maintaining operations. Although firewall availability can affect continuity, BCP does not define the approval, testing, documentation, and rollback workflow required for implementing new firewall rules.
A change management procedure is the correct control for implementing new firewall rules. It requires formal requests, risk/impact analysis, approvals, testing, scheduled implementation, documentation, and rollback planning. This reduces outages and security misconfigurations, supports least privilege, and provides auditability and accountability. Firewall rule changes are classic examples of changes that must go through change control.
Core concept: This question tests governance around making security-impacting configuration changes. Firewall rule creation/modification is a high-risk change because it can unintentionally expose services, break connectivity, or violate compliance requirements. In Security+ terms, this aligns with change control/change management as part of security program management and oversight. Why the answer is correct: A security administrator should adhere to the change management procedure when setting up new firewall rules. Change management ensures changes are requested, reviewed, approved, tested, implemented in a controlled manner, and documented with a rollback plan. It also enforces separation of duties and accountability (who requested vs. who approved vs. who implemented), reducing the chance of unauthorized or poorly planned rule changes. Key features/best practices: Proper change management for firewall rules typically includes: a formal change request with business justification; risk/impact analysis (what traffic is allowed/blocked, affected subnets, dependencies); peer/security review to validate least privilege and alignment with policy; testing in a staging environment when possible; scheduling during maintenance windows; implementation steps and verification (connectivity tests, log review); backout/rollback procedures; and updating documentation (network diagrams, rulebase comments, ticket references). Frameworks like ITIL change enablement and common audit expectations (e.g., evidence of approvals and traceability) reinforce this. Common misconceptions: Disaster recovery plans and business continuity plans are about restoring operations after major disruptions, not controlling routine configuration changes. Incident response procedures guide actions during/after a security event, but creating new firewall rules as part of normal operations (or even as a planned security improvement) should still follow change control unless it’s an emergency change—then the emergency change process applies. Exam tips: When you see “setting up new rules,” “modifying configurations,” “patching,” or “upgrading,” think change management. If the scenario says “during an active attack,” then incident response may be primary, but even then many organizations require emergency change documentation after the fact. For Security+, default to governance controls that prevent unauthorized changes and ensure traceability: change management is the best match.
Download Cloud Pass and access all SY0-701: CompTIA Security+ practice questions for free.
Want to practice all questions on the go?
Get the free app
Download Cloud Pass for free — includes practice tests, progress tracking & more.