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

###############################################################################
# Module: conditional_access_policy
# Author: Andie Garcia (andie.garcia@garciaplatformgroup.example)
# Owner:  Platform Engineering — Garcia Platform Group LLC
# Repo:   azuredevops/GarciaPlatformGroup/_git/platform-iac
# Purpose:
#   Reusable wrapper around azuread_conditional_access_policy so every
#   Conditional Access policy in the Garcia Platform Group tenant is created
#   from a single, peer-reviewed code path. Replaces manual portal changes for
#   the 600+ user platform.
###############################################################################

terraform {
  required_providers {
    azuread = {
      source  = "hashicorp/azuread"
      version = "~> 2.47"
    }
  }
}

variable "display_name" {
  type        = string
  description = "Display name for the conditional access policy."
}

variable "state" {
  type        = string
  description = "Policy state."
  default     = "enabledForReportingButNotEnforced"

  validation {
    condition     = contains(["enabled", "disabled", "enabledForReportingButNotEnforced"], var.state)
    error_message = "state must be enabled, disabled, or enabledForReportingButNotEnforced."
  }
}

variable "included_users" {
  type    = list(string)
  default = ["All"]
}

variable "excluded_groups" {
  type    = list(string)
  default = []
}

variable "included_applications" {
  type    = list(string)
  default = ["All"]
}

variable "client_app_types" {
  type    = list(string)
  default = ["all"]
}

variable "sign_in_risk_levels" {
  type    = list(string)
  default = []
}

variable "require_mfa" {
  type    = bool
  default = true
}

variable "require_compliant_device" {
  type    = bool
  default = false
}

resource "azuread_conditional_access_policy" "this" {
  display_name = var.display_name
  state        = var.state

  conditions {
    client_app_types    = var.client_app_types
    sign_in_risk_levels = var.sign_in_risk_levels

    applications {
      included_applications = var.included_applications
    }

    users {
      included_users  = var.included_users
      excluded_groups = var.excluded_groups
    }
  }

  grant_controls {
    operator = "AND"

    built_in_controls = compact([
      var.require_mfa              ? "mfa"             : "",
      var.require_compliant_device ? "compliantDevice" : "",
    ])
  }
}

output "policy_id" {
  value       = azuread_conditional_access_policy.this.id
  description = "The ID of the created Conditional Access policy."

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


Summary

This architecture shifted access control from disconnected policy changes to a governed identity-first dependency model. Microsoft Entra ID provided the foundation, Conditional Access became the central enforcement layer, device trust and SaaS controls strengthened access decisions, and Sentinel-backed visibility created a feedback loop for validation and improvement.

The image represents that system as a Terraform dependency topology: provider and foundation components feed identity structure, identity structure supports access policy, access policy depends on device trust and SaaS governance, and the visibility layer validates the entire model through monitoring, correlation, and controlled deployment.