SY0-701 — CompTIA Security+ Quick Review
Quick review for CompTIA Security+ (SY0-701) candidates covering high-yield concepts, traps, decision rules, and practice focus areas.
Quick Review purpose
This Quick Review is for candidates preparing for the real CompTIA Security+ (SY0-701) exam. Use it as a fast, practical refresher before moving into topic drills, mock exams, and detailed explanations in an IT Mastery question bank.
The goal is not to replace full study. The goal is to help you quickly reconnect major concepts, spot common traps, and practice choosing the best answer when multiple options sound plausible.
This page is IT Mastery exam-prep support and is not affiliated with CompTIA.
How to use this page before practice
- Scan the decision tables first. They help with “best,” “first,” and “most likely” questions.
- Mark weak areas. If a row feels vague, turn it into a topic drill.
- Practice by objective style, not just by definition. Security+ questions often ask what to do next, what control is most appropriate, or what risk is being reduced.
- Review every explanation. For missed questions, the explanation is where you learn why the tempting answer was not best.
High-yield exam mindset
Security+ questions usually reward practical judgment:
| If the question emphasizes… | Think first about… |
|---|---|
| “Best control” | Control objective, placement, and feasibility |
| “First step” | Identify, preserve, validate, or contain before fixing |
| “Most likely attack” | Clues in symptoms, logs, user behavior, or network traffic |
| “Reduce impact” | Resilience, segmentation, backup, least privilege |
| “Prevent recurrence” | Root cause, patching, hardening, policy, automation |
| “Cloud responsibility” | Whether the customer or provider controls that layer |
| “Compliance/privacy” | Data classification, minimization, retention, access control |
| “Zero Trust” | Verify explicitly, least privilege, assume breach |
Core security principles
CIA, AAA, and non-repudiation
| Concept | What it protects | Common examples | Common trap |
|---|---|---|---|
| Confidentiality | Prevents unauthorized disclosure | Encryption, access control, data masking | Encryption does not prove integrity by itself |
| Integrity | Prevents unauthorized alteration | Hashing, digital signatures, checksums | Hashing is not encryption |
| Availability | Keeps systems usable | Redundancy, clustering, backups, DDoS protection | A backup alone does not guarantee rapid recovery |
| Authentication | Proves identity | Passwords, certificates, biometrics, tokens | Authentication is not authorization |
| Authorization | Grants permissions | RBAC, ABAC, ACLs, policy engines | “Logged in” does not mean “allowed” |
| Accounting/Auditing | Records activity | Logs, SIEM, audit trails | Logs are useful only if collected, protected, and reviewed |
| Non-repudiation | Prevents credible denial of action | Digital signatures, signed logs | Hashes alone do not identify who performed an action |
Security control categories
Security+ often tests whether you can classify a control by purpose and implementation type.
| Control type | Purpose | Examples |
|---|---|---|
| Preventive | Stops an event before it occurs | MFA, firewall rules, least privilege, secure coding |
| Detective | Finds events that occurred or are occurring | IDS, SIEM alerts, audit logs, file integrity monitoring |
| Corrective | Restores after an event | Patch, restore from backup, reimage endpoint |
| Deterrent | Discourages behavior | Warning banners, guards, visible cameras |
| Compensating | Alternative when primary control is not feasible | Extra monitoring when legacy systems cannot be patched |
| Directive | Tells people what to do | Policies, standards, procedures, signs |
| Physical | Protects facilities/devices | Locks, mantraps, cameras, fencing |
| Technical | Uses technology | Encryption, EDR, NAC, WAF |
| Administrative | Uses process/governance | Training, policies, vendor reviews, risk assessments |
Trap: A camera is usually detective if it records evidence, but it can also be deterrent if the question emphasizes discouraging intruders.
Identity and access management
Authentication factors
| Factor | Meaning | Examples |
|---|---|---|
| Something you know | Knowledge | Password, PIN |
| Something you have | Possession | Smart card, hardware token, authenticator app |
| Something you are | Inherence | Fingerprint, face, iris |
| Somewhere you are | Location | Geofencing, source network |
| Something you do | Behavior | Typing cadence, gesture pattern |
MFA trap: Two passwords are not MFA. MFA requires different factor types.
Access control models
| Model | Best clue in a question | Typical use |
|---|---|---|
| RBAC | Access based on job role | Employees grouped by function |
| ABAC | Access based on attributes | User, device, time, location, data sensitivity |
| DAC | Resource owner grants access | File owner shares a file |
| MAC | Central authority and labels | Highly controlled environments |
| Rule-based | If/then rules | Firewall ACLs, conditional access policies |
| Least privilege | Minimum access needed | Reducing blast radius |
| Just-in-time access | Temporary privilege elevation | Admin access only during approved window |
| Privileged access management | Controls/administers privileged accounts | Vaulting, session recording, approval workflows |
Federation and identity protocols
| Technology | What to remember |
|---|---|
| SAML | Common for browser-based enterprise SSO using assertions |
| OAuth | Authorization framework; often used for delegated access |
| OpenID Connect | Authentication layer built on OAuth 2.0 |
| Kerberos | Ticket-based authentication in many enterprise environments |
| RADIUS | Centralized AAA, often for VPN/Wi-Fi/network access |
| TACACS+ | Device administration AAA; separates authn/authz/accounting |
| LDAP/LDAPS | Directory access; LDAPS protects LDAP with TLS |
| SSO | One authentication grants access to multiple services |
| FIM | Federated identity management across organizations or domains |
Decision rule: If the question involves delegated access to an API, think OAuth. If it involves enterprise web SSO assertions, think SAML. If it involves identity claims plus login, think OpenID Connect.
Cryptography and PKI
Know the function, not just the term
| Mechanism | Primary purpose | Key exam distinction |
|---|---|---|
| Symmetric encryption | Fast confidentiality | Same key encrypts and decrypts |
| Asymmetric encryption | Key exchange, signatures, confidentiality | Public/private key pair |
| Hashing | Integrity verification | One-way; no decryption |
| Digital signature | Integrity, authentication, non-repudiation | Hash encrypted/signed with private key |
| Certificate | Binds public key to identity | Issued/validated through PKI |
| HMAC | Integrity plus shared secret authentication | Uses hash plus secret key |
| Salting | Defends stored password hashes | Adds unique random value before hashing |
| Key stretching | Slows brute force attacks | PBKDF2, bcrypt, scrypt, Argon2-style concept |
| Perfect forward secrecy | Protects past sessions if long-term key is compromised | Uses ephemeral session keys |
PKI quick path
| Component | Role |
|---|---|
| CA | Issues certificates |
| Root CA | Top trust anchor |
| Intermediate CA | Issues certificates while protecting root CA |
| CSR | Request containing public key and identity details |
| CRL/OCSP | Certificate revocation checking |
| HSM | Hardware protection for cryptographic keys |
| TPM | Hardware root of trust on endpoint |
| Secure enclave | Isolated hardware-backed key/secret processing |
Common trap: Encoding, hashing, and encryption are different.
- Encoding changes format and is reversible without a secret.
- Hashing is one-way and supports integrity verification.
- Encryption is reversible only with the correct key.
Threats, attacks, and indicators
Social engineering
| Attack | Clue |
|---|---|
| Phishing | Broad fraudulent email/message |
| Spear phishing | Targeted phishing against a person/group |
| Whaling | Targets executives or senior leaders |
| Vishing | Voice-based phishing |
| Smishing | SMS/text phishing |
| Pretexting | Fabricated scenario to gain trust |
| Business email compromise | Fraudulent payment or invoice request |
| Tailgating | Following someone into a secure area |
| Shoulder surfing | Observing sensitive information |
| Dumpster diving | Searching discarded materials |
| Watering hole | Compromising a site used by target group |
Best mitigation choices: user training helps, but technical controls such as MFA, email filtering, DMARC/SPF/DKIM, least privilege, and payment verification procedures are often stronger depending on the question.
Malware and endpoint threats
| Threat | Key behavior |
|---|---|
| Virus | Attaches to host file/program |
| Worm | Self-replicates across networks |
| Trojan | Disguised as legitimate software |
| Ransomware | Encrypts or exfiltrates data for extortion |
| Spyware | Collects user/system data |
| Rootkit | Hides privileged compromise |
| Logic bomb | Triggers on condition/date |
| Botnet | Remotely controlled infected hosts |
| Fileless malware | Uses memory/native tools to avoid disk artifacts |
| Cryptojacking | Abuses resources to mine cryptocurrency |
Trap: If the malware spreads without user action, a worm is more likely than a virus.
Application and web attacks
| Attack | What happens | High-value mitigation |
|---|---|---|
| SQL injection | Input alters database query | Parameterized queries, input validation |
| XSS | Malicious script runs in user browser | Output encoding, input validation, CSP |
| CSRF | User’s authenticated session performs unwanted action | Anti-CSRF tokens, SameSite cookies |
| SSRF | Server is tricked into making internal/external requests | Egress filtering, metadata protections |
| Path traversal | Attacker accesses unintended files | Normalize paths, restrict file access |
| Command injection | Input executes OS commands | Avoid shell calls, validate input |
| Insecure deserialization | Object data triggers code/logic abuse | Validate/sign serialized data |
| Buffer overflow | Memory overwritten | Bounds checking, memory-safe practices |
| Race condition | Timing flaw changes outcome | Locking, atomic operations |
| API abuse | Broken auth, excessive data exposure, weak rate limits | Strong auth, schema validation, throttling |
Password and credential attacks
| Attack | Key clue | Mitigation |
|---|---|---|
| Brute force | Tries many combinations | Lockout, MFA, rate limiting |
| Password spraying | Few common passwords across many accounts | MFA, monitoring, password policy |
| Credential stuffing | Reuses breached credentials | MFA, breached-password detection |
| Pass-the-hash | Uses password hash without knowing password | Credential protection, patching, least privilege |
| Golden ticket | Kerberos ticket abuse | Protect domain controllers, rotate KRBTGT after compromise |
| Rainbow table | Precomputed hash lookup | Salting and strong hashing |
Vulnerability management
Practical workflow
flowchart LR
A[Discover assets] --> B[Scan or assess]
B --> C[Validate findings]
C --> D[Prioritize risk]
D --> E[Remediate or mitigate]
E --> F[Rescan and verify]
F --> G[Document exceptions]
Prioritization factors
Do not rely only on a severity label. Prioritize using context.
| Factor | Why it matters |
|---|---|
| Exploitability | A critical flaw with active exploitation moves up |
| Exposure | Internet-facing systems usually carry higher urgency |
| Asset criticality | Business-critical or sensitive-data systems matter more |
| Compensating controls | Segmentation or WAF may reduce immediate risk |
| Patch availability | Fixable issues can move quickly |
| Business impact | Downtime risk may affect remediation timing |
| Regulatory/contractual impact | Sensitive data and obligations may change priority |
Trap: A vulnerability scan finding is not always proof of exploitability. Validate false positives before disruptive remediation.
Assessment types
| Assessment | Purpose |
|---|---|
| Vulnerability scan | Finds known weaknesses or misconfigurations |
| Credentialed scan | More accurate internal view using valid credentials |
| Penetration test | Attempts exploitation to demonstrate risk |
| Red team | Goal-based adversary simulation |
| Blue team | Defenders monitoring and responding |
| Purple team | Collaboration to improve detection and response |
| Bug bounty | External researchers report vulnerabilities |
| Configuration audit | Compares systems to secure baselines |
Network security review
Segmentation and traffic control
| Control | Best use |
|---|---|
| VLAN | Logical segmentation |
| ACL | Permit/deny traffic based on rules |
| Firewall | Enforces network traffic policy |
| NGFW | Adds app/user awareness and deeper inspection |
| WAF | Protects web applications from HTTP-layer attacks |
| IDS | Detects suspicious activity |
| IPS | Blocks suspicious activity inline |
| Proxy | Intermediates requests, can filter and log |
| NAC | Controls device access to network |
| VPN | Encrypted tunnel over untrusted network |
| ZTNA | Application-specific access based on identity/context |
| Microsegmentation | Fine-grained east-west traffic control |
Decision rule: If the attack is against a web application layer, a WAF is often more specific than a traditional firewall.
Secure protocol choices
| Insecure/legacy | Prefer | Why |
|---|---|---|
| HTTP | HTTPS | TLS encryption and server authentication |
| Telnet | SSH | Encrypted remote administration |
| FTP | SFTP or FTPS | Protected file transfer |
| SNMPv1/v2 | SNMPv3 | Authentication and encryption support |
| LDAP | LDAPS | Directory access over TLS |
| POP3/IMAP without TLS | Secure mail protocols with TLS | Protects credentials and messages in transit |
| SMBv1 | Modern SMB with signing/encryption where supported | Reduces legacy protocol risk |
| WEP/WPA | WPA2/WPA3 | Stronger Wi-Fi security |
| Unsecured DNS | DNSSEC / protected DNS where applicable | Integrity and privacy improvements depending on solution |
Common ports worth recognizing
| Service | Common port(s) |
|---|---|
| FTP | 20/21 |
| SSH/SFTP | 22 |
| Telnet | 23 |
| SMTP | 25 |
| DNS | 53 |
| DHCP | 67/68 |
| HTTP | 80 |
| POP3 | 110 |
| NTP | 123 |
| IMAP | 143 |
| SNMP | 161/162 |
| LDAP | 389 |
| HTTPS | 443 |
| SMB | 445 |
| Syslog | 514 |
| LDAPS | 636 |
| RDP | 3389 |
Trap: Ports help identify traffic, but modern attacks often use common allowed ports such as 443. Do not choose an answer based only on a port if the scenario gives stronger clues.
Secure architecture
Zero Trust
Zero Trust is a security model, not one product.
| Principle | Practical meaning |
|---|---|
| Verify explicitly | Use identity, device health, location, risk, and context |
| Least privilege | Grant only required access |
| Assume breach | Segment, monitor, and limit lateral movement |
| Continuous evaluation | Reassess trust during the session |
| Strong telemetry | Collect logs and signals for detection |
Trap: A VPN alone is not Zero Trust. VPNs often grant broad network access after connection.
Resilience and availability
| Concept | Meaning |
|---|---|
| Redundancy | Duplicate components to avoid single points of failure |
| Load balancing | Distributes traffic across systems |
| Clustering | Multiple systems operate together for availability/performance |
| Failover | Switches to backup system when primary fails |
| Backup | Copy of data for restoration |
| Snapshot | Point-in-time state, often fast but not a full backup strategy |
| Replication | Copies data to another system/location |
| RTO | Maximum acceptable time to restore service |
| RPO | Maximum acceptable data loss measured in time |
| MTTR | Average time to repair/recover |
| MTBF | Average time between failures |
Decision rule: If the question asks how much data loss is acceptable, think RPO. If it asks how long the service can be down, think RTO.
Cloud and shared responsibility
| Layer/question | Usually consider |
|---|---|
| Physical data center security | Cloud provider in public cloud |
| Customer data classification | Customer |
| IAM permissions | Customer, configured within provider tools |
| Guest OS patching in IaaS | Customer |
| Application security in PaaS | Customer still owns application logic |
| SaaS user access and data | Customer manages users, roles, and data use |
| Hypervisor maintenance | Provider in typical public cloud models |
| Network security configuration | Shared depending on service model |
Trap: Moving to cloud does not remove the need for logging, IAM governance, encryption decisions, backups, and incident response planning.
IaaS, PaaS, SaaS
| Model | Customer manages more of… | Provider manages more of… |
|---|---|---|
| IaaS | OS, apps, data, identity config | Physical hardware, virtualization platform |
| PaaS | App code, data, access | Runtime, middleware, infrastructure |
| SaaS | Users, data, configuration | Application and underlying infrastructure |
Containers and serverless
| Area | Review point |
|---|---|
| Container images | Use trusted base images and scan for vulnerabilities |
| Secrets | Do not bake secrets into images or code repositories |
| Runtime | Limit privileges, isolate workloads, monitor behavior |
| Orchestration | Secure cluster API, RBAC, network policies |
| Serverless | Secure permissions, input validation, dependencies, logging |
| CI/CD | Protect pipelines because they can deploy trusted code at scale |
Endpoint, mobile, IoT, and OT security
Endpoint hardening
| Control | Why it matters |
|---|---|
| Secure baseline | Standard hardened configuration |
| Patch management | Reduces known vulnerability exposure |
| EDR/XDR | Detects and responds to endpoint activity |
| Host firewall | Limits inbound/outbound traffic |
| Disk encryption | Protects data if device is lost |
| Secure boot | Helps prevent boot-level tampering |
| Application allowlisting | Blocks unauthorized executables |
| USB/device control | Reduces removable media risk |
| Local admin restriction | Limits privilege abuse |
| Centralized logging | Supports detection and investigation |
Mobile deployment models
| Model | Meaning | Security implication |
|---|---|---|
| BYOD | Bring your own device | Harder privacy/control balance |
| CYOD | Choose your own device | More standardization than BYOD |
| COPE | Company-owned, personally enabled | Organization owns device, some personal use |
| COBO | Company-owned, business-only | Strongest organizational control |
Mobile controls
| Control | Use |
|---|---|
| MDM | Device enrollment, policy, remote wipe |
| MAM | Application-level management |
| Containerization | Separates work and personal data |
| Remote wipe | Removes data from lost/stolen device |
| Geofencing | Location-based policy |
| Screen lock/biometric | Local access protection |
| Certificate-based Wi-Fi/VPN | Stronger device/user authentication |
IoT and OT reminders
| Environment | Security challenge |
|---|---|
| IoT | Weak defaults, limited patching, many devices |
| OT/ICS | Availability and safety may outweigh rapid patching |
| Embedded systems | Long lifecycle, limited resources |
| Medical/industrial devices | Vendor support and maintenance windows matter |
Trap: In OT environments, immediately patching or rebooting may be unsafe. Segmentation, monitoring, compensating controls, and planned maintenance may be better first answers.
Application security and DevSecOps
Secure SDLC essentials
| Phase/activity | Security focus |
|---|---|
| Requirements | Security and privacy requirements |
| Design | Threat modeling, architecture review |
| Development | Secure coding, code review |
| Build | Dependency scanning, secrets detection |
| Test | SAST, DAST, fuzzing, abuse cases |
| Deploy | Secure configuration, IaC scanning |
| Operate | Monitoring, patching, incident response |
| Retire | Data retention and secure disposal |
Testing types
| Test | What it examines |
|---|---|
| SAST | Source/static code without running app |
| DAST | Running application from outside |
| IAST | Runtime analysis with instrumentation |
| Fuzzing | Unexpected/random inputs |
| Dependency scan | Vulnerable third-party libraries |
| Secret scan | Exposed keys, tokens, passwords |
| Manual code review | Logic flaws and context-specific issues |
Trap: SAST may find code-level issues early, but it may miss runtime/configuration issues. DAST can find runtime behavior but usually sees less internal code detail.
Data protection
| Technique | Best use |
|---|---|
| Encryption | Protects confidentiality at rest/in transit |
| Hashing | Verifies integrity; stores password-derived values |
| Tokenization | Replaces sensitive value with token |
| Masking | Hides part of data from users/displays |
| Anonymization | Removes identifying links where feasible |
| Pseudonymization | Replaces identifiers but can potentially be re-linked |
| DLP | Detects/blocks sensitive data movement |
| Classification | Labels data by sensitivity/handling need |
| Retention policy | Defines how long data is kept |
| Secure destruction | Prevents recovery after disposal |
Security operations
Logging and monitoring
| Tool/concept | Function |
|---|---|
| SIEM | Aggregates/correlates logs and alerts |
| SOAR | Automates response workflows |
| EDR | Endpoint detection and response |
| NDR | Network detection and response |
| XDR | Correlates across multiple telemetry sources |
| UEBA | Detects unusual user/entity behavior |
| Syslog | Common log transport format/protocol |
| NetFlow | Network flow metadata |
| Packet capture | Detailed network traffic evidence |
High-yield log clues:
| Clue | Possible meaning |
|---|---|
| Many failed logins across many users | Password spraying |
| One user with many password attempts | Brute force against account |
| Successful login from unusual geography | Account compromise or impossible travel |
| PowerShell spawning network connections | Possible fileless malware or living-off-the-land |
| DNS queries to random domains | DGA malware possibility |
| Repeated 500 errors after special characters in input | Injection testing or exploitation |
| New admin account outside change window | Privilege escalation or unauthorized change |
Incident response sequence
A common practical flow:
flowchart LR
A[Preparation] --> B[Identification]
B --> C[Containment]
C --> D[Eradication]
D --> E[Recovery]
E --> F[Lessons learned]
| Phase | What it means |
|---|---|
| Preparation | Policies, tools, contacts, training, playbooks |
| Identification | Confirm event, determine scope/severity |
| Containment | Limit damage and spread |
| Eradication | Remove root cause, malware, persistence |
| Recovery | Restore normal operations and monitor |
| Lessons learned | Improve controls, documentation, training |
Trap: Do not jump to wiping systems if the question emphasizes evidence preservation or scope identification. In many scenarios, containment and evidence handling come before full remediation.
Evidence and forensics
| Concept | Review point |
|---|---|
| Chain of custody | Tracks who handled evidence, when, and why |
| Legal hold | Preserves relevant data from alteration/deletion |
| Order of volatility | Collect most volatile evidence first when appropriate |
| Imaging | Create forensic copy rather than working on original |
| Hashing evidence | Verifies evidence integrity |
| Time synchronization | Makes event timelines reliable |
| Write blocker | Prevents modification during acquisition |
Common volatility order, from more volatile to less volatile:
- CPU registers/cache
- RAM
- Network connections/processes
- Disk data
- Backups/archives
Governance, risk, and compliance concepts
Policy hierarchy
| Document | Purpose |
|---|---|
| Policy | High-level management intent |
| Standard | Mandatory specific requirement |
| Procedure | Step-by-step instructions |
| Guideline | Recommended practice |
| Baseline | Minimum secure configuration |
| Playbook | Repeatable operational response steps |
| Runbook | Detailed operational procedure |
Trap: If the question asks for a mandatory configuration requirement, “standard” is often better than “guideline.”
Risk management
| Term | Meaning |
|---|---|
| Asset | Something valuable |
| Threat | Potential cause of harm |
| Vulnerability | Weakness that can be exploited |
| Likelihood | Chance of occurrence |
| Impact | Consequence if it occurs |
| Inherent risk | Risk before controls |
| Residual risk | Risk remaining after controls |
| Risk appetite | Amount of risk organization is willing to accept |
| Risk register | Documented list of risks and status |
Risk response options:
| Response | Meaning | Example |
|---|---|---|
| Avoid | Stop the risky activity | Decommission vulnerable public service |
| Mitigate | Reduce likelihood or impact | Patch, segment, monitor |
| Transfer | Shift financial/operational impact | Insurance, outsourcing contract |
| Accept | Acknowledge and live with risk | Formal exception for low risk |
Business impact and continuity
| Item | Purpose |
|---|---|
| BIA | Identifies critical processes and impact of disruption |
| BCP | Keeps business operating during disruption |
| DRP | Restores IT systems after disruption |
| Tabletop exercise | Discussion-based scenario walkthrough |
| Simulation | More realistic scenario practice |
| Failover test | Verifies alternate systems work |
| Backup test | Confirms data can actually be restored |
Trap: A backup that has never been restored is an assumption, not proof of recoverability.
Third-party and supply chain risk
| Control/activity | Why it matters |
|---|---|
| Vendor due diligence | Evaluates security before onboarding |
| Contract requirements | Defines responsibilities and expectations |
| SLA | Service performance/availability commitments |
| Right to audit | Allows verification of controls |
| SOC reports/attestations | Provide independent control reporting context |
| Data processing terms | Clarify handling of sensitive data |
| SBOM | Lists software components and dependencies |
| Vendor offboarding | Removes access and confirms data return/destruction |
Trap: Third-party risk is not eliminated by outsourcing. Accountability for data and access decisions often remains with the organization.
Common “best answer” decision rules
| Scenario wording | Strong answer pattern |
|---|---|
| Lost laptop with sensitive data | Full-disk encryption, remote wipe, MDM, incident process |
| User needs temporary admin rights | PAM, JIT access, approval, logging |
| Legacy system cannot be patched | Segmentation, compensating controls, monitoring |
| Web app hit by injection attempts | Parameterized queries and input validation; WAF may help |
| Need proof data was not altered | Hash or digital signature depending on identity need |
| Need proof who approved/sent it | Digital signature/non-repudiation |
| Prevent lateral movement | Segmentation, least privilege, EDR, restrict admin creds |
| Stop data leaving email/cloud | DLP, classification, access controls |
| Cloud storage exposed publicly | Correct permissions, policy guardrails, monitoring |
| Detect unusual insider behavior | UEBA/SIEM correlation |
| Reduce phishing account takeover | MFA, training, email authentication, conditional access |
| Protect admin access to network devices | TACACS+/RADIUS, MFA, centralized logging |
| Secure machine-to-machine API access | Strong auth, least privilege tokens, rotation, mTLS where appropriate |
| Verify software integrity | Code signing, hashes, trusted repositories |
| Improve repeatable deployment security | IaC scanning, secure templates, CI/CD controls |
Common candidate mistakes
Mistake 1: Choosing the most technical answer automatically
Security+ does not always reward the most advanced tool. If the scenario is about governance, user process, or risk acceptance, a policy, procedure, approval, or risk register entry may be the best answer.
Mistake 2: Confusing detection with prevention
An IDS detects. An IPS can block. A SIEM correlates and alerts. A firewall enforces traffic rules. Read whether the question asks to detect, prevent, respond, or document.
Mistake 3: Ignoring business context
Patching is important, but immediate patching may not be the best answer for a critical OT system, high-availability production service, or system requiring change control.
Mistake 4: Treating encryption as a solution for everything
Encryption protects confidentiality. It does not automatically provide availability, authorization, input validation, or user accountability.
Mistake 5: Missing “first” versus “best long-term”
- First: identify, contain, preserve, notify proper internal roles, follow procedure.
- Best long-term: remediate root cause, improve controls, automate, train, monitor.
Mistake 6: Overlooking least privilege
When two answers both work, the one that grants less access, narrows scope, or reduces blast radius is often better.
Performance-based question review tactics
For interactive or scenario-style questions:
- Read the task before the exhibits. Know what you are building, matching, or selecting.
- Identify constraints. Look for “least privilege,” “most secure,” “minimum downtime,” or “cost-effective.”
- Place controls by layer. Network controls do not fix insecure code; IAM controls do not replace patching.
- Use elimination. Remove insecure protocols, overly broad permissions, and answers that solve the wrong problem.
- Check for completeness. A partially secure design may miss logging, redundancy, or access control.
- Do not overconfigure. If the question asks for one best action, avoid adding assumptions not in the scenario.
Fast final review checklist
Before starting topic drills or a mock exam, confirm you can explain:
- Difference between authentication, authorization, and accounting
- MFA factor types and common identity protocols
- Symmetric encryption, asymmetric encryption, hashing, and digital signatures
- PKI certificate validation and revocation basics
- Common social engineering, malware, password, and web attacks
- Vulnerability management workflow and prioritization
- Firewalls, WAF, IDS, IPS, proxies, NAC, VPN, and ZTNA
- Secure protocol replacements for insecure services
- Zero Trust principles and segmentation
- Cloud shared responsibility across IaaS, PaaS, and SaaS
- Endpoint, mobile, IoT, and OT security constraints
- Secure SDLC, SAST/DAST, dependency scanning, and secrets management
- SIEM/SOAR/EDR monitoring and incident response phases
- Chain of custody and evidence integrity
- RTO, RPO, BIA, BCP, and DRP
- Risk responses: avoid, mitigate, transfer, accept
- Policy, standard, procedure, guideline, and baseline differences
- Third-party and supply chain risk controls
Practice focus recommendations
Use this Quick Review to choose your next practice set:
| If you struggled with… | Practice next |
|---|---|
| Definitions blend together | Short topic drills with detailed explanations |
| Scenario questions feel close | Mixed-domain question bank sets |
| Timing is a problem | Mock exams with review afterward |
| You miss “first step” questions | Incident response and governance drills |
| You miss architecture questions | Network, cloud, and Zero Trust scenarios |
| You miss attack identification | Threat, log, and vulnerability questions |
| You miss control selection | Preventive/detective/corrective and risk drills |
A practical next step: start with a focused set of original practice questions on your weakest SY0-701 topic, read every detailed explanation, then take a mixed question bank quiz to confirm you can apply the concept outside its original context.
Continue in IT Mastery
Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official CompTIA questions, copied live-exam content, or exam dumps.