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 attacker crosses the line you drew. Roughly 18% of the exam sits here. Tool names matter less than patterns: segmentation, identity-centric access, shared responsibility in cloud, and resilience baked into design rather than bolted on after an audit finding.

This post connects deployment models, zero trust principles, enterprise infrastructure patterns, and cloud-specific traps—with scenarios you can reuse on practice exams.

Architecture models and what changes for security

Every deployment model shifts who owns which control and where data flows. Exam stems often hide the model in plain sight ("our IdP is Azure AD but payroll stays in the basement").

On-premises

On-premises means the organization operates facilities, hardware, networks, and most software stacks. Security upside: full visibility and policy enforcement if staff and budget exist. Downside: you own patching, physical access, power, cooling, and every misconfiguration.

When exam answers favor on-prem thinking: Air-gapped segments, strict data residency, legacy apps that cannot move, or regulatory language about physical control.

Cloud

Cloud (IaaS, PaaS, SaaS) moves operational burden to a provider but not accountability for your data and identities. The shared responsibility model is non-negotiable on the exam:

The exact line varies by vendor—CompTIA cares that you know misconfigured cloud resources remain your problem.

Hybrid and multicloud

Hybrid blends on-prem and cloud (or multiple clouds). Identity federation, VPNs or private links, duplicate logging, and inconsistent patch cadence create trust boundary multiplication. A user authenticated in cloud SaaS may still reach on-prem SQL through a connector the diagram forgot to draw.

Exam scenario pattern: "CRM in SaaS, HR database on-prem." Strong answers mention SSO/MFA, conditional access, encrypted transit, DLP on exports, network paths that avoid hairpinning all traffic through a single weak link, and logging in both realms with clear ownership.

IoT, OT, and ICS

IoT/OT/ICS environments prioritize availability and safety over rapid patching. Rebooting a PLC during production may be unacceptable; scanning with aggressive credentialed tools can crash fragile devices.

Security implications:

• Long patch windows and vendor-maintained firmware
• Segmentation between IT and OT (Purdue model thinking)
• Monitoring focused on protocol anomalies, not only CVEs
• Physical and environmental constraints (HVAC, sensors) as attack surface

Exam trap: Recommending "patch everything this weekend" when the stem describes manufacturing lines that cannot stop.

Virtualization, containers, and infrastructure as code

Virtualization concentrates risk on the hypervisor. VM escape is rare but architecturally significant—compromise of the host affects every guest.

Containers share the host kernel. Image hygiene (no secrets in layers), minimal base images, orchestration RBAC (Kubernetes service accounts with excessive permissions show up as misconfiguration vulnerabilities), and registry signing reduce supply-chain and lateral movement risk.

Infrastructure as Code (IaC)—Terraform, CloudFormation, Ansible—makes architecture repeatable. That is a security win when templates are peer-reviewed and scanned; it is a loss when one bad module propagates open security groups to every environment.

Worked example: A terraform apply opens port 22 globally because a dev copied a module. Vulnerability class: misconfiguration. Mitigation: IaC scanning in CI, policy-as-code (OPA/Sentinel-style concepts), manual approval for prod, CSPM continuous detection.

Zero trust: verify explicitly, assume breach

Zero trust is not a product SKU—it is a design stance: never trust, always verify, least privilege, assume breach, and microsegmentation with identity-aware policy.

Traditional "castle and moat" VPN models often grant broad network access after one authentication event. Zero trust pushes decisions to each request/session: who, what device posture, what resource, what risk score?

Core exam-friendly elements:

• Identity as perimeter — strong auth (MFA), device health signals
• Microsegmentation — east-west traffic restricted, not only north-south at the firewall
• Continuous validation — session risk changes (impossible travel) trigger re-auth or block
• Logging and analytics — visibility across identity, device, app, network

ZTNA (Zero Trust Network Access) replaces "VPN to entire LAN" with application-specific access brokers. When a stem says "contractors should reach only one app, not the file servers," ZTNA patterns beat full-tunnel VPN.

Exam trap: "Zero trust means no firewall." False—firewalls and policy enforcement remain; default implicit trust is what disappears.

Secure enterprise infrastructure patterns

These patterns recur because they solve recurring failure modes.

Segmentation and screened subnets

Network segmentation limits lateral movement—critical in ransomware stems mentioning "flat network." Microsegmentation applies the same idea at workload or identity granularity (software-defined policies between apps).

Screened subnets (DMZ) expose only necessary services to the internet. Internal apps and databases sit behind additional boundaries. Dual-homed servers bridging DMZ and internal without strict rules are classic exam mistakes.

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

The ASCII sketch is simplified; your mental diagram should mark trust boundaries at each hop.

Secure connectivity

VPN, IPsec site-to-site, MPLS/private links, and ZTNA solve different problems. VPNs encrypt paths; they do not automatically enforce least privilege inside the tunnel. Private links reduce exposure to the public internet but still need IAM and segmentation at endpoints.

High availability and load balancing

HA and load balancers support availability—a CIA pillar exams treat as security when DDoS or single points of failure appear. Active-active vs active-passive, health checks, and geographic distribution matter in disaster narratives.

Exam trap: HA without security—two load-balanced web servers both running default admin credentials is not resilience, it is doubled risk.

Jump hosts and privileged access paths

Administrators should not RDP from home laptops directly to domain controllers. Jump hosts/bastions, PAM, session recording, and just-in-time elevation protect the admin plane. Stems about "helpdesk uses domain admin for convenience" scream least privilege and PAM.

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—preview of Domain 4, but architecture must allocate subnets and policies first.

Defense in depth done correctly

Defense in depth stacks independent controls across identity, endpoint, network, application, data, and monitoring layers. Two identical firewalls enforcing the same bad rule is redundancy, not depth.

Good depth example for a web app:

1. WAF at edge (application layer)
2. Segmented app and DB tiers (network)
3. Parameterized queries (application)
4. DB encryption + least-privilege DB user (data)
5. MFA for admin access (identity)
6. SIEM correlation on auth and WAF logs (monitoring)

If one layer fails (WAF bypass), others still constrain blast radius.

Cloud-specific architecture instincts

Beyond shared responsibility, these themes dominate cloud stems:

Identity in cloud: Overbroad IAM roles, long-lived access keys on servers, and missing MFA on root/admin accounts. Prefer roles over keys, rotate credentials, use permission boundaries.

Storage and exposure: Public buckets, unencrypted snapshots shared publicly, backup files in object storage without access logging.

Visibility: CASB for SaaS shadow IT and policy; CSPM-style continuous misconfiguration detection for IaaS/PaaS. CompTIA may use varying acronyms—the idea of continuous posture assessment is what sticks.

Encryption: Customer-managed keys (CMK/KMS concepts) for regulatory control; encryption in transit (TLS) everywhere data crosses untrusted networks.

Worked example: A startup deploys API keys in GitHub. Architecture failure: secrets management. Mitigation: vault/secret manager, CI scanning for leaks, short-lived tokens, not "make repo private" alone if forks exist.

Applying architecture to a hybrid scenario

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

Strong answer threads:

• Federation/SSO with MFA for chat agents; separate from mainframe auth where required
• Data minimization—what chat logs contain (PII) and retention limits
• DLP preventing export of account numbers into unsanctioned channels
• Network path from SaaS to on-prem connector through controlled integration layer, not flat VPN
• Vendor risk assessment, SOC 2/ISO reports, incident notification SLAs
• Logging to SIEM from SaaS audit API and on-prem connector
• BCP/DR if SaaS unavailable—fallback channel documented

Weak answers: "Encrypt laptops" (orthogonal) or "air-gap the internet" (ignores SaaS business need).

Sketch exercise for study

Draw three zones: users, application tier, data tier. Place:

• Identity provider (IdP)
• WAF or API gateway at the edge
• SIEM log aggregation
• Backup path outside the production trust zone (immutable/offline concept)

Annotate every arrow with protocol and auth mechanism. If you cannot mark trust boundaries, architecture questions feel like random tool picks. Repeat for a hybrid cloud variant with one SaaS box outside your network border.

Exam traps summary

Closing frame for Domain 3 part one

Architecture questions ask: Where does trust change? Who can reach what? What fails safely? Zero trust, segmentation, and shared responsibility are lenses—not buzzwords to sprinkle on every answer.

The companion post on data protection and resilience completes the other half of secure design: once you drew 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 being a vocabulary test.