SecurityX · Domain 2 of 4

SecurityX Domain 2: Security Architecture

Domain 2 tests whether you can design an enterprise that stays secure and available by default: where components sit, how identity decides access, how cloud services are governed and how Zero Trust replaces the perimeter.

Exam weight
27%
Official objectives
6
Estimated questions estimate
~24
Suggested study time estimate
45–60 hrs

About 19 min read Reviewed October 2026

Overview

Security Architecture is 27% of the CAS-005 exam and covers six objectives: designing resilient systems, building security into the systems life cycle, integrating controls into a secure architecture, designing access, authentication and authorization systems, implementing cloud capabilities securely, and integrating Zero Trust concepts. The questions are design questions: given requirements and constraints, choose where a component goes, which pattern meets the goal and what the trade-off costs.

The domain sits between risk and implementation. It takes the threats and obligations from Governance, Risk, and Compliance and turns them into placement decisions, identity flows, data classification schemes and cloud guardrails. Security Engineering then configures and troubleshoots what is designed here, and Security Operations depends on the logging, sensor placement and continuous monitoring this domain builds in from the start.

How it's tested

Expect architecture scenarios with requirements such as uptime targets, regulatory boundaries, remote users, third-party integrations or legacy components, followed by BEST design choice questions. Performance-based items may ask you to place components in a diagram or map controls to zones. The deciding detail is usually a single requirement such as real-time blocking, statelessness or device trust.

  • Component placement

    A network or application diagram is described and you decide where a WAF, reverse proxy, API gateway, tap or collector belongs to meet the stated goal.

  • Pattern versus requirement

    Several valid designs are offered and the right one is the only option that satisfies a specific requirement, such as stateless scaling, data residency or continuous authorization.

  • Life cycle placement

    A development or procurement scenario asks which assurance activity, such as SCA, an SBoM, branch protection or canary testing, belongs at that stage.

Reasoning it through

A retailer's web tier must scale out during sales without users losing their carts. Options include larger servers, sticky sessions on the load balancer, storing session state in a shared cache, and a CDN. Vertical scaling hits a ceiling and sticky sessions break when a node is removed. Making web nodes non-persistent and moving session state to a shared store allows horizontal scaling while preserving carts, so that design is BEST.

Objectives 6

Official objectives from the CompTIA outline, in outline order.

2.1 Given a scenario, analyze requirements to design resilient systems.Component placement and configuration, and availability and integrity design choices.
What it means
This objective covers placing and configuring firewalls, IPS, IDS, vulnerability scanners, VPNs, NAC, WAFs, proxies, reverse proxies, API gateways, taps, collectors and CDNs, and availability and integrity design: load balancing, recoverability, interoperability, geographical considerations, vertical versus horizontal scaling, and persistence versus non-persistence.
What to understand
Placement follows purpose: a WAF or reverse proxy sits in front of the application it protects, an IPS sits inline where it can drop traffic, while an IDS, tap or collector observes a copy. Horizontal scaling adds nodes and needs stateless or externally stored state, while vertical scaling adds resources to one node and keeps a single point of failure. Non-persistent instances rebuilt from a known-good image limit attacker persistence and configuration drift.
How it shows up
A diagram or requirement list asks where to place a component or which scaling and recovery approach meets a stated uptime or integrity goal.
Common confusion
Mixing up forward proxies, which mediate outbound user traffic, with reverse proxies, which front inbound requests to servers.
2.2 Given a scenario, implement security in the early stages of the systems life cycle and throughout subsequent stages.Security requirements, software assurance, CI/CD controls, supply chain, hardware assurance and end of life.
What it means
This objective covers defining functional and non-functional security requirements and the security versus usability trade-off; software assurance through SAST, DAST, IAST, RASP, vulnerability analysis, SCA, SBoM and formal methods; CI/CD controls including coding standards and linting, branch protection, continuous improvement and testing activities (canary, regression, integration, automated test and retest, unit); software and hardware supply chain risk management; hardware certification and validation; and end-of-life considerations.
What to understand
Security requirements are cheapest to meet when written before design, as non-functional requirements alongside performance and availability. An SBoM lists every component and version so a newly disclosed library vulnerability can be traced to affected products in minutes. Branch protection enforces review and passing checks before merge, formal methods mathematically prove properties of high-assurance code, and canary releases expose a change to a small population before full rollout.
How it shows up
A scenario names a life cycle stage or a supply chain event and asks which assurance activity or pipeline control best addresses it.
Common confusion
Treating RASP as a testing tool; it is a runtime protection that instruments the running application to detect and block attacks.
2.3 Given a scenario, integrate appropriate controls in the design of a secure architecture.Attack surface reduction, detection enablement, data classification and DLP, hybrid and third-party designs, control effectiveness.
What it means
This objective covers attack surface management and reduction (vulnerability management, hardening, defense-in-depth, legacy components within an architecture); detection and threat-enabling capabilities (centralized logging, continuous monitoring, alerting, sensor placement); information and data security design (classification models, data labeling, tagging strategies); DLP at rest, in transit and through data discovery; hybrid infrastructures; third-party integrations; and control effectiveness measured by assessments, scanning and metrics.
What to understand
Detection must be designed in: if logs are not centralized and sensors do not see east-west traffic, operations cannot find lateral movement later. Classification and labeling make DLP enforceable, because a DLP rule can act reliably on a label or tag but only guess at unlabeled content. Legacy components that cannot be hardened are isolated and wrapped with compensating controls, and control effectiveness is shown with metrics rather than assumed from deployment.
How it shows up
A design review reveals a blind spot, unlabeled sensitive data or an unhardenable legacy system, and you choose the control that closes it.
Common confusion
Assuming deploying a control proves it works; the outline separates control effectiveness, which needs assessment, scanning and metrics.
2.4 Given a scenario, apply security concepts to the design of access, authentication, and authorization systems.Provisioning, federation, SSO, conditional access, PDP and PEP, access control models, logging and PKI architecture.
What it means
This objective covers provisioning and deprovisioning (credential issuance, self-provisioning); federation, SSO, conditional access, identity providers, service providers and attestations; policy decision and enforcement points; role-based, rule-based, attribute-based, mandatory and discretionary access control; logging and auditing; PKI architecture including certificate extensions, certificate types, OCSP stapling, CA/RA roles, templates and deployment approach; and physical and logical access control systems.
What to understand
In federation the identity provider authenticates the user and issues an assertion that the service provider trusts, so the service provider never sees the password. A policy decision point evaluates the request against policy and context, while a policy enforcement point sits in the traffic path and carries out that decision. ABAC evaluates attributes of subject, object, action and environment, which is how conditions like time, location and device posture are expressed.
How it shows up
A scenario lists access requirements, such as contractors from a partner company or access that depends on device health and data label, and asks which model, flow or PKI feature fits.
Common confusion
Calling rule-based access control and role-based access control the same thing; rule-based applies global rules such as time windows or firewall-style conditions regardless of role.
2.5 Given a scenario, securely implement cloud capabilities in an enterprise environment.CASB, shadow IT, shared responsibility, IaC, containers, serverless, API security, key ownership and cloud data risks.
What it means
This objective covers API-based and proxy-based CASB; shadow IT detection; the shared responsibility model; CI/CD pipelines with Terraform and Ansible; package monitoring; container security and orchestration; serverless workloads, functions and resources; API security through authorization, logging and rate limiting; cloud-managed versus customer-managed encryption keys and licenses; cloud data risks such as exposure, leakage, remanence and insecure storage resources; proactive, detective and preventative control strategies; and customer-to-cloud connectivity, service integration and adoption.
What to understand
Shared responsibility shifts with the service model: the customer always owns data, identities and configuration, while the provider takes more of the stack moving from IaaS to PaaS to SaaS. Customer-managed keys give control over rotation and revocation, which can satisfy sovereignty or crypto-shredding needs. Infrastructure as code lets guardrails run as policy checks before deployment, which is a preventative strategy, while posture scanning of running resources is detective.
How it shows up
A cloud adoption scenario describes a data exposure, a compliance need or unsanctioned SaaS use and asks for the most effective cloud control or ownership decision.
Common confusion
Assuming the provider is responsible for a publicly readable storage bucket, when access configuration is always the customer's responsibility.
2.6 Given a scenario, integrate Zero Trust concepts into system architecture design.Continuous authorization, reauthentication, segmentation, attestation, security boundaries, deperimeterization and subject-object relationships.
What it means
This objective covers continuous authorization and context-based reauthentication; network architecture choices including segmentation, microsegmentation, VPN and always-on VPN; API integration and validation; asset identification, management and attestation; security boundaries such as data perimeters, secure zones and system components; deperimeterization through SASE, SD-WAN and software-defined networking; and defining subject-object relationships.
What to understand
Zero Trust removes implicit trust based on network location: every request is evaluated on identity, device attestation and context, and the decision can be revisited during the session. Microsegmentation enforces policy per workload so a compromised host cannot reach peers by default. SASE converges SD-WAN with cloud-delivered security services such as secure web gateway, CASB and Zero Trust network access, which suits a distributed workforce better than backhauling traffic to a data center.
How it shows up
A scenario describes flat networks, VPN-based remote access or lateral movement and asks which Zero Trust element addresses the stated weakness.
Common confusion
Treating an always-on VPN as Zero Trust; it still grants network-level access once connected unless access is decided per resource and continuously.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Reverse proxy vs. forward proxy

    A forward proxy mediates outbound requests from internal users to the internet, while a reverse proxy receives inbound requests on behalf of servers and forwards them internally.

    Remember
    Protecting, load balancing or terminating TLS for your own published applications is a reverse proxy job.
    Tested as
    Placement questions hinge on the direction of traffic the requirement describes.
    Trap
    Choosing a forward proxy to hide or protect internal web servers from external clients.

  • Horizontal vs. vertical scaling

    Horizontal scaling adds more instances behind a load balancer, while vertical scaling adds CPU, memory or storage to an existing instance.

    Remember
    Horizontal scaling improves availability as well as capacity but requires stateless nodes or shared state storage.
    Tested as
    Resilience scenarios with variable load or no-single-point-of-failure requirements favor horizontal designs.
    Trap
    Choosing a bigger server for a requirement that also demands tolerance of a node failure.

  • Software bill of materials (SBoM)

    An SBoM is a machine-readable inventory of the components, libraries and versions inside a piece of software.

    Remember
    Its value is speed of impact analysis when a new component vulnerability is disclosed, and it supports supply chain transparency with suppliers.
    Tested as
    Supply chain questions ask what lets an organization quickly determine whether it uses an affected library.
    Trap
    Thinking an SBoM detects vulnerabilities by itself; it must be matched against vulnerability data, which is what SCA tooling does.

  • RASP

    Runtime application self-protection instruments the running application so it can detect and block attacks using knowledge of its own execution context.

    Remember
    RASP protects in production from inside the app, while a WAF inspects traffic from outside it.
    Tested as
    Questions about protecting an application that cannot be fixed quickly, with low false positives, can point to RASP.
    Trap
    Listing RASP as a pre-release testing method alongside SAST and DAST.

  • Policy decision point and policy enforcement point

    The PDP evaluates an access request against policy and context and returns allow or deny, while the PEP sits in the request path and enforces that answer.

    Remember
    Zero Trust architectures centralize decisions in the PDP and distribute enforcement through PEPs near resources.
    Tested as
    Access design and Zero Trust questions ask which component makes versus carries out a decision.
    Trap
    Placing policy logic in each enforcement point, which fragments policy and makes consistent decisions impossible.

  • ABAC

    Attribute-based access control decides access by evaluating attributes of the subject, object, action and environment against policy.

    Remember
    Requirements that combine department, data classification, device posture, location and time are expressed most naturally in ABAC.
    Tested as
    Scenarios with role explosion or context-dependent access expect ABAC.
    Trap
    Creating more roles to express conditions, which leads to unmanageable role explosion.

  • OCSP stapling

    With OCSP stapling the server periodically fetches a signed OCSP response for its own certificate and includes it in the TLS handshake.

    Remember
    It removes the client's separate call to the CA's responder, improving privacy and performance and reducing dependence on responder availability.
    Tested as
    PKI architecture questions about slow handshakes, responder load or client privacy point to stapling.
    Trap
    Choosing a larger CRL distribution schedule, which increases client download size and staleness.

  • API-based vs. proxy-based CASB

    An API-based CASB connects to the SaaS provider's API to scan stored data and configurations, while a proxy-based CASB sits inline in the traffic path.

    Remember
    Only inline proxy mode can block an action in real time; API mode sees data at rest, including uploads from unmanaged devices, after the fact.
    Tested as
    Cloud scenarios ask which mode meets real-time blocking or retrospective discovery requirements.
    Trap
    Expecting an API-based CASB to stop an upload as it happens.

  • Customer-managed keys

    With customer-managed keys the organization controls key creation, rotation, access policy and revocation in a key management service or HSM rather than leaving them entirely to the provider.

    Remember
    Revoking or destroying the key renders the encrypted data unreadable, which supports sovereignty requirements and crypto-shredding at exit.
    Tested as
    Regulated cloud adoption scenarios often hinge on who controls the keys.
    Trap
    Assuming provider-managed encryption at rest gives the customer the ability to revoke the provider's access.

  • Data remanence in cloud

    Data remanence is residual data left on storage after deletion, which in multitenant cloud cannot be physically wiped by the customer.

    Remember
    Encrypt with customer-controlled keys and destroy the keys at decommissioning, because physical destruction is not available to the tenant.
    Tested as
    Exit and decommissioning scenarios test how to make cloud data unrecoverable.
    Trap
    Requesting physical drive destruction from a public cloud provider as the primary sanitization method.

  • Microsegmentation

    Microsegmentation applies access policy at the level of individual workloads or applications, often through host or hypervisor enforcement.

    Remember
    It limits east-west movement inside a data center or cloud even when hosts share a network segment.
    Tested as
    Lateral movement scenarios inside a flat environment point to microsegmentation.
    Trap
    Choosing VLANs alone, which separate broad groups but still allow free movement within each VLAN.

  • SASE

    Secure access service edge combines SD-WAN networking with cloud-delivered security services such as secure web gateway, CASB, firewall as a service and Zero Trust network access.

    Remember
    It applies consistent policy near users wherever they are, instead of backhauling traffic to a central data center.
    Tested as
    Distributed workforce and branch office scenarios with latency complaints and inconsistent policy favor SASE.
    Trap
    Treating SD-WAN alone as SASE, when SD-WAN provides routing and path selection without the security services.

  • Continuous authorization and context-based reauthentication

    Access is reevaluated throughout a session as risk signals change, and the user is prompted to reauthenticate when context such as location, device health or behavior shifts.

    Remember
    A single login at session start is not sufficient in Zero Trust; decisions can be revoked mid-session.
    Tested as
    Session hijacking and token theft scenarios ask which Zero Trust element would cut off access.
    Trap
    Relying on shorter password expiry, which does nothing to a session already established.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

RBAC vs. rule-based vs. ABAC vs. MAC vs. DAC

ConceptMeaningKey differenceCommon trap
Role-based (RBAC) Permissions are attached to roles that users are assigned Access follows job function Expanding roles to encode context, causing role explosion
Rule-based Global rules apply to all subjects, such as time windows or source network Rules apply regardless of who the user is Confusing it with role-based because both abbreviate to RBAC
Attribute-based (ABAC) Policy evaluates subject, object, action and environment attributes Fine-grained and context-aware decisions Underestimating the attribute quality and governance it requires
Mandatory (MAC) System-enforced labels and clearances decide access Owners cannot override the labels Choosing it for commercial collaboration needs that require owner discretion
Discretionary (DAC) Resource owners grant access at their discretion Flexible but prone to permission sprawl Selecting it where regulation demands centrally enforced access

API-based CASB vs. proxy-based CASB

ConceptMeaningKey differenceCommon trap
API-based CASB Connects to sanctioned SaaS through provider APIs Scans data at rest and configurations, including content uploaded from unmanaged devices, without being in the traffic path Expecting it to block an action in real time
Forward proxy CASB Inline proxy configured on managed endpoints or networks Real-time control and shadow IT visibility for managed devices Assuming it covers personal devices that bypass the proxy
Reverse proxy CASB Inline proxy in front of a sanctioned SaaS application, often reached through SSO redirection Real-time control for unmanaged devices on that sanctioned app without endpoint configuration Expecting it to discover unsanctioned SaaS use

CRL vs. OCSP vs. OCSP stapling

ConceptMeaningKey differenceCommon trap
CRL CA-published list of revoked certificate serial numbers Clients download the whole list; status is only as fresh as the publication interval Ignoring staleness between publications
OCSP Client queries the CA responder for one certificate's status Near real-time, but adds latency and reveals browsing to the responder Overlooking the dependency on responder availability
OCSP stapling Server attaches a recent signed OCSP response in the TLS handshake Removes the client's separate lookup while keeping a signed status Assuming the stapled response is created by the server rather than signed by the CA responder

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Vertical scaling for an availability requirement

    What candidates pick
    Upgrading the single application server to a larger instance size.
    Why it looks right
    It solves the capacity complaint quickly and needs no application change.
    Why it's wrong
    A larger single node still fails as a unit; the requirement to survive node loss needs horizontal scaling with stateless or shared-state nodes behind a load balancer.

    Clue to watch for The scenario mentions uptime targets, maintenance without downtime, or tolerance of an instance failure.

  2. Real-time blocking from an API CASB

    What candidates pick
    Deploying an API-based CASB to stop users uploading regulated data to a SaaS app as it happens.
    Why it looks right
    API CASBs integrate easily and cover unmanaged devices.
    Why it's wrong
    API mode works out of band after data lands; only inline proxy modes can intercept and block the upload in real time.

    Clue to watch for Words such as 'prevent', 'block at the time of upload' or 'in real time'.

  3. VPN equals Zero Trust

    What candidates pick
    Mandating an always-on VPN for all remote staff to achieve Zero Trust.
    Why it looks right
    Always-on VPN removes unprotected connections and is listed in the objective.
    Why it's wrong
    A VPN still places the user on the network with broad reachability after a single authentication; Zero Trust requires per-resource decisions based on identity, device attestation and context, revisited continuously.

    Clue to watch for The scenario complains about lateral movement or broad access after users connect remotely.

  4. Provider owns the misconfiguration

    What candidates pick
    Opening a ticket asking the cloud provider to fix a publicly readable storage bucket.
    Why it looks right
    The bucket runs on provider infrastructure, so it feels like their responsibility.
    Why it's wrong
    Under the shared responsibility model, access policies, identities and data protection settings remain the customer's job in every service model.

    Clue to watch for The problem involves permissions, configuration or data rather than physical or hypervisor issues.

  5. More roles for context

    What candidates pick
    Creating new roles such as 'Finance-Remote-ManagedDevice' to express conditional access.
    Why it looks right
    RBAC is familiar and already deployed.
    Why it's wrong
    Encoding context into roles causes role explosion; conditions like device posture, location and data label belong in ABAC or conditional access policies evaluated at request time.

    Clue to watch for Requirements combine job function with time, location, device health or data classification.

  6. Testing tools in production protection questions

    What candidates pick
    Running DAST weekly to protect a vulnerable production app whose fix is months away.
    Why it looks right
    DAST finds runtime vulnerabilities in a running application.
    Why it's wrong
    DAST discovers flaws but does not stop exploitation; protecting the app until the fix ships calls for a runtime control such as RASP or a WAF virtual patch.

    Clue to watch for The scenario says the flaw is already known and the need is protection until remediation.

Answer framework

For Domain 2 design questions, anchor every choice to the single requirement that eliminates the other options.

  1. Extract the hard requirements first, such as uptime targets, real-time enforcement, data residency, unmanaged devices or legacy constraints, because one of them usually eliminates most options.
  2. Trace the traffic or data flow and identify trust boundaries, because placement and enforcement points follow the path.
  3. Assign responsibility using the shared responsibility model and decide who must control encryption keys, identities and configuration in each service.
  4. Prefer designs that decide access per request on identity, device and context, and that limit blast radius through segmentation.
  5. Check the trade-off: reject options that break a stated business, usability or performance need, and confirm the design produces logs operations can use.

Practice question

A company must find and remediate regulated files already stored in its sanctioned cloud file-sharing service, including files employees uploaded from personal devices that cannot be configured with agents or proxy settings. Which solution BEST meets this requirement?

Want more like this? The SecurityX practice test has questions for every domain.

Checklist

0 of 14

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Begin with 2.1 and 2.4 because placement and identity flows appear inside almost every other architecture scenario. Draw a reference diagram with internet edge, DMZ, application tier, data tier and cloud, and practice placing each component from the outline with a one-line reason. For identity, walk through a federated login step by step until you can say which party authenticates, which issues the assertion and where the PDP and PEP sit.

Next study 2.5 and 2.6 together, since cloud adoption and Zero Trust share the same ideas of identity-centric access, segmentation and shared responsibility. Pay particular attention to the CASB deployment modes and to key ownership, which candidates commonly underestimate.

Finish with 2.2 and 2.3, linking each assurance activity to a life cycle stage and each data control to the classification that drives it. Afterwards, practice performance-based placement items and BEST-design questions, and for every miss write down the single requirement that should have eliminated your choice.

FAQ

How much of SecurityX is Security Architecture?

Security Architecture is 27% of the CAS-005 exam and contains six objectives. Per-domain question counts are not published, so the estimate on this page is for planning only.

What kind of questions does Domain 2 use?

Mostly design scenarios that ask for the BEST component, placement or pattern given stated requirements, plus performance-based items where you may place controls in a diagram or map them to zones.

Do I need hands-on cloud experience for this domain?

It helps, because objective 2.5 covers CASB modes, infrastructure as code, containers, serverless, API security and key ownership. Focus on which control solves which problem rather than on one provider's console.

How deep does Zero Trust go on SecurityX?

Objective 2.6 expects you to design with continuous authorization, context-based reauthentication, microsegmentation, device attestation, data perimeters, SASE and subject-object relationships, and to recognize designs that only look like Zero Trust.

What is the difference between Security Architecture and Security Engineering on this exam?

Architecture decides what the design should be and where controls belong. Engineering configures, hardens and troubleshoots those components, such as fixing an IAM federation failure or a TLS cipher mismatch.

Which access control model is tested most?

All five listed models are fair game. Scenarios most often require you to recognize when context-dependent requirements call for ABAC instead of adding roles, and when centrally enforced labels call for MAC.

How should I study the SDLC objective if I am not a developer?

Learn what each assurance activity finds and when it runs, such as SCA and SBoM for third-party components, SAST before build, DAST and IAST against a running app, and RASP in production.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 2 knowledge

You have covered resilient design, life cycle assurance, architecture controls, access design, cloud capabilities and Zero Trust. Practice choosing the design that satisfies every stated requirement under exam timing.

Take the SecurityX practice test Check your SecurityX readiness

Keep going