CAS-005 Security architecture

Security architecture Detailed Explanation

CAS-005 security architecture questions focus on how controls behave inside real enterprise designs. The exam expects you to reason about traffic paths, cloud and SaaS boundaries, federation trust, software release pipelines, policy enforcement points, and resilience evidence. A good architecture answer places the control where it can actually inspect, decide, or prove state, rather than naming a familiar product that sits outside the operational path.

Resilient System Component Placement and Control Effectiveness

Exam Radar

Official Objective Mapping: Security architecture; related CAS-005 objective areas: resilient architecture, network and application control placement, cloud capabilities, availability, monitoring, segmentation, load balancing, and recovery considerations.

Plain-English Understanding: This topic tests whether you can place the right control in the traffic path and prove it works. A firewall, WAF, IDS, load balancer, proxy, or logging pipeline is useful only if the relevant packets, requests, health signals, and events actually reach it.

Key Concepts: control placement; request path; inline vs passive inspection; health probe; failover; centralized logging; time synchronization.

Exam Focus: traffic path, application-layer inspection, health checks, sensor visibility, and evidence correlation.

• Core Priority: Follow the actual request or packet path before choosing a control.
• High Frequency: SecurityX often asks why a good control failed because it was deployed outside the relevant path.
• Confusion Alert: A network firewall cannot parse every application-layer attack, and an IDS cannot detect traffic it never receives.
• Scenario Logic: Draw the path from client to CDN, proxy, WAF, load balancer, application tier, data tier, and log collector.
• Version Delta: Hybrid and cloud architectures make placement harder because traffic may enter through multiple listeners, regions, or API paths.
• Failure Trigger: Misplaced controls create clean logs while attacks or outages continue elsewhere.
• Operational Dependency: Health probes, routing rules, policy associations, sensor interfaces, and log ingestion must all match the production path.
• How the Exam Asks It: The stem may say one layer looks healthy while users still see attacks, failures, or missing timelines.
• How Distractors Are Designed: Wrong answers add capacity, rename controls, or inspect an unrelated subnet instead of fixing placement.
• Why the Correct Answer Works: It restores inspection, availability, or evidence at the point where the system actually makes the decision.

Practice Question: A WAF is enabled, but SQL injection attempts still reach the backend. Traffic enters through a CDN and a separate API endpoint bypasses the WAF listener. What should be corrected?

A. Increase server CPU capacity B. Route all relevant application traffic through the WAF or API security enforcement point before backend access C. Disable application logging D. Add an IDS sensor on an unrelated management subnet

Correct Answer: B

Explanation: B is correct because the WAF cannot protect traffic that bypasses its listener. The fix is to place enforcement in every relevant application path. CPU capacity does not inspect requests, disabling logs removes evidence, and an unrelated sensor will not see the bypassed API flow.

Practice Question: After a node failure, users keep reaching the failed server. Which evidence best identifies the architectural issue?

A. A list of installed desktop antivirus agents B. A password policy report C. Load-balancer backend pool health-probe status and active member list D. A code-signing certificate inventory

Correct Answer: C

Explanation: C is correct because the symptom is failed traffic distribution. Backend health-probe status and active pool membership show whether the load balancer still considers the node eligible. The other evidence sources belong to endpoint, identity, or software integrity, not failover behavior.

Exam Takeaway: If a control appears enabled but attacks or failures continue, trace the production path and fix the point where traffic, health checks, or logs bypass enforcement.

Atomic Deconstruction - Operational Level

What this topic really tests: can you trace a request or packet through the architecture and place controls where they can enforce or observe? A WAF belongs in the HTTP request path; an IPS must be inline for prevention; an IDS must receive mirrored or routed traffic for detection; a load balancer needs valid health probes; logs need time sync and parser support. The exam punishes answers that name a good tool but put it in the wrong place.

Beginner-friendly grounding: A security control only works on traffic or events it can actually see. Before choosing WAF, IDS, IPS, load balancer, or logging changes, trace the request path and find where inspection or failover really occurs.

Exam transformation: wrong options usually appear as using a network firewall for application-layer attacks; placing a sensor where it cannot see traffic; fixing availability without checking health probes; replacing application logs with perimeter logs. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
WAF policy	Application-layer inspection point	Inline, reverse proxy, CDN-integrated	Not deployed	Application traffic path	Layer 7 attacks bypass network-only controls
IDS/IPS sensor	Visibility and enforcement mode	Out-of-band IDS, inline IPS	Misplaced or blind	Tap, span, route, or inline segment	False negatives rise because traffic never reaches the sensor
Load balancer	Availability distribution	Active-active, active-passive, geo-aware	Single endpoint	Health probes and persistence design	A failed node remains in rotation or session state breaks during failover
Central logging collector	Detection evidence path	Endpoint, network, application, cloud	Partial ingestion	Time sync and retention	Incident analysis lacks complete event sequence

Step-by-Step Execution Path

1. Trace the real traffic path from client, CDN, WAF or reverse proxy, load balancer, application tier, and data tier. Placement decisions must follow packet and request flow.
2. Identify which threats are blocked at which layer: network ACLs for path control, WAF for HTTP semantics, IDS/IPS for signature or anomaly inspection, and logging for evidence.
3. Validate load-balancer health probes, persistence requirements, and failover behavior before tuning security rules. Availability controls fail if unhealthy nodes remain eligible.
4. Confirm centralized logging with time synchronization, source identity, parser status, and retention. Detection requires comparable event timestamps across layers.
5. Run a controlled test through the approved test environment: blocked web attack, failed node health probe, and log-correlation review. The expected outcome is blocked malicious request, removed failed node, and correlated event chain.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts with a client request, routing decision, proxy or WAF handling, load-balancer selection, backend processing, and logging. Each component either changes traffic flow, inspects content, measures health, or records evidence. If the control is bypassed, the backend receives uninspected traffic. If health checks are wrong, failed nodes stay active. If logs are incomplete, incident reconstruction breaks. The correct answer restores the flow that makes the control effective.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Verify application inspection path	WAF or reverse-proxy console: listener > policy association > backend route	Application traffic passes through the WAF policy before reaching backend servers
Check sensor visibility	IDS/IPS console: sensor health > interface traffic > rule hit counters	Sensor receives expected segment traffic and rule counters move during authorized test events
Validate load-balancer failover	Load balancer console: backend pool > health probe status > active members	Unhealthy nodes are removed and healthy nodes remain eligible
Review event correlation	SIEM query: application, WAF, load balancer, and host events by request ID or timestamp window	Events show a complete path without parser failures or missing critical sources

Secure Lifecycle, CI/CD, and Supply Chain Architecture

Exam Radar

Official Objective Mapping: Security architecture; related CAS-005 objective areas: secure software development lifecycle, CI/CD pipeline controls, container security, software supply chain controls, SBoM, SCA, branch protection, signing, and deployment governance.

Plain-English Understanding: This topic tests whether you can identify which lifecycle control catches which type of failure. Source-code scanning, dependency scanning, artifact signing, branch protection, SBoM, container scanning, and deployment gates solve different parts of the release chain.

Key Concepts: SAST; DAST; IAST; RASP; SCA; SBoM; artifact signing; branch protection; container image provenance.

Exam Focus: match the failing release stage to the correct assurance control: source, dependency, artifact, container image, branch, or deployment gate.

• Core Priority: Locate where the weakness enters the lifecycle before selecting a scanner or gate.
• High Frequency: Questions distinguish custom-code defects from dependency exposure, unsigned artifacts, direct pushes, and untrusted container layers.
• Confusion Alert: SAST does not prove third-party package provenance, and RASP does not replace pre-release supply-chain checks.
• Scenario Logic: Read the release chain as code change, branch review, build, dependency resolution, artifact creation, SBoM, signature, repository, and deployment.
• Version Delta: CAS-005 emphasizes supply-chain assurance, SBoM, container security, and CI/CD governance more directly than older security exams.
• Failure Trigger: A release can pass unit tests while still failing dependency, provenance, branch, or artifact-integrity requirements.
• Operational Dependency: Required checks, protected branches, SCA status, artifact signatures, and SBoM metadata must be enforced before release.
• How the Exam Asks It: The stem often says a release passed one control but failed later because the wrong stage was inspected.
• How Distractors Are Designed: Wrong answers apply a valid tool to the wrong phase or rely on manual review where enforced status checks are needed.
• Why the Correct Answer Works: It adds assurance exactly where the release chain lost trust.

Practice Question: A container image deployed to production contains an outdated base image and an unsigned application layer. Which control combination best addresses the release weakness?

A. More comments in the source code B. A network firewall rule for developer workstations C. Container image scanning, SBoM generation, artifact signing, and enforced CI/CD status checks D. Disabling the issue tracker

Correct Answer: C

Explanation: C is correct because the failure is in the release artifact and container supply chain. Image scanning finds vulnerable layers, the SBoM records components, signing proves artifact integrity, and CI/CD checks enforce the gate. Comments, firewall rules, and issue tracker changes do not prove release trust.

Practice Question: Developers can push directly to the production branch during emergencies. Which risk is most direct?

A. DNSSEC validation will fail automatically B. Kerberos tickets will expire faster C. SIEM retention will increase D. Required reviews, security scans, and provenance checks can be bypassed

Correct Answer: D

Explanation: D is correct because unprotected production branches let changes skip the controls that create release assurance. DNSSEC, Kerberos, and SIEM retention are real technologies, but they do not describe the branch-governance failure in the stem.

Exam Takeaway: Match the failed release stage to the control that proves it: SAST for source patterns, SCA/SBoM for dependencies, signing for artifacts, and branch protection for change governance.

Atomic Deconstruction - Operational Level

What this topic really tests: can you locate the weak link in the build-to-release chain? SAST looks at custom code, SCA and SBoM expose dependencies, DAST and IAST inspect behavior during testing, signing proves artifact integrity, branch protection controls change authorization, and container scanning validates image layers. A mature answer connects the tool to the exact failure mode rather than saying 'scan more'.

Beginner-friendly grounding: A release pipeline is a chain of trust. Code review, SAST, SCA, SBoM, signing, image scanning, and branch protection each guard a different link, so the right answer depends on where trust was lost.

Exam transformation: wrong options usually appear as using SAST to prove dependency provenance; using runtime protection as the only build control; allowing direct pushes to release branches; keeping an SBoM outside the artifact lifecycle. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Security requirement	Functional or non-functional constraint	Mandatory, conditional, compensating	Late-stage request	Design review and backlog traceability	Testing finds issues too late for architecture correction
SCA result	Dependency risk signal	Known CVE, license issue, abandoned package	Not scanned	Build pipeline and SBoM	Vulnerable third-party code ships because source code scanning missed it
SBoM artifact	Component inventory	Package name, version, hash, supplier	Absent or stale	Software supply chain process	Incident response cannot identify affected builds after a dependency disclosure
Branch protection rule	Merge control	Required review, signed commit, status checks	Direct push allowed	CI/CD governance	Unreviewed changes bypass testing and provenance controls

Step-by-Step Execution Path

1. Classify each requirement as functional, non-functional, or security-specific and attach it to design and test evidence. This prevents security from appearing only as a release gate.
2. Map assurance tools to failure modes: SAST for source patterns, DAST for running application behavior, IAST for instrumented testing, RASP for runtime protection, and SCA for dependencies.
3. Require SBoM generation and artifact signing in the pipeline where builds are produced. Provenance must attach to the artifact, not a separate spreadsheet.
4. Validate branch protection, required reviews, status checks, and emergency exception workflow. CI/CD controls are bypassed when direct pushes or unprotected release branches exist.
5. Review release evidence for test status, dependency findings, artifact hash, SBoM location, and approver identity. The expected state is reproducible release evidence.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain begins with a requirement and code change, then moves through branch control, build pipeline, security tests, dependency resolution, artifact creation, SBoM generation, signature, repository storage, and deployment approval. If direct pushes are allowed, governance is bypassed. If SCA is missing, vulnerable dependencies survive source review. If signing is absent, artifact integrity cannot be proven. The correct answer restores assurance at the stage where the failure enters.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Inspect pipeline assurance gates	CI/CD console: pipeline > security stages > required status checks	SAST, SCA, test, and artifact stages must pass before release approval
Validate SBoM availability	Artifact repository: release artifact > SBoM attachment or metadata	SBoM lists package names, versions, hashes, and supplier details for the released build
Check branch protection	Repository settings: branch protection > required reviews > required checks	Release branches block direct pushes and require security-relevant status checks
Review dependency exposure	SCA tool: project > critical vulnerabilities > affected versions	Critical findings are blocked, remediated, or formally excepted before deployment

Access Architecture, Cloud Capabilities, and Zero Trust Boundaries

Exam Radar

Official Objective Mapping: Security architecture; related CAS-005 objective areas: access architecture, cloud security capabilities, federation, PKI, CASB, conditional access, microsegmentation, Zero Trust, policy decision and enforcement points.

Plain-English Understanding: This topic tests whether you can design access around subject, object, context, and policy enforcement instead of trusting a network location. SSO is only the start; the scenario often asks whether device state, risk, SaaS exposure, cloud boundary, and workload identity are validated continuously.

Key Concepts: federation trust; claims and audience; conditional access; CASB; microsegmentation; policy decision point; policy enforcement point; cloud shared responsibility.

Exam Focus: separate authentication from authorization, then validate context, SaaS control, workload identity, and enforcement logs.

• Core Priority: Zero Trust decisions require subject, object, context, policy, and enforcement evidence.
• High Frequency: Stems often say SSO works while sensitive data is still exposed or workloads can still move laterally.
• Confusion Alert: VPN origin, internal IP address, or successful login is not sufficient proof of least privilege.
• Scenario Logic: Identify the subject, target object, token claims, device state, session risk, SaaS policy, and enforcement point.
• Version Delta: CAS-005 expects cloud and SaaS controls such as conditional access, CASB visibility, segmentation, and shared-responsibility awareness.
• Failure Trigger: Access architecture fails when authentication is treated as a complete authorization decision.
• Operational Dependency: Policy decisions need identity signals, device compliance, resource sensitivity, and logs showing why access was allowed or blocked.
• How the Exam Asks It: The question may ask how to reduce lateral movement or stop unmanaged-device SaaS downloads after SSO is already deployed.
• How Distractors Are Designed: Wrong answers keep perimeter trust, use shared accounts, or expose certificates in the name of convenience.
• Why the Correct Answer Works: It moves trust from location to continuous subject-object validation.

Practice Question: Users authenticate through SSO, but unmanaged devices can download sensitive SaaS files. Which design evidence matters most?

A. Conditional access result, device compliance signal, CASB policy, and SaaS session control logs B. The number of VPN concentrators C. A shared administrator account for the SaaS tenant D. A public folder containing federation certificates

Correct Answer: A

Explanation: A is correct because the problem is not login; it is contextual authorization and SaaS data control. Conditional access, device compliance, CASB policy, and session logs show whether unmanaged devices are restricted. VPN capacity, shared accounts, and exposed certificates do not solve the access decision.

Practice Question: A workload in one cloud segment can call an internal API it does not need. What Zero Trust control is most relevant?

A. Broader network trust for the cloud VPC B. Microsegmented subject-object policy with workload identity and enforcement logs C. Disabling API authentication because traffic is internal D. Moving the API documentation to a private wiki

Correct Answer: B

Explanation: B is correct because the issue is unnecessary workload-to-API access. Microsegmentation tied to workload identity limits the subject-object path and provides enforcement evidence. Broad VPC trust and disabled authentication preserve the weakness, while documentation location is not an access control.

Exam Takeaway: Do not treat VPN origin or SSO success as authorization; verify subject, object, device state, risk, data sensitivity, and enforcement logs.

Atomic Deconstruction - Operational Level

What this topic really tests: can you separate authentication, authorization, context, and enforcement? Federation proves who the subject is; claims and token audience tell the application what was asserted; conditional access adds risk and device context; CASB sees SaaS behavior; microsegmentation controls workload-to-object communication. The exam distractor is often a perimeter answer that ignores continuous validation.

Beginner-friendly grounding: Zero Trust does not mean users log in more often; it means every subject-object request is checked with identity, device, risk, data sensitivity, and enforcement evidence. Successful SSO is only one signal.

Exam transformation: wrong options usually appear as trusting VPN origin as proof of authorization; using shared local accounts; ignoring device compliance; treating SSO as a complete Zero Trust design. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Federation trust	Identity provider to service provider relationship	SAML, OIDC, OAuth-based	Local identity silo	Certificate, metadata, claims, and audience	Users authenticate but receive wrong claims or invalid token audience
Conditional access policy	Context decision logic	Device, location, risk, time, configuration	Allow all	Signal quality and enforcement point	Access is granted without meeting device or risk requirements
CASB integration	Cloud application control mode	API-based, proxy-based, hybrid	No discovery	SaaS logs and identity integration	Shadow IT or data exposure remains invisible
Zero Trust segment	Subject-object boundary	User, device, workload, data object	Network location trust	Policy decision and enforcement points	A trusted network zone allows lateral access without continuous validation

Step-by-Step Execution Path

1. Identify identity provider, service provider, token protocol, certificate trust, claim mapping, and audience values. Federation failures often come from metadata or claim mismatch.
2. Define conditional access using strong signals: user risk, device compliance, geolocation, time, session risk, and application sensitivity. Weak signals create false confidence.
3. Select CASB mode based on need: API mode for at-rest SaaS inspection and proxy mode for inline session control. The mode must match the data exposure path.
4. Model Zero Trust subject-object relationships for users, devices, workloads, APIs, and data stores. Network location should not be the authorization proof.
5. Validate policy decisions at the enforcement point using sign-in logs, denied-session evidence, CASB alerts, and segmentation tests. Expected evidence shows why access was granted or denied.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts when a user, device, or workload requests access. The identity provider authenticates the subject, issues claims or tokens, policy engines evaluate context, and enforcement points allow, block, restrict, or log the session. In cloud and SaaS environments, shared responsibility means the provider supplies capability while the customer configures identity, policy, logging, and data controls. The correct answer proves access at the enforcement point, not merely at login.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate token and claim behavior	Identity provider logs: sign-in event > token claims > audience and application	Claims, issuer, audience, and certificate trust match the service provider requirements
Inspect conditional access decision	Identity portal: sign-in logs > conditional access tab > policy result	Sensitive app access requires compliant device or approved compensating control
Review CASB discovery	CASB console: discovered apps > risk score > sanctioned status	Unsanctioned SaaS and sensitive data movement are visible and policy-addressed
Check microsegmentation policy	Segmentation console: subject group > object rule > enforcement logs	Only approved subject-object flows are allowed, and denied lateral attempts are logged