Domain 3 · Objective reference 3.5 · Chapter 23 of 62
Assess weaknesses across architecture types
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Architecture changes attack paths and responsibility.
Explore the anchors
Consider remote dependencies and trust.
Concept matching activity
Match this task or description to its concept:
Consider shared hosts and isolation.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
- Compare architecture-specific exposure
Concepts and mechanisms
Client, server, database, distributed, cloud, virtualized and embedded systems expose different boundaries. Containers share important host dependencies; serverless functions still depend on identities, configuration, code and provider services. Microservices add API, service-discovery and cross-service authorization decisions. Edge and IoT systems may have physical access or support constraints. Industrial systems can couple technical failure to physical consequences.
Design, evidence and tradeoffs
Model the actual deployment and shared responsibilities. Evaluate isolation, identity, state, management, update trust, data and recovery paths. A distributed deployment is not necessarily independent if it shares an identity provider or administrator. For AI workloads, include model and data provenance, sensitive interfaces, resource demands and human fallback. Verify control assumptions under material failure conditions rather than using the architecture label as assurance.
Compare architecture-specific exposure
An industrial control system may prioritize safe deterministic operation and carefully staged changes; a web API needs object-level authorization and input handling. Containers share a host kernel while virtual machines typically separate guest kernels through a hypervisor. Serverless reduces infrastructure administration but leaves code, identity, secrets and data responsibilities. IoT and embedded devices add physical access and update constraints; edge deployments add distributed custody and intermittent links. High-performance and distributed systems add shared scheduling, interconnect and consistency concerns. Examine client, server, database, cloud and cryptographic components in their real deployment paths.
Worked example
Two regional applications share one identity dependency; a loss-of-identity exercise challenges the claimed independent recovery capability.
Check your understanding
Why does a serverless service still require a security architecture review?
Show explanation
Customer code, permissions, data, integrations and operational dependencies remain even where the provider manages servers.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.