Security+ PBQ Lab: Firmware Integrity and Storage Recovery

Domain 1: General Security Concepts — 12%

General Security Concepts gives you the vocabulary and core principles used throughout the rest of the exam.

You’ll need to understand confidentiality, integrity, availability, non-repudiation, authentication, authorization, control types, zero trust, change management, physical safeguards, and basic cryptographic concepts. Don’t memorize security terms without knowing what problem each one solves. Hashing supports integrity, encryption protects confidentiality, and digital signatures can support integrity, authentication, and non-repudiation. The exam often presents several controls that sound secure, but only one delivers the specific property being requested. Focus on the asset, the threat, and the intended outcome before choosing a mechanism.

Domain 2: Threats, Vulnerabilities, and Mitigations — 22%

This domain focuses on how attacks happen, what weaknesses they exploit, and which controls reduce the resulting risk.

You’ll need to understand threat actors, motivations, attack surfaces, social engineering, malware, application vulnerabilities, cloud weaknesses, network attacks, and common indicators of compromise. Study symptoms such as unusual processes, impossible travel, unexpected resource usage, changed files, credential abuse, and suspicious outbound traffic. Don’t settle for vague answers like “improve security.” Match the mitigation directly to the weakness by patching the vulnerable system, restricting access, isolating the host, rotating credentials, hardening the configuration, or blocking the attack path. The exam rewards precise relationships between threat, vulnerability, evidence, and response.

Domain 3: Security Architecture — 18%

Security Architecture is about designing systems that meet security requirements without ignoring availability, performance, ownership, or recovery needs.

You’ll need to compare on-premises, cloud, hybrid, virtualized, embedded, and industrial environments. Study segmentation, resilience, secure design, backups, data classification, encryption, shared responsibility, and recovery models. Pay close attention to who manages each layer in a cloud service, including identities, applications, operating systems, platforms, networks, and facilities. The best answer usually maps directly to the stated requirement, such as isolating workloads, protecting data at rest, surviving a site failure, or reducing implicit trust. Don’t choose the most advanced design if it doesn’t fit the actual business constraint.

Domain 4: Security Operations — 28%

Security Operations is the largest domain and covers the day-to-day work required to detect, contain, investigate, and recover from security events.

You’ll need to understand hardening, asset management, vulnerability management, monitoring, identity administration, automation, incident response, forensics, and data protection. A tool only creates value when alerts, ownership, prioritization, and remediation workflows are clear. Thousands of scanner findings aren’t useful if nobody knows which ones matter first. Study how analysts combine endpoint, network, identity, application, and cloud telemetry to build context. Follow the incident lifecycle from preparation and detection through containment, eradication, recovery, and lessons learned. Preserve evidence while restoring service, and verify that the original attack path has been closed.

Domain 5: Security Program Management and Oversight — 20%

Security Program Management and Oversight turns technical controls into a governed, measurable business program.

You’ll need to understand policies, standards, procedures, guidelines, risk management, third-party oversight, compliance, audits, privacy, awareness, business continuity, and security metrics. Know the difference between accepting, mitigating, avoiding, and transferring risk. Don’t assume a signed policy, completed questionnaire, or vendor contract proves that controls are effective. Strong oversight creates traceability from a requirement to the implemented control, supporting evidence, exceptions, ownership, and review dates. The goal is to reduce ambiguity while giving technical teams enough structure to build, operate, and improve systems without unnecessary administrative friction.