SY0-701: CompTIA Security+

This is incorrect because the first rule permits DNS from any source to any destination on port 53, which already allows all outbound DNS. The second rule then denies DNS from 10.50.10.25, which is the opposite of the requirement. Additionally, due to top-down processing, the initial broad permit would match first and the deny would never effectively restrict traffic as intended.

This is incorrect because it reverses the meaning of the destination. It permits traffic from any source to destination 10.50.10.25 on port 53, which would be relevant for inbound DNS to an internal DNS server, not outbound DNS originating from that host. The subsequent deny blocks all DNS to any destination, which would still not correctly allow 10.50.10.25 to query external DNS.

This is incorrect because, like option A, it begins with a broad permit allowing DNS from any source to any destination on port 53, which defeats the goal of limiting outbound DNS. The deny rule also targets traffic destined to 10.50.10.25, not sourced from it, so it does not implement “only this internal host may originate DNS.”

Brand impersonation is when an attacker pretends to be a trusted company (logos, sender name, look-and-feel) to gain credibility. It commonly appears as a component of phishing, but by itself it’s broader and doesn’t necessarily involve credential harvesting. In this question, the key behavior is an email link leading to credential entry, which more directly maps to phishing.

Pretexting involves creating a believable fabricated scenario (a “pretext”) to manipulate a target into providing information or performing actions, often through interactive communication (calls, chats, repeated exchanges). While the email claims to be from a payment site, the scenario is not an extended story or interactive persuasion; it’s a straightforward credential-harvesting lure typical of phishing.

Typosquatting relies on registering a domain name that is a close misspelling or variation of a legitimate domain (e.g., rnicrosoft.com vs. microsoft.com) to trick users who don’t notice the difference. The question provides no evidence of a look-alike URL or misspelled domain—only that a link was clicked and credentials were entered—so typosquatting cannot be concluded.

NGFWs add capabilities beyond traditional firewalls (application identification, IPS, URL filtering, SSL inspection). They can help reduce risk from known exploit traffic, but they are not purpose-built for detailed web application parameter validation and virtual patching. For a compromise of a website via crafted HTTP input, a WAF is typically the more precise and effective control at the application layer.

TLS encrypts data in transit and provides server (and optionally client) authentication, preventing eavesdropping and tampering between client and server. However, TLS does not stop an attacker from sending malicious but properly encrypted requests to the application. A buffer overflow is an application vulnerability; encryption does not validate input safety or prevent memory corruption exploits.

SD-WAN is a networking technology for managing WAN connectivity using centralized control, dynamic path selection, and improved performance/reliability across multiple links. While it may include security features in some implementations, its primary purpose is connectivity and traffic engineering, not specialized protection against web application exploits like buffer overflows.

Canceling current employee recognition gift cards is not directly responsive to the smishing attempt. The scam is about fraudulent purchasing and exfiltration of gift card codes, not compromise of an existing gift card program. Canceling legitimate cards may disrupt business operations and does not address the root cause (social engineering). A better response is warning users and reinforcing verification procedures.

Having the CEO change phone numbers is usually unnecessary and ineffective. Smishing/impersonation often uses spoofed numbers or lookalike identities; changing the CEO’s number does not prevent attackers from claiming to be the CEO again. It also creates operational disruption. The better approach is verification procedures and awareness rather than changing identifiers.

Conducting a forensic investigation on the CEO’s phone is not the best initial response given the facts. The scenario indicates impersonation via SMS, not confirmed compromise of the CEO’s device. Forensics is appropriate when there are indicators of device compromise (malware, suspicious logins, SIM swap evidence). Here, immediate user warning and training updates are higher-value responses.

Implementing mobile device management can improve mobile security posture (policy enforcement, app control, device compliance), but it is not the best direct response to an SMS impersonation/gift-card scam. MDM typically won’t prevent an attacker from sending fraudulent texts to employees. It’s a broader architectural control and may be beneficial long-term, but it’s not the top response for this specific incident.

A legally enforceable corporate acquisition policy improves internal governance (who can buy, from where, required approvals), but by itself it doesn’t validate authenticity or provenance. Policies can be ignored, misapplied, or fail to address upstream risks like sub-tier suppliers and logistics substitution. It’s supportive, but not the best single control for counterfeit hardware risk.

A right to audit clause can help verify a vendor’s processes and compliance, and it can deter poor practices. However, audits are periodic, may be limited by scope, and can be difficult to execute across multi-tier supply chains. It’s a useful contractual safeguard, but it is not as directly preventative as comprehensive supply chain analysis and validation.

Penetration testing suppliers and vendors evaluates their security posture and potential vulnerabilities in their networks or applications. It does not reliably detect counterfeit hardware, unauthorized component substitution, or tampering during manufacturing/shipping. Counterfeit risk is primarily a procurement/provenance and chain-of-custody problem, not a problem solved by offensive security testing.

ACLs (Access Control Lists) filter traffic based on simple criteria such as source/destination IP, port, and protocol. While an ACL can block traffic from known bad IPs or restrict risky ports, it does not inspect payloads to match exploit signatures (e.g., specific browser exploit patterns in HTTP). Therefore, it is not the best tool for monitoring and blocking known signature-based browser exploit attacks.

DLP (Data Loss Prevention) is designed to detect and prevent unauthorized disclosure of sensitive data (PII, PHI, PCI, intellectual property) via email, web uploads, removable media, or cloud services. It is not primarily used to stop inbound exploit attempts against browsers, nor does it typically rely on exploit signatures for prevention. DLP might help after compromise (exfiltration control), but it doesn’t best meet the stated need.

An IDS (Intrusion Detection System) uses signatures and/or anomaly detection to monitor traffic and generate alerts when malicious patterns are observed. However, IDS is typically deployed out-of-band (SPAN/TAP) and does not block traffic by default. It provides visibility and detection, but the question explicitly requires the ability to both monitor and block known signature-based attacks, which is more aligned with IPS.

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.

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.

Jailbreaking is the process of removing manufacturer or OS restrictions (commonly on iOS) to gain elevated privileges and install unauthorized software or tweaks. It weakens built-in security controls like sandboxing and code-signing enforcement. While jailbreaking can enable installing apps outside the official store, the question specifically describes the act of installing from outside the approved repository, which is sideloading.

Memory injection is an exploitation technique where an attacker inserts and executes malicious code in the memory space of a running process (e.g., DLL injection, process hollowing). It is associated with malware execution and evasion, not with how software is obtained or installed. It does not describe installing software outside an approved repository.

Resource reuse refers to insecure reuse of resources such as memory, sessions, tokens, file handles, or identifiers without proper reinitialization or access control. This can lead to data leakage or privilege issues, but it is unrelated to application distribution channels or installing software from outside a manufacturer’s repository.

Subject role is an identity and access management concept used to determine authorization (e.g., RBAC/ABAC). While roles influence policy decisions, they are typically evaluated in the control plane (policy decision logic) rather than the data plane (traffic enforcement and segmentation). Roles can feed enforcement rules, but “subject role” itself is not a data-plane implementation element.

Adaptive identity refers to risk-based or context-aware authentication/authorization (device posture, location, behavior, step-up MFA). This is strongly associated with identity systems and policy decision processes (control plane). The data plane may enforce the resulting decision, but adaptive identity is not primarily about how traffic is segmented or routed; it’s about how trust is evaluated before allowing access.

Threat scope reduction is a desired outcome of Zero Trust (limiting blast radius and lateral movement). However, it is not a specific data-plane component to evaluate. The analyst would instead assess the mechanisms that achieve scope reduction—such as secured zones, microsegmentation, and enforcement points—rather than the abstract goal itself.

"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.

"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.

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 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.

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.

Incorrect. User awareness training is typically delivered to users (email/LMS) or enforced via policy, not “to a device.” While an inventory system could help identify who has a laptop, the sticker itself doesn’t enable training delivery or ensure the right endpoint receives it. This is more of a security program/training administration function than a direct benefit of asset tagging.

Incorrect. Mapping users to devices for software MFA tokens generally depends on identity provider enrollment, device registration, MDM/UEM records, or device certificates. A physical asset sticker is not a trusted technical identifier for MFA provisioning and is not used by MFA systems to bind tokens. Asset tagging may help administratively, but it’s not the security benefit being tested.

Incorrect. User-based firewall policies are usually targeted using user identity (directory groups), device identity (hostnames, certificates), or MDM compliance state. A sticker does not integrate with firewall policy engines and cannot be reliably used for enforcement. Proper targeting requires technical controls like NAC, endpoint agents, or directory-based policy mapping.

Incorrect. Penetration testing targets are defined by scope (IP ranges, hostnames, applications) and discovered through technical inventory and scanning, not by physical stickers. Asset tags might help correlate a discovered host to a physical device after the fact, but they don’t materially enable targeting the “desired laptops” during a test.

A perimeter network (DMZ) is a segmented network placed between the internet and the internal network, typically used to host public-facing services. While it improves segmentation, it does not by itself provide the most secure method for administrative access or minimize boundary traffic. You would still need a controlled admin entry point (like a bastion) to avoid opening management access broadly.

A WAF (Web Application Firewall) protects web applications by filtering and monitoring HTTP/HTTPS traffic, mitigating attacks like SQL injection and XSS. It is not designed to provide administrative access to internal resources or reduce management-plane exposure. Even with a WAF, you would still need a secure remote administration approach for non-web internal systems.

Single sign-on (SSO) centralizes authentication and can improve security with stronger identity controls and reduced password sprawl. However, SSO does not inherently minimize the network traffic allowed through a security boundary or reduce exposed ports/services. It addresses who can authenticate, not how many firewall openings are required for administrative connectivity.

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.