Zero Trust, Cloud, and Secure Enterprise Architecture

Domain 3 on SY0-701—Security Architecture—tests whether you can reason about where trust starts, where it ends, and what happens when an adversary crosses a boundary you drew. Roughly 18% of the exam sits here. Vendor acronyms matter less than patterns: identity-centric access, explicit trust boundaries, the cloud shared responsibility model, microsegmentation, and resilience baked into design rather than bolted on after an audit finding.

This post connects enterprise deployment models, formal Zero Trust Architecture under NIST SP 800-207, infrastructure patterns, and cloud-specific traps—with scenarios and exam traps you can reuse on practice exams.

Architecture models and what changes for security

Every deployment topology redraws who owns which control, how identity is federated, and where sensitive data crosses physical or logical boundaries. Exam stems often hide the model in plain sight—"Identity is anchored in Azure AD, but core payroll still runs on hardware in the basement"—and expect you to reason about what those two worlds share and who is responsible for what falls between them.

On-premises means the organization retains facilities, hardware, hypervisors, networks, and most software stacks. That buys full visibility, hardware-backed key custody through on-prem HSMs, and tight control over data sovereignty—but only if staff and budget exist to operate it responsibly. The other side of that coin is that you own facility controls, physical access, firmware and OS patching, power, cooling, and every misconfiguration. When exam answers favor on-premises thinking, look for air-gapped ICS segments, strict legacy compliance language about physical custody, or workloads that simply cannot move.

Cloud and the shared responsibility model

Cloud models—IaaS, PaaS, SaaS—shift operational burden for physical infrastructure to a Cloud Service Provider (CSP). Transferring operations does not transfer accountability for your data and identity posture. Across every service model, the customer still owns data classification, identity and access decisions, and configuration choices inside what the provider exposes. CompTIA cares that you know misconfigured cloud resources remain your problem.

A compact mental model—customer always owns the top row; CSP ownership expands upward as you move right:

                 On-prem     IaaS       PaaS       SaaS
Data & identity    YOU        YOU        YOU        YOU
Applications       YOU        YOU        YOU      CSP+YOU*
OS / runtime       YOU        YOU        CSP        CSP
Hypervisor         YOU        CSP        CSP        CSP
Hardware / net     YOU        CSP        CSP        CSP
Facilities         YOU        CSP        CSP        CSP

* SaaS: provider runs the app; you still own config, users, and data decisions.

Hybrid and multicloud

Hybrid blends on-prem and cloud; multicloud uses multiple CSPs. Both multiply trust boundaries: a user authenticated to SaaS may still reach on-prem databases through a connector or hybrid VPN the architecture diagram forgot to draw. The mitigation pattern is consistent—federated identity with SSO and phishing-resistant MFA, conditional access, unified logging through SIEM and SOAR, CSPM for continuous misconfiguration detection, and encrypted transit that does not hairpin every flow through a single weak link.

When a stem describes "CRM in SaaS, HR database on-prem," strong answers reach for SSO and MFA across both realms, DLP on exports, controlled integration paths instead of a flat VPN that merges trust zones, and logging in both environments with clear ownership boundaries drawn before anything goes live.

IoT, OT, and ICS

Industrial Control Systems, SCADA, and IoT prioritize safety and availability over rapid patching or aggressive scanning. Maintenance windows stretch long; vendor-locked firmware may never patch cleanly; fragile embedded stacks crash under credentialed vulnerability scans. Purdue-model thinking applies: isolate IT from OT and monitor with passive TAP or SPAN where active scanning is unsafe. Privileged access runs through jump hosts and just-in-time (JIT) elevation, never standing domain admin on the plant floor. The exam trap here is confident advice like "patch everything this weekend" when the stem describes a manufacturing line that cannot stop.

Virtualization, containers, and infrastructure as code

Virtualization concentrates risk on the hypervisor. VM escape is architecturally significant even when rare—a host compromise affects every guest. Containers share the host kernel, so image hygiene matters: no secrets baked into layers, minimal base images, orchestration RBAC enforced, and registry signing to reduce supply-chain exposure. Over-permissioned Kubernetes service accounts appear regularly as a misconfiguration finding worth knowing by name.

Infrastructure as Code—Terraform, CloudFormation, Ansible—makes architecture repeatable, which is a security win when templates are reviewed and scanned in CI, and a loss when one bad module opens security groups across every environment simultaneously. A terraform apply that opens port 22 globally because a developer copied an unreviewed module is a misconfiguration finding, not a novel attack. The mitigation runs through IaC scanning in the pipeline, policy-as-code enforcement, production approval gates, and CSPM continuous detection after the fact.

Zero Trust Architecture (NIST SP 800-207)

Zero trust is an architectural paradigm, not a product SKU. Castle-and-moat designs assume anything inside the perimeter is trustworthy. Zero trust discards that implicit trust entirely.

The three core tenets are really one continuous idea expressed from three angles. You authenticate and authorize every request in context and encrypt regardless of whether traffic originates on the LAN or the open internet—because origin alone tells you nothing useful about intent or risk. Minimal access follows from that: JIT elevation and contextual policy replace the standing broad VPN rights that make lateral movement cheap. And when you assume breach, you design as if an adversary already has a foothold, constraining movement through microsegmentation and continuous session monitoring instead of betting everything on the perimeter holding. Traditional VPN models often grant broad network access after a single authentication event. Zero trust pushes the decision to each request and session: who is this, what is the device posture, what specific resource is being reached, and what does the risk signal look like right now?

Control plane vs data plane (PE / PA / PEP)

CompTIA expects you to separate where policy is decided from where traffic is enforced:

                 CONTROL PLANE
  +------------------+      +------------------------+
  |  Policy Engine   | ---> | Policy Administrator   |
  |  (decide)        |      | (issue/revoke tokens)  |
  +------------------+      +------------------------+
                                      |
                                      v
                 DATA PLANE
  Subject/Device ---> Policy Enforcement Point ---> Enterprise resource
                      (PEP: allow / deny / kill)

Identity is the perimeter in this model—MFA plus device health, microsegmentation of east-west traffic, continuous validation where an impossible-travel signal triggers re-authentication or a block, and analytics correlated across identity, device, application, and network. ZTNA (Zero Trust Network Access) translates that into practice by replacing "VPN to the entire LAN" with application-specific access. When contractors should reach one app and nothing else, ZTNA patterns beat full-tunnel VPN by a wide margin.

The exam trap worth burning in: "Zero trust means no firewall." False. Firewalls and PEPs remain. Default implicit trust is what disappears.

Secure enterprise infrastructure patterns

Segmentation and screened subnets

Network segmentation limits lateral movement—it is critical in ransomware stems that describe a flat network, where one compromised workstation becomes a company-wide incident. Microsegmentation applies the same idea at workload or identity granularity, which means a compromised web tier cannot freely query the database tier without hitting an enforcement point that requires fresh authorization.

Screened subnets (DMZ) expose only necessary services to the internet while internal applications and databases sit behind additional boundaries:

Internet → [WAF] → DMZ (web) → internal firewall → app tier → data tier

Mark a trust boundary at each hop in your mental diagram. Dual-homed servers that bridge the DMZ and internal networks without strict rule sets are a classic exam mistake—they collapse two distinct security zones into one exposed box and remove the control the DMZ was designed to provide.

Secure connectivity and privileged access paths

VPN, IPsec site-to-site, private links, and ZTNA solve different problems and the exam expects you to match the solution to the need. VPNs encrypt the path; they do not automatically enforce least privilege inside the tunnel. Private links reduce public exposure but still need IAM and segmentation at the endpoints.

Administrators should not RDP from home laptops straight to domain controllers. Bastion hosts, PAM, session recording, and JIT elevation protect the admin plane. When a stem describes a helpdesk technician using domain admin credentials "for convenience," the answer path runs through least privilege and PAM—not a policy memo that no one reads.

High availability and load balancing

HA and load balancers support availability, which the exam treats as a security objective when DDoS or single points of failure appear in the stem. Active-active versus active-passive configurations, health checks, and geographic distribution all matter in disaster narratives. The exam trap: two load-balanced web servers with default admin credentials is not resilience—it is doubled attack surface hiding behind the appearance of redundancy.

Device and IoT placement

Cameras, printers, and HVAC controllers do not belong on the same VLAN as finance databases. NAC and 802.1X-style concepts tie device identity to network placement, and architecture allocates the subnets and enforces the policies before Domain 4 operations inherit the day-to-day.

Defense in depth done correctly

Defense in depth stacks independent controls across identity, endpoint, network, application, data, and monitoring. Two identical firewalls enforcing the same bad rule is redundancy, not depth—the distinction matters in exam stems that ask "best" rather than "most."

A web application done right illustrates the idea concretely. A WAF at the edge handles application-layer attacks; segmented app and database tiers contain lateral movement if the web tier falls; parameterized queries remove the SQL injection risk the WAF might miss on a bad day; database encryption combined with a least-privilege database user limits what an attacker can read even with valid credentials; MFA on admin access constrains privilege abuse; and SIEM watching authentication and WAF logs means a bypass does not stay invisible. Each layer is independent—a WAF bypass does not hand over database read access, it only removes one obstacle. That is depth. Two WAFs with identical rulesets is an expensive single control.

Cloud-specific architecture instincts

Beyond shared responsibility, cloud stems reward a few specific instincts. Overbroad IAM roles, long-lived access keys baked into server configurations, and missing MFA on root or admin accounts are the most common identity-layer findings—prefer roles over keys, short-lived credentials, and permission boundaries. Storage exposure through public buckets, unencrypted snapshots shared publicly, and unlogged backups in object storage are the data-layer equivalents. CASB handles SaaS shadow IT; CSPM-style continuous misconfiguration detection watches IaaS and PaaS—CompTIA may vary acronyms, but the idea of continuous posture assessment is what sticks. Customer-managed keys give you regulatory control over encryption; TLS keeps data safe wherever it crosses an untrusted path.

The worked example worth knowing cold: API keys committed to a public GitHub repository. The failure is secrets management, not repository visibility—making the repo private after the fact does not help if forks already exist. The fix is a vault or secret manager, CI secret scanning, and short-lived tokens.

Applying architecture to a hybrid scenario

Stem: A regional bank moves customer chat to a SaaS vendor while core banking stays on-prem via mainframe connectors.

A strong answer runs the full trust-boundary story. Chat agents authenticate through federation and SSO with MFA, kept separate from mainframe authentication where legacy constraints require it. Data minimization and retention limits apply to chat logs that capture PII, so the SaaS vendor holds only what the business justifies. DLP blocks account numbers from flowing into unsanctioned channels—the bank cannot control where an employee pastes a screenshot once it leaves the browser. The network path from SaaS back to the on-prem connector runs through a controlled integration layer rather than a flat VPN that would make the mainframe reachable from any compromised chat session. Vendor risk assessment, assurance reports, and incident-notification SLAs define the contractual boundary so accountability survives the relationship. Logging flows to SIEM from the SaaS audit APIs and the on-prem connector so one correlation surface sees the full story. Business continuity planning covers the SaaS-unavailable scenario with a documented fallback channel, because the bank's obligation to serve customers does not pause for a vendor outage.

Weak answers reach for "encrypt the laptops" (orthogonal to the integration risk) or "air-gap the internet" (which destroys the business rationale for SaaS in the first place).

Sketch exercise for study

Draw three zones on paper: users, application tier, and data tier. Place the identity provider at the perimeter where users authenticate, a WAF or API gateway at the edge where external traffic enters, SIEM log aggregation off to the side collecting from every zone, and a backup path deliberately outside the production trust zone to capture the immutable or offline-copy concept. Annotate every arrow with a protocol and an authentication mechanism—HTTPS with OIDC, SSH through a bastion with certificate auth, whatever the flow actually demands. Then overlay a NIST-style loop: the subject reaches a PEP, which checks the PE and PA off the data path before allowing the request to continue to the resource. If you cannot mark trust boundaries on your own diagram without looking at notes, architecture questions will feel like random tool picks. Repeat the exercise with one SaaS box placed outside your network border to force yourself through the hybrid variant. Both diagrams together cover most of the scenario space Domain 3 throws at candidates.

Exam traps summary

Closing frame

Architecture questions ask: Where does trust change? Who can reach what? What fails safely? Zero trust under NIST SP 800-207, segmentation, and shared responsibility are lenses for answering those questions—not buzzwords to sprinkle on every answer. Study the PE/PA/PEP split until you can draw it from memory, and practice the shared-responsibility table until the row for IaaS produces "guest OS is yours" without conscious effort.

The companion post on data protection and resilience completes the other half of secure design: once you have drawn the zones, you must classify what lives inside them, encrypt it appropriately, and survive losing a site or a weekend of systems. Master both halves and Domain 3 stops feeling like a vocabulary test.