Designing Resilient Systems for CompTIA SecurityX (CAS-005): Component Placement and Scaling Strategies

CompTIA SecurityX (CAS-005) objective 2.1 asks candidates to "analyze requirements to design resilient systems" — and it's one of the most heavily weighted objectives on an exam where Security Architecture already accounts for 27% of the total score. Unlike Security+, which tests whether you can identify what a firewall, WAF, or load balancer does, SecurityX tests whether you can decide where each control belongs in a complex enterprise topology, how it should scale, and what happens when a node fails. This guide walks through the component placement decisions, scaling models, and persistence strategies that CAS-005 expects architects to reason through on exam day.

Why "Where" Matters as Much as "What"

A junior-level exam asks you to define a reverse proxy. A SecurityX-level question gives you a data flow diagram and asks whether the reverse proxy should sit in front of the API gateway or behind it, and what breaks if you get the order wrong. That shift — from definitions to design trade-offs — is the core of the Security Architecture domain, and it's why CAS-005 objective 2.1 explicitly calls out component placement and configuration as a testable skill, not just a vocabulary list.

Placement decisions matter because every security control also introduces a point of failure, a potential bottleneck, or a new trust boundary. An architect who can recite the function of an IPS but can't explain why it needs to sit inline (rather than out-of-band, like a tap) hasn't actually internalized the resilience implications CAS-005 is testing for.

Component Placement: Where Each Control Belongs

CAS-005 objective 2.1 lists a specific set of components you need to be able to place correctly inside a resilient architecture: firewalls, IPS/IDS, vulnerability scanners, VPN concentrators, NAC, WAFs, forward and reverse proxies, API gateways, network taps, flow collectors, and CDNs. A few placement principles come up again and again on practice scenarios:

• Inline vs. passive. Controls that need to block traffic in real time (firewalls, IPS, WAFs) must sit inline, directly in the traffic path. Controls that only need to observe traffic for detection or analytics — taps and flow collectors — sit passively off a SPAN port or a network tap so they add zero latency and can't become a single point of failure for availability.
• Edge vs. core. A CDN and reverse proxy belong at the network edge, absorbing traffic and attacks before they ever reach internal infrastructure. A NAC solution, by contrast, belongs at the access layer — the switch port or wireless controller where a device first requests entry to the network — because its job is admission control, not traffic inspection.
• API gateways as a chokepoint. In microservices and cloud-native architectures, the API gateway is often the single place where authentication, rate limiting, and schema validation can be enforced consistently. CAS-005 scenarios frequently test whether you'd rely on each individual service to enforce its own security controls (fragile, inconsistent) versus centralizing them at the gateway (resilient, auditable).
• Vulnerability scanners sit out of the production data path. Unlike an IPS, a scanner's job is periodic assessment, not real-time defense, so it's typically deployed with scoped, scheduled access rather than permanent inline presence — minimizing the chance that a scanning engine itself becomes an availability or stability risk.

Scaling for Availability and Integrity

Once components are placed correctly, CAS-005 shifts to a second question: how does the architecture behave under load, and under failure? Objective 2.1 specifically calls out load balancing, recoverability, interoperability, and vertical vs. horizontal scaling as testable concepts.

Load balancing is the mechanism that makes horizontal scaling possible — it's what lets an architecture add more servers rather than bigger ones. The distinction the exam wants you to internalize:

• Vertical scaling (scaling up) adds CPU, memory, or storage to an existing node. It's simpler to manage but has a hard ceiling, and it creates a single point of failure — if that one bigger server goes down, there's no graceful degradation.
• Horizontal scaling (scaling out) adds more nodes behind a load balancer. It's more complex to orchestrate (you need session state handling, health checks, and consistent configuration across nodes) but it's what enables true resilience: traffic reroutes around a failed node automatically, and capacity grows without a hard ceiling.

Recoverability and interoperability round this out. Recoverability asks whether a failed component can resume state cleanly — does the architecture need hot standby nodes, or can it tolerate a cold restart? Interoperability asks whether the resilience mechanisms you've chosen (say, a specific load balancer's health-check protocol) will actually work across the mixed vendor environment most real enterprises run, including hybrid on-prem/cloud deployments.

Persistence vs. Non-Persistence

This is a distinction that trips up a lot of exam candidates because it sounds like a data-retention question when it's really an architecture-resilience question. In the context of CAS-005 objective 2.1:

• Persistent systems maintain state between sessions or between requests — a traditional VM, a database server, a stateful firewall session table. They're easier to reason about for troubleshooting, but a compromise or corruption can persist indefinitely, and recovery means restoring from a known-good state.
• Non-persistent systems are rebuilt from a known-good image or template on every session, reboot, or request — think golden-image VDI desktops, ephemeral containers, or serverless functions that tear down after execution. Any compromise is wiped out the moment the instance is destroyed, which is a powerful resilience and security property, but it requires externalizing state (to a database, object store, or session cache) since nothing survives locally.

CAS-005 scenarios often ask you to choose between the two for a given workload. The general rule the exam rewards: high-risk, high-exposure, or frequently-attacked components (public-facing web tiers, jump boxes, kiosk endpoints) are strong candidates for non-persistent design, while stateful backend systems that need durable, auditable history remain persistent by necessity.

Geographic Considerations

Resilient design doesn't stop at the data center door. CAS-005 also expects you to weigh geographic considerations: regulatory data residency requirements, latency to end users, and — critically — whether redundant components are distributed across availability zones, regions, or physical sites so that a single disaster (power outage, natural event, regional cloud outage) doesn't take out every redundant node at once. A load-balanced pair of servers in the same rack provides no protection against a rack-level failure; true resilience requires thinking about the blast radius of every single point of shared infrastructure, right down to the power circuit and the ISP uplink.

Exam Tips for CAS-005 Objective 2.1

• When a scenario describes a component "inspecting and blocking" traffic, it belongs inline. When it's "monitoring and logging," it belongs on a tap or passive collection point.
• If a question emphasizes elasticity or unpredictable demand, the expected answer is horizontal scaling with load balancing — not a bigger server.
• Watch for scenarios describing frequently-compromised, public-facing systems — these are hints toward a non-persistent (golden-image or ephemeral) design recommendation.
• Don't confuse recoverability (can the system resume state after failure) with the separate availability/disaster-recovery testing concepts covered under CAS-005 domain 1.0 governance and risk — 2.1 is about architecture decisions made at design time, not the BCDR plan itself.
• Geographic redundancy questions on CAS-005 almost always hinge on identifying a shared point of failure (a single region, a single power feed) that redundancy on paper didn't actually eliminate.

Key Takeaways

• CAS-005 objective 2.1 tests placement decisions (inline vs. passive, edge vs. core) for firewalls, IPS/IDS, WAFs, proxies, API gateways, taps, flow collectors, and CDNs — not just their definitions.
• Horizontal scaling with load balancing is the resilient default for unpredictable or growing demand; vertical scaling is simpler but creates a ceiling and a single point of failure.
• Non-persistent (ephemeral/golden-image) designs are favored for high-exposure, frequently-attacked components because compromise doesn't survive a rebuild.
• Recoverability and interoperability both matter for resilience — a design that can't recover state cleanly, or can't integrate with mixed-vendor failover protocols, isn't actually resilient under real conditions.
• Geographic distribution of redundant components is what turns theoretical redundancy into real resilience — redundant nodes sharing one rack, one region, or one power feed aren't truly redundant at all.