How to Master One of the Hardest Parts of the CompTIA SecurityX Exam: Security Architecture

Security Architecture is where SecurityX stops feeling like a certification exam and starts feeling like a design review. Instead of asking what a WAF is, questions ask where it belongs, what it can’t protect, and whether a different control would meet the requirement better.

Candidates find this domain hard for a few specific reasons. It covers a huge range (network design, secure development, identity, PKI, cloud, and Zero Trust). Several correct-sounding answers often appear together, and the best one depends on a business constraint buried in the question. And many candidates are experts in one layer but have never designed another.

We’ll walk you through the domain, core concepts, common traps, and a focused study plan.

What Does Security Architecture Cover on the SecurityX Exam?

Domain 2.0, Security Architecture, makes up 27% of the CAS-005 exam, or roughly 24 of up to 90 questions. It’s the second-largest domain after Security Engineering (31%). The CompTIA SecurityX (CAS-005) Exam Objectives divide it into six objectives:

  • 2.1: Analyze requirements to design resilient systems.
  • 2.2: Implement security throughout the systems life cycle.
  • 2.3: Integrate appropriate controls in secure architecture design.
  • 2.4: Apply security concepts to access, authentication, and authorization systems.
  • 2.5: Securely implement cloud capabilities in an enterprise environment.
  • 2.6: Integrate Zero Trust concepts into system architecture.

What Core Concepts Should You Master?

Resilient Design and Component Placement (2.1)

Know what each security component does and where it belongs. A WAF sits in front of web applications and inspects HTTP traffic for attacks like SQL injection and XSS. An IPS sits inline and can block, while an IDS usually receives copied traffic from a tap or SPAN port and can only alert. An API gateway centralizes authentication, rate limiting, and logging for APIs.

For availability, understand load balancing, vertical scaling (a bigger server) versus horizontal scaling (more servers), and persistent versus non-persistent systems. Non-persistent designs, such as instances rebuilt from a golden image, make recovery fast and limit how long an attacker can stay.

Security Throughout the Life Cycle (2.2)

This objective tests whether you can match the right assurance tool to the stage of development:

  • SAST: Analyzes source code without running it. Catches flaws early but can produce false positives.
  • DAST: Tests the running application from the outside, as an attacker would. It needs no source code access.
  • IAST: Uses agents inside the running application during testing to combine code-level and runtime insight.
  • RASP: Runs inside the application in production and can block attacks in real time.
  • SCA and SBOM: Software composition analysis finds vulnerable third-party libraries, and a software bill of materials inventories them.

Also know CI/CD controls such as branch protection and required code review, and testing types like unit, integration, regression, and canary deployments.

Integrating Controls (2.3)

Expect questions about defense in depth, attack surface reduction, data classification and labeling, and DLP for data at rest, in transit, and during discovery. Sensor placement matters too. A sensor that can’t see east-west traffic between internal servers won’t catch lateral movement.

Access, Authentication, and Authorization (2.4)

Be comfortable with these distinctions:

  • Federation vs. SSO: SSO lets a user sign in once across systems. Federation extends trust across organizations or domains, with an identity provider (IdP) asserting identity to a service provider (SP), often using SAML or OpenID Connect.
  • Access control models: RBAC grants access by job role, ABAC evaluates attributes like department, device, and location, MAC uses labels and clearances set by the system, and DAC lets owners decide.
  • Policy decision point (PDP) and policy enforcement point (PEP): The PDP decides whether to grant access, and the PEP enforces that decision.
  • PKI architecture: Know the roles of the CA and RA, certificate types and extensions, and OCSP stapling, where the server attaches a signed revocation status so clients don’t have to query the CA themselves.

Cloud Capabilities (2.5)

The shared responsibility model is the foundation. The customer always owns its data and access decisions, while the provider takes on more of the stack as you move from IaaS to PaaS to SaaS. Also know:

  • CASB modes: Proxy-based CASBs sit inline and can enforce policy in real time. API-based CASBs connect directly to sanctioned cloud services to scan stored data and settings, but they don’t sit in the traffic path.
  • Infrastructure as Code: Tools like Terraform and Ansible make configurations repeatable and reviewable, which reduces drift.
  • Key management: Provider-managed keys are simpler, while customer-managed keys give you more control over access and revocation.
  • Containers and serverless: Image scanning, orchestration security, and least-privilege function permissions.

Zero Trust (2.6)

Zero Trust assumes no user, device, or network location is trusted by default. Every request is evaluated using identity, device posture, and context. The objectives highlight continuous authorization, context-based reauthentication, microsegmentation, asset attestation, defining subject-object relationships, and deperimeterization through SASE and SD-WAN.

Common Security Architecture Traps

  • Mixing up SAST and DAST. If the question says there’s no source code access, SAST is out. If the goal is to catch flaws before the code runs, DAST is too late.
  • Treating a VPN as Zero Trust. An always-on VPN still grants broad network access once connected. Zero Trust grants access per resource and keeps checking.
  • Picking the wrong CASB mode. Scanning data already stored in a sanctioned SaaS app points to API mode. Blocking an upload as it happens points to proxy mode.
  • Assuming the provider handles everything in SaaS. Account permissions, data classification, and user access remain your responsibility.
  • Choosing the strongest control instead of the right one. SecurityX often states a business constraint, such as low latency, a legacy system that can’t be patched, or a limited budget. The best answer meets the requirement within that constraint.
  • Confusing IDS and IPS placement. An out-of-band sensor can’t block traffic, no matter how good its rules are.

How to Reason Through a Security Architecture Question

Consider a question where a company moves its HR application to a SaaS provider. Security wants to find sensitive employee files that are already stored in the service and shared publicly, without adding latency for users. The options include a proxy-based CASB, an API-based CASB, a WAF, and an always-on VPN.

Start with what the question is really asking: discover data at rest in a sanctioned SaaS app, with no performance impact. A WAF protects web applications you host, not a provider’s storage. An always-on VPN secures the connection but doesn’t see what’s stored in the service. A proxy-based CASB sits inline and could add latency, and it only sees traffic as it passes. The API-based CASB connects directly to the service to scan existing files and sharing settings, so it’s the best answer.

Now consider a scenario where a hospital has a legacy imaging system that can’t be patched or run an agent, and an attacker who compromised a workstation could reach it. The choices include installing EDR on the device, moving it to a microsegmented zone that allows only the required imaging traffic, replacing it immediately, and adding MFA to the workstation.

The constraint rules out EDR, since no agent can run on the device. Immediate replacement may be the long-term goal, but it doesn’t meet a near-term need. MFA on the workstation doesn’t stop an attacker who already has access. Microsegmentation limits who can reach the system and is the best compensating control.

How Security Architecture Connects to the Other Domains

  • Security Engineering (3.0): Architecture decides that you’ll use federation or Zero Trust. Engineering asks you to troubleshoot the SAML assertion or conditional access policy that breaks.
  • Security Operations (4.0): Logging and sensor placement decisions from 2.3 determine what your SIEM can detect later.
  • Governance, Risk, and Compliance (1.0): Data classification, privacy laws, and data sovereignty shape where cloud workloads can live and which controls are required.

A Focused Study Plan for Security Architecture

  1. Draw it. Sketch a hybrid network with a DMZ, cloud VPC, and remote users, then place every component from objective 2.1. Explain why each goes where it does.
  2. Build comparison notes. Make quick-reference notes for SAST/DAST/IAST/RASP, the access control models, CASB modes, and cloud service models.
  3. Practice by objective. In Pocket Prep, use Build Your Own Quiz on Security Architecture until you consistently explain why each wrong answer is wrong.
  4. Review your misses. Use the Missed Questions quiz every few days, and note which objective each miss belongs to.
  5. Mix it back in. Once your scores stabilize, switch to Timed Quiz and mixed sets, so you learn to recognize architecture questions when they aren’t labeled.

Start Preparing for the CompTIA SecurityX Exam With Pocket Prep

Security Architecture gets easier once you’ve worked through enough scenarios to spot the constraint that decides the answer. Pocket Prep’s CompTIA SecurityX practice questions offer 1,430 questions across all four domains, each with a detailed explanation, plus a full-length mock exam. Target this domain with Build Your Own Quiz, then let the Weakest Subject quiz show you what to tackle next. You’ve got this!