Case Study
Terraform Dependency Topology
IDENTITY-FIRST
ZERO TRUST ARCHITECTURE

For a better view, use the links on the right to open to download a copy.
Architecture Diagram

Code
Snapshot
I redesigned access across a cloud and SaaS environment by making Microsoft Entra ID the central identity foundation for access control, device trust, policy enforcement, and security visibility.
Instead of treating access as a simple login event, the architecture connected identity structure, Conditional Access policies, device compliance, SaaS governance, role assignment standards, and monitoring into one governed dependency model. The image represents that architecture as a Terraform-style dependency topology, showing how providers, modules, policies, and validation layers depend on one another
Business Impact
• Standardized access control across Microsoft 365, Azure resources, managed endpoints, and SaaS
applications.
Reduced risk from unmanaged devices, risky sign-ins, excessive permissions, and inconsistent policy enforcement.
Improved visibility into identity activity, device compliance, SaaS sessions, and policy behavior.
Replaced manual access-policy changes with version-controlled, governed deployment patterns.
Created a more scalable access model by tying policy, identity structure, validation, and monitoring together.
Role and Ownership
I owned the access architecture from design through rollout. My work focused on defining the identity control model, structuring access groups, standardizing role assignments, building Conditional Access policy logic, and connecting device compliance and SaaS governance into the access decision process.
I also moved policy management toward a governed infrastructure-as-code model. That included reusable policy modules, version control, service principal authentication, validation steps, and controlled deployment patterns so changes could be reviewed, tested, deployed, and monitored consistently.
Architecture Summary
The architecture used Microsoft Entra ID as the identity foundation and Conditional Access as the central policy enforcement layer.
The dependency model started with provider and foundation components, including the Entra ID provider, Azure provider, policy module library, version control repository, and service principal authentication. Those foundation components supported identity structure, including identity foundations, dynamic grouping, workforce groups, admin access groups, named locations, and role assignment standards.
Conditional Access policies sat at the center of the model. Baseline access policies, risk-based access controls, session controls, Privileged Access Management, and access reviews all connected into the policy layer. Device compliance policies, compliant device requirements, SaaS session governance, and cloud app controls added device and SaaS context into the access model.
Security visibility was handled through Log Analytics, Sentinel correlation, policy validation, and controlled deployment. That created a feedback loop where policy changes could be deployed, monitored, validated, and improved over time.
Architecture Components
Provider & Foundation
• Entra ID Provider
Azure Provider
Policy Module Library
Version Control Repository
Service Principal Authentication
Identity Structure
• Identity Foundations
Dynamic Grouping
Workforce Groups
Admin Access Groups
Named Locations
Role Assignment Standards
Access Policy
• Baseline Access Policies
Conditional Access Policies
Risk-Based Access Controls
Session Controls
Privileged Access Management
Access Reviews
Device Trust & SaaS Governance
• Device Compliance Policies
Compliant Device Requirements
SaaS Session Governance
Cloud App Controls
Visibility & Operations
• Log Analytics Workspace
Security Visibility
Sentinel Correlation
Policy Validation
Controlled Deployment
Design Approach
The architecture was built around identity-first access, not network trust alone. A user having valid credentials was not enough. Access depended on identity structure, group membership, device compliance, risk context, session controls, and the sensitivity of the application being accessed.
The identity layer provided the foundation. Dynamic grouping separated users into workforce and admin access groups, while named locations and role assignment standards gave Conditional Access policies the context they needed to make consistent decisions.
The access policy layer became the center of the architecture. Conditional Access policies depended on baseline policy standards, risk-based access controls, session controls, privileged access rules, and access review requirements. This made the access model more structured and reduced the chance of inconsistent policy behavior across systems.
Device trust and SaaS governance extended the model beyond identity alone. Device compliance policies and compliant-device requirements helped ensure unmanaged or non-compliant devices could not reach sensitive resources. SaaS session governance and cloud app controls added visibility and control over cloud application usage after authentication.
The operations layer closed the loop. Log Analytics, Sentinel correlation, policy validation, and controlled deployment made it possible to monitor the impact of policy changes, detect issues, validate enforcement, and improve the model without relying on manual one-off changes
Technical Challenges Solved
• Inconsistent access enforcement across cloud, endpoint, and SaaS platforms.
Manual policy changes that were difficult to review, validate, or roll back.
Unmanaged or non-compliant devices reaching business applications.
Overly broad access permissions increasing identity risk.
Limited visibility into how identity, device, and SaaS signals affected access.
Difficulty understanding downstream impact when changing policies, groups, roles, or named locations.
Lack of a governed feedback loop between deployment, monitoring, validation, and policy improvement
Technical Impact
• Established a centralized identity-first access model across users, devices, and applications.
Made Conditional Access the primary enforcement point for identity, device, risk, and session decisions.
Improved least-privilege enforcement through admin access groups, role assignment standards, privileged access controls, and access reviews.
Strengthened device-based access control through compliance policies and compliant-device requirements.
Increased SaaS governance through session controls and cloud app controls.
Centralized access visibility through Log Analytics, security visibility, and Sentinel correlation.
Reduced configuration drift by moving access policies and supporting components into governed deployment patterns.
Created a clearer dependency model for understanding how identity, policy, device trust, SaaS governance, and monitoring components interact.
Technology Stack and Ownership
Identity and Access
Microsoft Entra ID
Conditional Access
Dynamic groups
Named locations
Role assignment standards
Privileged Access Management
Access reviews
Device and SaaS Governance
Device compliance policies
Compliant device requirements
SaaS session governance
Cloud app controls
Monitoring and Operations
Log Analytics Workspace
Microsoft Sentinel
Sentinel correlation
Security visibility
Policy validation
Automation and Deployment Governance
Terraform
Policy module library
Version control repository
Service principal authentication
Controlled deployment