CySA+ CS0-003: Find the Gaps in Security Architecture

A company adds endpoint detection to every laptop, a firewall at each branch, and a cloud security service for its public applications. During an incident, investigators discover that the affected service account can read production secrets, that a backup environment trusts the same identity, and that no log links the cloud session to the endpoint user. The organization owns plenty of controls. Its architecture still permits a minor compromise to become a major one. The security-architecture angle in CySA+ CS0-003 begins with this distinction between having tools and designing defensible trust boundaries.

“Security architecture” is not a separate named CS0-003 weighted domain. Architectural reasoning appears throughout its Security Operations, Vulnerability Management, and Incident Response objectives. This matters when planning study: the exam expects an analyst to understand infrastructure and control behavior well enough to investigate threats and recommend remediation, not merely to draw an idealized network diagram. The successor CS0-004 uses a revised blueprint, so the exact domain allocation must be checked against the exam version you are taking.

Map where trust is granted, not just where devices sit

Traditional diagrams emphasize routers, switches, subnets, and servers. A security investigation also needs identity providers, application roles, API dependencies, data stores, privileged management routes, and outbound service connections. A network zone labeled “trusted” might contain contractors, automation accounts, and production workloads with very different risk. Ask which principals can request access, what authenticates them, what authorizes the action, and whether the permission survives longer than the business task. Trust boundaries exist within an application as well as between networks.

Consider an HR service that sends approved employee information to a payroll vendor. The decisive questions are not only whether TLS protects the connection but which records the integration can retrieve, whether its token can be reused elsewhere, and how revocation works when the vendor relationship ends. Document the data flow from original source to final processing destination. A security analyst should be able to point to every step that changes identity, privilege, custody, or visibility. Omitting those transitions makes later log analysis and containment unnecessarily speculative.

Separate network segmentation from complete isolation

VLANs and subnets organize traffic, but their presence alone does not enforce security boundaries. Routing policy, stateful inspection, endpoint controls, service identities, and workload-specific restrictions determine whether one segment can reach another. A segmented design can fail when a shared jump host has broad access, a management network is reused for application traffic, or an emergency exception remains permanently open. Review permitted paths using real source-and-destination pairs rather than relying on diagram colors or broad claims about “secure zones.”

A demilitarized zone can reduce exposure for public services if inward connections are narrowly defined and logged. It does not automatically protect a database reached through a permissive backend rule. A practical account of DMZ design clarifies the role of the boundary without treating the DMZ as a magic shield. For each allowed path, ask who needs it, which protocol and port are required, how it is authenticated, and which telemetry would reveal unexpected use. Architecture becomes meaningful when a reader can verify that paths reflect business need.

Design for compromised credentials, not perfect users

An architecture that assumes credentials will never be stolen is brittle. Enforce minimum workable privilege, short-lived credentials where appropriate, controlled administrative access, and effective separation of duties. Service accounts deserve the same attention as human accounts; long-lived secrets embedded in build pipelines or application configuration can create lateral access that is difficult to investigate. Consider how a compromised ordinary account might reach sensitive workloads, and which independent controls would prevent escalation.

Role-based access control gives teams a vocabulary for permission design, but meaningful least privilege requires testing real effective rights. A role name such as “reader” may still expose regulated data, and permissions inherited through groups or application grants can be less obvious than direct assignments. Inspect privileged paths and resource-level authorization together. When responding to an account compromise, know how to revoke sessions and tokens as well as change a password; otherwise the apparent containment action may not affect the access mechanism that caused the problem.

Place monitoring where investigators can actually observe activity

Network logs alone may show a connection but not the document opened inside an encrypted application session. Endpoint logs may expose process behavior while missing cloud-side downloads. Identity logs show authentication outcomes but not every subsequent action. Strong architecture provides complementary observation points, common timestamps, stable resource identifiers, and retention appropriate to investigation needs. It also acknowledges blind spots: some managed services reveal only limited activity, and traffic decryption can create new privacy and operational concerns.

When an alert fires, analysts should know which system of record can confirm the event. For a suspect cloud storage download, a complete path may require identity sign-in records, resource audit activity, endpoint client context, and external sharing state. For a server command execution alert, process telemetry and deployment history may be more relevant than internet packet captures. Detection design must align to the assets and threat paths the architecture actually contains. A generic rule deployed everywhere can generate impressive volumes of noise while important transitions remain unobserved.

Account for dependencies that could amplify a failure

Availability is part of security architecture. An identity provider outage can block administration; a shared DNS dependency can disable many supposedly independent services; a central logging service can become both a single point of failure and a high-value target. Map the dependency chain for critical operations and decide how security controls behave during partial outages. A “fail-open” choice may preserve service while widening exposure, whereas “fail-closed” may prevent unauthorized access but interrupt essential work. Neither setting should be applied without understanding the business consequence.

Backups illustrate this trade-off. If production credentials can delete the backup copies, ransomware or account misuse can compromise both recovery and the original data. Separate backup administration, protect immutable or appropriately isolated restore points, and test recoverability. Redundancy is not the same as recoverability: a replicated corrupted dataset can preserve the problem in multiple locations. Verify that the organization can restore a specific protected service after losing the dependencies on which normal administration relies.

Make cloud and hybrid boundaries explicit

Cloud deployments often combine customer-managed identities, vendor-managed infrastructure, virtual networks, storage policies, and external APIs. The provider’s responsibility for physical infrastructure does not eliminate the customer’s responsibility for resource permissions, secret handling, data classification, and configuration. Hybrid connections further complicate exposure because on-premises identities may receive cloud rights and public cloud workloads may reach internal applications. Map both the network tunnel and the authorization relationship: a private route can carry an excessively privileged request.

Where software-defined infrastructure changes rapidly, treat configuration as reviewable evidence. Version-controlled infrastructure definitions, change logs, policy checks, and short-lived deployments make it easier to establish what was exposed during a specific incident window. A cloud security posture tool can spot broad permissions, but its findings must be tied to runtime identity and actual data access before declaring impact. Architecture assessment asks not merely whether a policy violates a benchmark but how that deviation contributes to a credible threat path.

Use incidents to test whether controls compose correctly

Suppose endpoint protection detects an unauthorized remote-access utility on a developer laptop. The laptop can reach a source repository, and the developer account can trigger a deployment pipeline whose automation identity reads production secrets. The architecture review should follow each step: was device health checked before repository access, were code changes approved, did the pipeline separate build privileges from runtime secrets, and could responders disable the chain without stopping unrelated services? The weakness may not be a missing antivirus product. It may be the interaction between individually reasonable permissions.

This type of case helps distinguish detective and preventive controls. An intrusion detection system can alert on suspicious behavior without necessarily blocking it; prevention mechanisms can stop some actions but also cause disruption if tuned poorly. Build a table of which control prevents a step, which detects it, and which supports investigation afterward. Do not count several tools as independent defenses if they all rely on the same vulnerable identity or the same event stream.

Practice architecture review as a defensive analyst

Draw an approved fictional environment with users, an identity provider, two application tiers, a database, a cloud storage account, backups, and a logging service. Add a single weak permission—such as an ordinary service account allowed to administer backup storage—and ask what could go wrong after an account compromise. Identify a preventive control, one monitoring event, and a recovery mechanism, then list what remains uncertain. Repeat the exercise after changing the assumption that network routing is private: does the risk actually disappear, or can an authorized but compromised identity still cross the boundary?

Use CompTIA Security+ concepts for the foundational control vocabulary and apply CySA+’s analyst lens to operational evidence. Study architecture by asking how you would prove the configuration, verify enforcement, and recognize bypass, rather than only memorizing product names. A strong design has visible ownership, constrained trust, meaningful monitoring, and tested recovery. A strong CS0-003 answer explains why a particular weakness matters within that design and which practical change would reduce the demonstrated attack path.

The best architecture reviews end with fewer assumptions, not a longer list of devices to purchase. They show where an initial foothold might gain power, where evidence would appear, who can close the exposure, and what must continue functioning during a response. Those details turn a network diagram into an operational security model that analysts can actually use.