Designing Security Into Every Computing Model

Architecture is the moment security stops being a checklist and becomes structure: once you've decided how components talk to each other, where trust boundaries sit, and which computing model you're building on, you've already determined most of what a later code review or penetration test can fix. This sub-objective is about reasoning consistently about security architecture across the very different computing models a real architect touches -- distributed systems, cloud, mobile, embedded, IoT, and increasingly AI-driven systems.

Distributed and Service-Oriented Systems

Most modern applications are not one program but a constellation of services -- a web tier, an API layer, background workers, message queues, and third-party integrations. Each hop between services is a place an attacker can sit, and each service must re-check authorization rather than inherit trust from its neighbor. Traditional perimeter thinking -- trust everything inside the network -- breaks down here. The modern answer is zero trust: every service-to-service call is authenticated and authorized regardless of network location, typically through mutual TLS, signed service tokens, or a service mesh. API gateways centralize authentication, rate limiting, and input validation so that logic isn't duplicated inconsistently across dozens of services.

Cloud and Virtualized Computing

Cloud architecture forces an explicit conversation about the shared responsibility model: the provider secures the physical infrastructure and, at higher service tiers, more of the stack above it -- but the customer never stops owning data classification and access configuration. Multi-tenancy introduces isolation risk between virtual machines or containers sharing physical hardware; a hypervisor or container escape turns "someone else's problem" into yours. Orchestration platforms add their own architectural surface -- secrets stored in cluster configuration, overly broad service accounts, and default-open network policies are design-time mistakes, not coding bugs.

Mobile, Embedded, IoT, and Cognitive Computing

Mobile architectures rely on OS-level app sandboxing and must design around a device the organization doesn't fully control. Embedded and IoT systems sit at the opposite extreme: constrained processors and memory push teams toward lightweight cryptography, and many devices ship for years without a practical update path, so secure-by-default provisioning matters more than any later patch strategy. AI and cognitive computing systems raise newer architectural questions -- where training data originates, how model inputs and outputs are validated, and how much autonomous decision authority the system is architected to hold.

Key Mechanics

• The shared responsibility model shifts as you move from IaaS to PaaS to SaaS -- the customer never loses data and access-configuration responsibility, only infrastructure responsibility.
• Zero trust architecture authenticates and authorizes every service call rather than trusting anything inside a network perimeter.
• Trust boundaries mark where data crosses into a different privilege or ownership context -- controls belong there.
• Constrained embedded/IoT hardware forces lightweight-cryptography tradeoffs and demands secure-by-default provisioning, since patching later is unreliable.
• Architectural decisions are the most expensive to change once implementation starts, making this the highest-leverage point to get security right.

Exam Tip: The exam loves the false comfort of "it's SaaS, so the vendor handles security." Know exactly what shifts with each cloud service model -- the customer always keeps data and access-configuration responsibility, even in SaaS.

Exam Tip: Don't confuse container isolation with VM isolation -- containers share a kernel, so a container escape is a meaningfully weaker boundary than a hypervisor escape, and the exam tests whether you know the difference.

Exam Tip: Watch for scenarios implying IoT or embedded devices are "too small" to need architected security -- the correct answer usually points to secure provisioning and lightweight crypto design, not "security doesn't apply here."

Diagram

Worked example: A retailer migrating a monolithic order system to microservices on a public cloud IaaS platform must decide, at the architecture stage, which team owns OS patching (the retailer, under IaaS), how services authenticate to each other (mutual TLS behind an API gateway rather than implicit network trust), and how a compromised recommendation-engine container is prevented from reaching the payment service's database -- all decided before a single security test is ever run.