10.3 Cloud Application Architecture (Domain 4.6)
Key Takeaways
- Domain 4.6 covers cloud application architecture specifics: supplemental security components (WAF, DAM, XML firewalls, API gateway, load balancer), cryptography, sandboxing, and application virtualization/orchestration (microservices, containers, Docker, Kubernetes).
- Supplemental components add defense in depth at the edge and data tier but do not replace secure design, authZ, or secure coding.
- Cryptography protects data and trust (TLS, encryption at rest, signing, key custody); design for algorithm agility and correct key management ownership.
- Sandboxing isolates risky code or workloads to limit blast radius of compromise or untrusted input processing.
- Microservices, containers, and orchestrators introduce service identity, image provenance, network policy, and control-plane security as first-class architecture concerns.
Cloud Application Architecture
Domain 4.6 requires you to comprehend and apply the specifics of cloud application architecture. The outline groups: supplemental security components (Web Application Firewall (WAF), Database Activity Monitoring (DAM), Extensible Markup Language (XML) firewalls, Application Programming Interface (API) gateway, load balancer); cryptography; sandboxing; and application virtualization and orchestration (microservices, containers, Docker, Kubernetes). This is the architectural toolkit that surrounds application code in cloud deployments.
Architecture as Security Design
Cloud application architecture defines trust boundaries, data flows, and control insertion points. A correct component in the wrong place (WAF without TLS understanding, encryption without key access control, Kubernetes without RBAC) creates a false sense of safety.
| Architectural question | Security implication |
|---|---|
| Where does identity live? | Federation, service mesh policy, gateway auth |
| Where is data at rest? | Encryption, DAM, backup isolation |
| How do services talk? | mTLS, API gateway, zero-trust east-west |
| What runs untrusted logic? | Sandbox, container isolation, least privilege |
| How is capacity managed? | Load balancer health, autoscaling abuse controls |
Exam framing: Match the component to the threat (injection noise → WAF; SQL abuse/insider queries → DAM; coarse XML attacks → XML firewall; API traffic management → gateway; availability/distribution → load balancer) while remembering none of these fix missing tenant authZ alone.
Supplemental Security Components
These components sit beside or in front of applications to add monitoring, filtering, routing, and policy enforcement.
Web Application Firewall (WAF)
A WAF inspects HTTP/HTTPS application traffic for attacks such as injection, XSS, known exploit patterns, and some bot abuse. It can run as a cloud service, reverse proxy, or platform feature.
| WAF strength | WAF limitation |
|---|---|
| Virtual patching for known exploit patterns | Limited understanding of complex business logic |
| Rate and geo controls at Layer 7 | Misconfigured rules can block legitimate traffic |
| Complements secure coding | Not a substitute for fixing root vulnerabilities |
Place WAFs at internet-facing edges. Tune to reduce false positives. Log and alert on blocks. Pair with secure SDLC so WAF is compensating, not permanent sole mitigation for known code bugs.
Database Activity Monitoring (DAM)
DAM monitors database queries and admin actions for unauthorized access, privilege abuse, anomalous query patterns, and policy violations—often independent of native DB logs alone.
| DAM use case | Example |
|---|---|
| Privileged user monitoring | DBA selects entire PII table off-hours |
| Application anomaly | Service account suddenly issues DDL |
| Compliance evidence | Prove access monitoring for regulated data stores |
| Insider threat detection | Bulk export patterns |
DAM does not encrypt data or replace IAM on the database; it provides visibility and detection. Protect DAM itself from tampering by the accounts it watches.
XML Firewalls
XML firewalls (and related XML/JSON threat protection at gateways) inspect structured messages for XML-specific attacks: oversized payloads, entity expansion (XXE-class issues), schema non-compliance, and malicious transformations. In SOAP/legacy enterprise integrations still common in hybrid cloud, XML firewalls remain relevant. Modern JSON APIs often use schema validation and threat protection features on API gateways with similar intent.
API Gateway
An API gateway is a managed entry point for API traffic offering:
| Capability | Security value |
|---|---|
| Authentication offload | Central token validation |
| Authorization hooks | Coarse route-level controls |
| Rate limiting / quotas | Availability and cost protection |
| Request/response transformation | Normalize and strip sensitive headers |
| TLS termination / re-encryption | Consistent crypto posture |
| Routing and versioning | Controlled exposure of API versions |
| Analytics and logging | Inventory and anomaly detection |
| Threat protection | Schema checks, size limits |
Architecture rule: Gateways enforce edge policy; services still enforce object-level authorization and business rules.
Load Balancer
Load balancers distribute traffic for scalability and availability. Security-relevant aspects:
| Feature | Security/resilience role |
|---|---|
| Health checks | Remove compromised or failed nodes |
| TLS termination / passthrough | Crypto design point; certificate management |
| Protocol controls | Disable weak ciphers/protocols at edge |
| Integration with WAF/DDoS | Layered edge defense |
| Internal vs external balancers | Separate public and private planes |
| Session affinity awareness | Understand sticky sessions for auth design |
Load balancers are not primarily authorization engines; do not treat “behind a LB” as “authenticated.”
Component Placement Table
| Component | Typical placement | Primary threats addressed |
|---|---|---|
| WAF | Public HTTP edge | OWASP-class web attacks, some bots |
| API gateway | North-south API edge (and some internal) | AuthN at edge, abuse of open APIs, version sprawl |
| XML firewall | SOAP/XML integration boundary | XML attacks, schema abuse |
| Load balancer | Before app tiers | Availability, TLS edge, healthy routing |
| DAM | Near data stores (logical) | DB abuse, insider/anomalous queries |
Defense in depth example: Internet users → DDoS protection → load balancer → WAF → API gateway → microservices → database with IAM least privilege and DAM on sensitive clusters.
Cryptography in Cloud Application Architecture
Cryptography protects confidentiality, integrity, authenticity, and non-repudiation when designed and keyed correctly.
Where Crypto Appears in Apps
| Layer | Application |
|---|---|
| In transit | TLS for user and service traffic; mTLS between services |
| At rest | Volume, object, database, backup encryption |
| Application-level | Field encryption for high-sensitivity elements before storage |
| Integrity | Hashing, HMAC, code/image signing |
| Identity | Certificate-based auth, signed tokens (JWT with proper validation) |
| Key management | KMS/HSM-backed keys; envelope encryption; rotation |
Design Principles for CCSP
- Prefer standard protocols and libraries—do not invent crypto.
- Separate key custody from encrypted data where threat requires (customer-managed keys).
- Least privilege on key use—encrypt/decrypt permissions are high value.
- Rotate and revoke keys/certificates; automate expiration monitoring.
- Protect against metadata and side channels where relevant (for example, do not put secrets in URLs/logs).
- Plan algorithm agility so broken primitives can be replaced.
- Mind shared responsibility—provider offers KMS; you configure key policies, access, and app integration.
Common Architectural Crypto Failures
| Failure | Result |
|---|---|
| TLS terminated then cleartext on flat internal networks without compensating controls | Lateral sniffing risk |
| Hardcoded keys in images | Global compromise on leak |
| Encryption at rest with publicly readable objects | Attackers read via API as authorized anonymous |
| Custom XOR “encryption” | Trivial break |
| JWT accepted without signature/algorithm validation | Auth bypass |
| Same key for every tenant without isolation strategy | Blast radius on key compromise |
Cryptography is necessary architecture glue for cloud apps, but access policy and secure key lifecycle determine real strength.
Sandboxing
Sandboxing runs code or processes in restricted environments so compromise or misbehavior cannot easily reach the host, sibling workloads, or sensitive data.
Sandbox Use Cases
| Use case | Example |
|---|---|
| Untrusted content processing | Convert user-uploaded documents in an isolated worker |
| Executable untrusted code | Customer scripts, plugins, or infrastructure-as-code plan evaluation |
| Browser isolation | High-risk browsing separated from corporate endpoints |
| Mobile/app runtime | OS-level app sandboxes (conceptually related) |
| Function isolation | Per-invocation isolation in serverless platforms |
| Test of suspicious packages | Detonate in isolated pipeline runners |
Properties of Effective Sandboxes
- Strong isolation (containers with hardened profiles, VMs, gVisor-like runtimes, separate accounts).
- Least privilege identities and network egress allow-lists.
- Ephemeral filesystems and no access to production secrets.
- Resource limits (CPU, memory, time, disk) against DoS from within.
- Monitoring of breakout attempts and anomalies.
- No shared writable host mounts by default.
Sandbox vs Container vs VM
| Mechanism | Isolation strength (generalized) | Notes |
|---|---|---|
| Process alone | Weak | Not a sandbox |
| Container | Moderate | Share kernel; harden and avoid privileged mode |
| Hardened container / user-space kernel | Stronger | Better for untrusted code |
| VM / separate account | Strong | Higher overhead; clear blast-radius boundary |
Exam tip: When stems involve processing untrusted uploads or running customer code, sandboxing is often the architecture control—not only “add a WAF.”
Application Virtualization and Orchestration
Microservices
Microservices decompose applications into independently deployable services communicating over networks (HTTP/gRPC/events).
| Benefit | Security challenge |
|---|---|
| Independent scaling and release | Larger attack surface of APIs |
| Technology flexibility | Inconsistent authZ implementations |
| Fault isolation (if designed) | Cascading failures and retry storms |
| Team autonomy | Divergent logging and secret practices |
Microservice security architecture patterns:
- Service identity and mTLS (mesh or platform).
- Centralized authZ or rigorously shared libraries.
- API gateway for north-south; service mesh policy for east-west.
- Per-service least-privilege datastore credentials.
- Distributed tracing with careful PII handling.
- Circuit breakers and timeouts (availability as security-adjacent resilience).
- Threat models per service trust boundary.
Containers and Docker
Containers package application and dependencies into portable images. Docker popularized container tooling (images, registries, daemon/runtime concepts). CCSP expects security practices, not product trivia.
| Control area | Practice |
|---|---|
| Image hygiene | Minimal base, no secrets in layers, SCA on images |
| Provenance | Sign images; pull by digest |
| User | Non-root processes |
| Capabilities | Drop Linux capabilities; read-only root FS where possible |
| Secrets | Inject at runtime via secret stores—not ENV in image history |
| Registries | Private, scanned, access-controlled |
| Runtime | Avoid privileged containers; limit hostPath mounts |
| Patching | Rebuild images frequently; immutable deploy |
Kubernetes and Orchestration
Kubernetes orchestrates containers: scheduling, networking, scaling, rolling updates, and declarative desired state. Security architecture must cover cluster control plane, nodes, workloads, and supply chain.
| Domain | Controls |
|---|---|
| AuthN/AuthZ | Strong identity for users and service accounts; RBAC least privilege; disable anonymous risky access |
| Admission control | Policy webhooks for signed images, non-root, resource limits |
| Network policy | Default-deny east-west; allow only required paths |
| Secrets | Encrypt etcd secrets; external KMS; short-lived tokens |
| Pod security | Restricted profiles; no privileged escalation |
| Supply chain | Only trusted registries; admission on digest/signature |
| Observability | Audit logs for API server; runtime detection |
| Multi-tenancy | Namespaces are not hard multi-tenant boundaries without extra controls; use separate clusters/accounts for strong isolation |
| Node hardening | Minimal OS, patching, restricted SSH |
| Egress control | Limit pod access to metadata and internet |
Orchestration Threat Examples
| Threat | Architectural mitigation |
|---|---|
| Compromised CI deploys malicious pod | Signed images + admission + least-privilege deploy identity |
| Pod escapes to node | Non-privileged, hardened runtime, up-to-date nodes |
| Lateral movement pod-to-pod | Network policies, mTLS |
| Stolen service account token | Bound tokens, short life, audience restrictions |
| Dashboard exposed publicly | Never expose control plane without strong auth and network restriction |
Serverless Note (Architecture Adjacent)
While the outline names microservices/containers/Docker/Kubernetes under virtualization and orchestration, cloud architectures also use serverless functions. Apply the same principles: least privilege roles, dependency SCA, secrets not in code, sandbox assumptions, and API gateway fronts. Do not ignore event-source permissions (who can invoke the function).
Integrated Architecture Scenario
A fintech exposes APIs publicly: global load balancer and WAF at the edge, API gateway for JWT validation and rate limits, microservices on Kubernetes with network policies and mTLS, field-level crypto for account numbers via KMS, DAM on the primary database, and untrusted document parsing in a sandboxed worker queue with no production datastore credentials. That design applies every Domain 4.6 bullet in one system.
Putting Domain 4.6 Together for the Exam
- Map threat → supplemental component (injection patterns → WAF; DB insider queries → DAM; API sprawl → gateway; availability → LB; XML threats → XML firewall).
- Place cryptography with correct key custody and TLS design.
- Use sandboxing for untrusted execution/content.
- For containers/K8s/microservices, emphasize identity, network policy, image provenance, and RBAC—not only “we containerized it.”
- Reject answers that claim a WAF or gateway alone completes application security.
Common Traps
- Equating load balancing with authentication.
- Storing long-lived cloud keys in container images.
- Treating Kubernetes namespaces as sufficient hard multi-tenancy for hostile tenants.
- Enabling a WAF in monitoring-only mode forever and calling the risk mitigated.
- Encrypting disks while leaving API anonymous public access.
- Running privileged containers “for convenience” in production.
Security needs detection of anomalous privileged SELECT statements against a regulated customer database that already uses IAM and encryption at rest. Which supplemental component best fits?
Which Kubernetes-oriented control set best reduces risk of unauthorized lateral movement and untrusted image deployment?
An application must convert untrusted user-uploaded office documents to PDF. Which architectural control is most appropriate to limit blast radius if a parser vulnerability is exploited?
What is a correct characterization of an API gateway in cloud application architecture?