3.2.2. Custom Security Attributes and Bulk Operations
💡 First Principle: Built-in attributes describe people (department, title); custom security attributes describe your security model (project clearance, data-handling tier) — defined once per tenant, permission-gated separately from ordinary directory reads, and usable in filters and (for apps) in Azure attribute-based access control.
Custom security attributes are organized as attribute sets (e.g., Engineering) containing definitions (e.g., ProjectCode, single/multi-value, freeform or allowed-list, string/int/bool). The two properties the exam leans on: they are not readable by default — even Global Administrator must be assigned Attribute Definition/Assignment roles to define or assign them (a deliberate break from "GA sees all") — and they're distinct from the legacy extensionAttributes1-15 (Exchange lineage, less governance). Use cases: sensitive classification you don't want every directory reader to see, and filtering (dynamic-style rules, CA filter for devices/apps in some scenarios, Azure ABAC conditions on storage).
Bulk operations keep large directories consistent. Portal bulk actions ship CSV templates: bulk create users, bulk invite guests, bulk delete, bulk add group members — download template, fill, upload, monitor the results file for row errors. Beyond CSV scale or logic, Microsoft Graph PowerShell is the scripting surface (Connect-MgGraph with scoped consent like User.ReadWrite.All, then New-MgUser, Get-MgUser -Filter, Add-MgGroupMember in loops). The older AzureAD/MSOnline modules are deprecated — modern-answer stems name the Graph SDK. Service-account-driven automation should authenticate as an application (Phase 4's workload identities) rather than as a user.
⚠️ Exam Trap: Global Administrator cannot read or assign custom security attributes without explicitly taking an attribute role. If a stem's admin "can't see the attributes," the fix is assigning Attribute Assignment Administrator/Reader — not adding more directory privilege.
Reflection Question: Why would you store a merger codename on users as a custom security attribute rather than in department or an extension attribute — name both the confidentiality and the governance reason?
