Build security readiness, protect confidentiality, integrity, and availability, and continuously improve the workload security posture with Zero Trust.
Suggested study time: 84 minutes • Intermediate • Complete original rewrite with a concise summary for every topic
By João Ricardo Dutra••Complete original content
1. Make security a design property of the workload
The Security pillar of the Azure Well-Architected Framework asks whether a workload protects its data and systems to the level its business requires. A secure architecture raises the effort and cost of compromise, limits the blast radius when prevention fails, understands what an attacker values, and enables rapid detection, response, and recovery. Even a small incident can damage customers, compliance, brand, and trust.
Use Microsoft Zero Trust as the decision compass: verify explicitly, grant least privilege, and assume breach. Protect confidentiality, integrity, and availability—the CIA triad—without losing sight of legitimate business outcomes. Security belongs in requirements, architecture, code, delivery, operations, and recovery rather than in a final review.
A secure workload combines Zero Trust decisions with the interdependent goals of the CIA triad.
Topic summary
Build security into the whole lifecycle, make compromise costly, contain its effect, and preserve confidentiality, integrity, and availability.
2. Apply five connected security principles
Security principles and their architectural purpose.
Principle
Purpose
Plan security readiness
Align business priorities, ownership, investment, segmentation, response, and secure practices.
Protect confidentiality
Restrict and obscure sensitive information throughout its lifecycle.
Protect integrity
Keep code, data, devices, workflows, and backups trustworthy and unaltered.
Protect availability
Prevent attacks from exhausting or locking out legitimate service and recovery.
Sustain the posture
Model threats, test controls, patch assets, automate evidence, and improve continuously.
No principle works alone. Encryption without key governance can block recovery; high availability without input validation can multiply malicious work; segmentation without least privilege can preserve excessive access inside each segment. Decisions must be tested as one system.
Topic summary
Use the five principles as one security operating model and evaluate interactions and trade-offs between controls.
3. Plan the Contoso Supermarket loyalty workload
A fictional supermarket is designing an NFC-enabled phone loyalty experience for both unattended purchases and purchases handled by a cashier. Customers enroll at in-store kiosks, and the back end will run in the cloud. The design is not final, so security readiness can still shape boundaries, identities, data handling, support, and deployment.
The workload owner shares responsibility with the organization. A readiness plan converts business priorities and regulatory obligations into clear roles, processes, investments, incident procedures, reliability assumptions, health models, and self-preservation measures. Budget and functional constraints inform engineering choices; they must not erase required protection.
Topic summary
Establish security ownership and minimum outcomes while the architecture is still flexible, and integrate them with reliability and operations.
4. Segment access, components, networks, and duties
Segmentation creates boundaries in the environment, processes, and team structure. Base boundaries on flow criticality, privacy, data sensitivity, blast radius, and division of duties. Clearly defined roles reduce friction because each identity receives the access needed for its task, especially for privileged accounts.
A QA intern inherited broad access through group membership, and social engineering compromised the account and every deployment sharing the application platform. The prototype avoided production harm, but the design lesson remains: separate components that process personal addresses and email from coupon services, isolate workload networks from the corporate environment, and use need-to-know plus just-in-time access.
Segmentation and least privilege contain compromise instead of allowing one identity to cross the entire platform.
Topic summary
Segmentation benefits security by isolating resource access according to least privilege and by reducing the blast radius of a compromised identity.
5. Prepare an executable security incident response plan
A workload-specific response plan should follow an accepted framework and cover preparation, detection, analysis, containment, mitigation, eradication, recovery, evidence, communications, escalation, and post-incident improvement. Define severity, authority, legal and privacy contacts, customer communication, on-call routes, playbooks, and remediation deadlines before a crisis.
The supermarket team had retailer support, customer support, and technical rotations but no security path. Working with the central security team, it maps internal and external compliance duties for personal information, then adds detection, mitigation, escalation, and communications. Rehearsals before launch make the plan operational. A disaster recovery, continuity, or DDoS plan does not replace the security incident response plan.
Clear ownership and practiced playbooks let responders spend an incident executing rather than inventing a process.
Topic summary
Create and rehearse a dedicated security incident response plan with roles, evidence, communications, containment, recovery, and improvement.
6. Codify secure development and operations
Set workload standards for requirements, architecture, coding, dependencies, peer approval, testing, change control, deployment, secrets, data handling, telemetry, rollback, and vulnerability remediation. A consistent process prevents avoidable mistakes and makes automated gates possible. It also produces evidence for audits and exposes opportunities to improve.
Although the loyalty workload does not store card data, customer information remains subject to local and federal obligations. The team learns current secure development and operations practices instead of blindly reusing old ones, adopts missing controls, and shares improvements with the organization. Consistent standards are the reason the knowledge-check statement about secure development is true.
Topic summary
Translate security policy into documented, repeatable, and increasingly automated development and operational controls.
7. Protect confidentiality in the Contoso Rise Up SaaS
A fictional fundraising SaaS provider runs a multitenant solution on and , with shared and isolated tenant options. Confidentiality means privacy, regulatory, customer, configuration, intellectual-property, and proprietary information crosses only trusted boundaries and remains auditable.
Tenant choice changes isolation and cost but does not remove the need for identity controls, classification, masking, encryption, logging, and backup governance. Support convenience must be designed around customer-data risk.
Topic summary
Protect confidential data across tenant models with identity, isolation, classification, opacity, encryption, and auditable handling.
8. Eliminate standing access to confidential data
Only identities with a justified task should receive confidential access, only to the necessary scope, and only for the required time. Training and trust do not replace technical controls. Approval, time-bound activation, separation of duties, periodic review, and complete logging reduce both malicious and accidental misuse.
A support employee copied and published a donor list while the entire team had permanent access. Contoso Rise Up reorganizes groups in , applies role-based access control (RBAC), requires approval, time-limits every data session, and records activity. A customer-service representative resolving a customer problem is the knowledge-check role with a valid need; marketing, sales, or finance access must be separately justified.
Need-to-know, just-in-time access replaces broad standing permission.
Topic summary
Use least privilege, approval, time limits, RBAC, access reviews, and logs so trusted users never receive indefinite broad access.
9. Classify, label, reorganize, and mask data
Inventory data by owner, usage, sensitivity, regulation, intellectual property, configuration value, and consequence of disclosure. Attach metadata to stores, columns, storage accounts, backups, logs, and exports, then map each class to approved locations, access, retention, masking, encryption, monitoring, and incident handling.
The SaaS holds its own customer list, customer-owned donor lists, donor addresses, stock images, and templates. A broad uniform control left sensitive records in a lower-security database and harmless assets in a higher-security one. Reorganizing data aligns protection and cost; masking key fields lets authorized users see only what their task needs. Classification is continuous as data, use, and regulation change—not a one-time exercise.
Topic summary
Continuous classification rightsizes controls, prevents sensitive data from drifting into weak locations, and drives masking throughout logs and backups.
10. Encrypt data throughout its lifecycle
Protect sensitive data at rest, in transit, and where supported during processing. Include configuration and secrets because they can unlock deeper access. Select algorithms, protocols, key ownership, rotation, separation, revocation, backup, and recovery from the classification and threat model. Encryption only works if keys remain separately protected and available to authorized recovery.
The SaaS has point-in-time restore and daily consistent PostgreSQL backups in a separate storage account with limited access. A recovery drill accidentally copied one backup to a network share. The new rule encrypts all backups at rest with Azure Service Encryption and protects keys in ; the runbook defines safe decryption. In the source knowledge check, Service Encryption is the control that encrypts storage-account data— protects keys rather than encrypting the account itself.
Encryption follows the data, while independent key governance keeps copied ciphertext unusable.
Topic summary
Base encryption and key governance on classification, cover every data state and backup copy, and test authorized decryption during recovery.
11. Protect integrity in the Contoso Paint Systems platform
A fictional manufacturer connects industrial paint-booth sensors and ventilation controls to a cloud application. On-premises components run on Azure Stack HCI and custom IoT devices; environmental reports depend on trustworthy measurements. Integrity requires code, firmware, data, workflows, operating systems, processes, devices, and infrastructure to remain authentic and unaltered from creation through use.
Compromise in one layer can falsify regulatory reports, expose data, or create an outage. The production design therefore needs supply-chain assurance, cryptographic trust, and immutable recoverable evidence.
Topic summary
Treat integrity as end-to-end trust in software, firmware, devices, data, infrastructure, workflows, and reports.
12. Defend the software and firmware supply chain
Know where tools, source, libraries, containers, packages, firmware, and build outputs originate. Protect repositories and build agents, pin and verify dependencies, maintain a software inventory, sign artifacts, scan during build and runtime, and prevent a risky release until findings meet the defined severity policy.
The engineering team uses open-source components without having secured its build system. It adds common vulnerabilities and exposures (CVE) and malware scanning across dependencies, packages, code, firmware, and back-end builds. It evaluates anti-malware controls for Azure Stack HCI, including Windows Defender Application Control. Scanning can detect vulnerabilities; it cannot guarantee vulnerability-free code or prevent every exploit.
Supply-chain controls establish provenance and stop unacceptable artifacts before production.
Topic summary
Secure repositories and builders, verify provenance, scan code and dependencies, sign outputs, and treat scanning as detection rather than a guarantee.
13. Establish cryptographic trust in devices and code
Encryption, certificates, digital signatures, hashes, and code signing provide different guarantees. Encryption preserves secrecy, a signature demonstrates origin and detects alteration, and a cryptographic hash supports comparison. Algorithms, key sizes, certificate chains, revocation, rotation, secure boot, and hardware capability must satisfy current organizational standards.
The original sensors cannot support HTTPS or custom encryption, and network segmentation alone cannot protect unencrypted traffic. The manufacturer selects more capable devices that use certificate-based communication and verify signed firmware before execution. Code signing plus encryption is the correct cryptographic-control pair in the source assessment.
Topic summary
Do not substitute network isolation for cryptography; select devices that can authenticate peers, encrypt traffic, and verify signed firmware.
14. Make backups confidential, immutable, and verifiable
A trusted backup must remain encrypted, access-controlled, restorable, and protected against modification or deletion while stored, moved, or copied. Separate backup administration from production, monitor access, retain independent copies, and rehearse recovery. Immutability protects an accepted object; a hash verifies whether content differs from the expected value.
Contoso keeps periodic emissions reports in Azure . It encrypts the report, stores it in with write-once, read-many (WORM) immutability, and compares a Secure Hash Algorithm (SHA) digest with the source. Moving to archive or retaining a VM disk would not make the report immutable; the WORM policy is the decisive control.
Combine encryption, WORM immutability, independent access control, integrity verification, monitoring, and restore drills for trustworthy backups.
15. Protect availability in the Contoso Concierge platform
A fictional hotel platform serves more than 50 brands from two US regions and mostly runs on . Availability security keeps bookings, check-ins, guest services, and housekeeping reachable during attack while ensuring authorized access and trustworthy data. Controls must block hostile traffic without creating unnecessary friction for legitimate staff.
A vulnerable update lets attackers generate huge fake folio requests that exhaust memory in one region. Retrying users spread the load across servers. The lesson is not merely to add instances; security architecture must reduce malicious work and contain its blast radius.
Topic summary
Protect availability by preventing hostile inputs and attack paths from consuming shared capacity or propagating across the workload.
16. Contain expensive data operations with the Valet Key pattern
Instead of proxying every storage transfer through application servers, a trusted service can issue a short-lived, tightly scoped token for direct resource access. The Valet Key pattern limits resource, operation, and duration, offloads memory and bandwidth, and creates an auditable authorization point. Token delivery, leakage, revocation, quotas, and request validation still require controls.
The hotel application stops handling folio data directly, issues restricted access, and validates or sanitizes untrusted input before processing. The pattern would not eliminate every attack, but it reduces the blast radius and keeps one oversized object from exhausting all application servers.
Granular direct access and edge filtering remove malicious work before it consumes application capacity.
Topic summary
Use a short-lived, least-privilege valet token plus input validation to isolate data transfer and contain resource-exhaustion attacks.
17. Proactively reduce attack vectors
Reduce exposed paths through secure coding, dependency and image scanning, timely patches, hardened configuration, endpoint protection, network segmentation, strong identity, secret management, and web filtering. Layer controls so a missed vulnerability does not become an outage.
The Ubuntu VMs from Azure Marketplace install certificates, tune SSH, and load code but initially lack anti-malware. fronts the site without its (WAF). The team enrolls the VMs in enterprise anti-malware and enables and tunes WAF rules to block traffic such as SQL injection. Anti-malware is the preventative measure in the source question; resource monitoring, autoscale, and Traffic Manager do not remove the attack vector.
Topic summary
Harden and patch every layer, protect endpoints, and tune WAF so common malicious traffic is rejected before reaching application capacity.
18. Give recovery the same security posture as production
Recovery systems, identities, networks, automation, keys, backups, and temporary cutover stages need controls at least as strong as the main environment. A neglected copy can carry malware, be altered, expose secrets, or be impossible to decrypt; a recovery sequence can also open a temporary protection gap.
The active-active hotel platform sends backups to a third region, but a drill finds all copies infected in a weakly monitored store. The team strengthens identity and network protection, makes backups tamper-resistant, scans and validates them, and changes the recovery order so the application is never exposed without WAF. The statement that a recovery environment may relax security is false.
Topic summary
Secure, scan, isolate, monitor, and rehearse the recovery environment and every transition with production-equivalent controls.
19. Sustain the Contoso rally analytics security posture
A fictional motorsport data platform receives track, weather, vehicle, and driver telemetry after races and processes it with Apache Spark in . Elite racing teams consider these datasets highly valuable, so they expect the provider to keep controls effective as threats, dependencies, packages, and operating practices change.
Security posture is a continuous capability: assess controls, enforce policy, study incidents, test defenses, update assets, and reduce human error through automation. Passing a launch review does not prove future protection.
Topic summary
Continuously reassess valuable assets, changing attack paths, dependencies, evidence, and control effectiveness.
20. Use threat modeling to find attack paths and gaps
Decompose the workload into flows, components, identities, trust boundaries, data stores, and dependencies. Apply an industry methodology to identify and classify threats, map attack paths, rate likelihood and impact, assign mitigations, and track residual risk. Repeat the model when architecture, data, or adversaries change.
The rally team brings in a specialist and discovers insider-leak opportunities in a data-cleanup task after Spark jobs and an obsolete race-team system that still accesses sensitive data. It schedules code fixes and retires the old system. Threat modeling—not health modeling, intrusion prevention, or failure mode analysis—is the exercise that exposes these security-control gaps.
Threat modeling turns architectural evidence into prioritized security work.
Topic summary
Model threats across every trust boundary, rank attack paths, assign mitigations, and revisit the model after meaningful change.
21. Test controls with independent expertise
Automated scans, code review, attack simulation, penetration tests, and control validation answer different questions. Embed scanners in deployment to block unacceptable findings early, but use qualified independent specialists for rigorous periodic testing. Define authorization, scope, safety, data handling, remediation, and retest in a statement of work.
A Microsoft partner performs quarterly penetration tests and an annual white-box assessment, while consultants help install anti-malware on developer devices and self-hosted build agents. The workload team should not perform all testing itself; independence and specialist skills improve assurance.
Topic summary
Combine continuous automated checks with authorized independent penetration testing, remediation tracking, and retesting.
22. Stay current through SDL, patching, and automation
Maintain an asset and dependency inventory, apply supported security updates, review audit reports and benchmarks, monitor emerging threats, automate repetitive controls, and periodically compare the lifecycle with Security Development Lifecycle (SDL) practices. Platform as a service and software as a service reduce responsibility for underlying infrastructure, but the team still owns code, data, identities, configuration, and packages.
Developers excluded Apache Spark jobs and their Python and R packages from regular updates. The new standard includes every technology in the normal patch schedule. That omission—not a lack of job-success monitoring—is the risk described in the knowledge check.
Security remains effective only when evidence and controls evolve with the workload and threat landscape.
Topic summary
Include every asset and package in inventory and patching, automate evidence, and revisit SDL controls as the threat landscape changes.
23. Review the complete security architecture decision
Use Zero Trust and the CIA triad to define the workload security outcome.
Plan ownership, segmentation, incident response, secure development, and required investment.
Protect confidentiality with least privilege, classification, masking, encryption, key governance, and audit.
Protect integrity with provenance, scanning, signatures, certificates, WORM storage, hashes, and trustworthy recovery.
Protect availability with input validation, Valet Key, endpoint protection, WAF, and secure backup environments.
Sustain posture through threat modeling, independent testing, SDL reviews, updates, and automation.
For AZ-305, connect every control to the asset, threat, trust boundary, business impact, owner, evidence, and failure behavior it addresses. A control name alone is not an architecture decision.
