Design security solutions for infrastructure
Security Requirements for Cloud Services
CoreDefine shared-responsibility baselines for SaaS, PaaS, IaaS, IoT, web, container, orchestration, and Azure AI services without losing workload-specific threat context.
Aligned to SC-100 skills measured as of October 21, 2026; candidates testing earlier should review the transition note in the lane overview.
Why this matters
Service models move control responsibilities; they do not remove them. Architects must identify which party controls identity, network, platform, runtime, application, data, and evidence at every layer before choosing safeguards.
Must Know
- SaaS emphasizes tenant configuration, identity, data governance, third-party integration, logging, and vendor assurance; customers cannot harden provider hosts.
- PaaS reduces operating-system duties but leaves identity, network exposure, application configuration, data, secrets, diagnostics, and service-specific controls with the workload team.
- IaaS customers retain responsibility for guest operating systems, workload middleware, endpoint controls, patching, identities, network segmentation, and data protection.
- Web workloads need authenticated management, WAF or edge protection where appropriate, secure headers and TLS, secretless backend access, private origins, logging, and safe deployment.
- Container design covers trusted registries, signed and scanned images, minimal bases, nonroot execution, immutable deployment, secret handling, runtime protection, and image provenance.
- Orchestrator security adds cluster identity, API-server access, node and pod isolation, network policy, admission control, RBAC, workload identity, audit, upgrade, and control-plane considerations.
- Azure AI services require secured endpoints, managed identity, data isolation, content-safety and abuse controls, model and prompt evaluation, logging, and protection of grounding and output data.
Compare and Distinguish
- Container-image security protects the packaged workload; orchestration security governs scheduling, identities, admission, networking, secrets, and cluster operations.
- A service security baseline supplies common defaults, while workload threat modeling adds business-specific abuse cases and data consequences.
Scenario examples
- Scenario: A platform team standardizes three service models. Think: create responsibility-specific baselines and policy evidence instead of imposing virtual-machine controls on SaaS.
- Scenario: An AI API handles regulated documents and tool calls. Think: isolate data and endpoints, use managed identity, constrain tools, evaluate harmful behavior, log access, and govern outputs.
Exam traps
- Moving to PaaS does not make public endpoints, weak application authorization, or exposed secrets the provider's responsibility.
- Scanning an image before deployment does not control excessive Kubernetes RBAC or runtime network reachability.
Key takeaways
- Shared responsibility moves control ownership; it does not remove customer duties.
- A trusted image does not settle cluster authorization, pod identity, or east-west reach.
- For Azure AI, protect the grounding and tool paths as deliberately as the model endpoint.
How it works
- Enterprise baselines define approved configurations and evidence, while platform automation applies them at provisioning and monitors drift.
- AI safeguards combine preventive access and network controls with evaluations, content controls, runtime monitoring, and incident handling.
Objects and administrative surfaces
- Security baseline documents, tenant settings, resource firewalls, private endpoints, managed identities, diagnostic settings, and policy assignments.
- Registries, image attestations, Kubernetes RBAC and admission policies, network policies, AI endpoints, model deployments, evaluations, and content filters.
When to use it
- Use responsibility-specific baseline patterns whenever a portfolio mixes service models or shared platforms.
Security and governance implications
- Document provider, platform-team, and workload-team responsibilities with acceptance criteria for every managed service pattern.
Troubleshooting signals
- If baseline adoption stalls, check whether requirements are actionable for the service model and whether exceptions have an owned path.
- If container findings reappear, verify base-image ownership, rebuild cadence, deployment provenance, and runtime inventory.
More detail
- Specify distinct baselines for SaaS, PaaS, and IaaS.
- Cover IoT, web, container, and orchestration boundaries.
- Evaluate Azure AI services as data-processing and action-capable workloads.
Ready for the quiz?
- Which security duties move when a database changes from IaaS to PaaS?
- What cluster risks remain after an image passes scanning?
- Which AI controls prevent a model from overreaching into sensitive tools?
Related objectives
- D3.3.S1 — Specify security baselines for SaaS, PaaS, and IaaS services
- D3.3.S2 — Specify security requirements for IoT workloads
- D3.3.S3 — Specify security requirements for web workloads
- D3.3.S4 — Specify security requirements for containers
- D3.3.S5 — Specify security requirements for container orchestration
- D3.3.S6 — Evaluate solutions that include Azure AI services security