Stop Managing Users. Start Architecting Communities.

Mid Engineer Asked at: Microsoft, Enterprises, any company using Azure

Q: "A junior admin is manually granting 50 new sales reps access to 10 different resources one by one. It's taking hours and is prone to error. They ask, 'Isn't there a better way?' As the senior engineer, explain the strategic difference between assigned and dynamic groups, and architect a scalable, automated onboarding solution."

Why this matters: This isn't a question about a feature; it's a test of your systems thinking. Can you distinguish between performing a task and engineering a process? Your answer reveals if you think like an admin who reacts to tickets, or an architect who eliminates them.

Interview frequency: Very high. This is a foundational concept in scalable Identity and Access Management (IAM).

❌ The Death Trap

The candidate gives a dry, feature-list definition that explains the "what" but completely misses the profound "why."

"Most people say: 'You should use groups. Assigned groups are where you manually add users. Dynamic groups use a query based on user properties, like their department.' This is correct but strategically useless. It doesn't convey the massive philosophical and operational shift between the two."

🔄 The Reframe

What they're really asking: "Can you articulate the difference between manual, high-touch administration and automated, low-touch governance? Show me you can design a self-managing system where access is a predictable function of identity, not a series of manual, error-prone decisions."

This reveals: Your ability to design for scale, your security mindset (automation eliminates human error), and whether you can connect technical features to business efficiency (faster onboarding, reduced admin cost).

🧠 The Mental Model

Use the "Nightclub Bouncer's Guide to Access Control." It's visceral, simple, and maps perfectly to the technical reality.

1. Individual Users are the Crowd. Managing them one by one is chaos. The bouncer can't remember everyone.

2. An Assigned Group is a Guest List. "Here's a list of 50 names for the sales party." The bouncer has to manually check each ID against the list. It's better than chaos, but still slow, manual, and prone to error (misreading a name, using an old list).

3. A Dynamic Group is a Rule. "Anyone wearing a gold wristband gets into the VIP lounge." The bouncer doesn't need a list. They don't need to know anyone's name. They just enforce a simple, verifiable rule. The system manages itself.

4. Permissions are the Rooms in the Club. Being on the "Guest List" might get you past the front door. Having a "Gold Wristband" might get you into the exclusive rooftop bar.

📖 The War Story

Situation: "At a previous company, we only used assigned groups. The 'guest list' approach. The IT team had a 20-step checklist for onboarding a new developer, which involved adding them to 15 different 'guest lists' for repos, servers, and databases."

Challenge: "Onboarding was a full-day, error-prone process. Worse, offboarding was a nightmare. When a developer left, someone had to manually remove them from all 15 lists. In one instance, a contractor was removed from 14 of the 15 lists, but someone missed the one for the production database."

Stakes: "Three weeks after their contract ended, that contractor's account still had access to live customer data. It was a massive security breach waiting to happen, discovered only by a routine audit. The 'simple' manual process created a huge, invisible risk."

✅ The Answer

My Thinking Process:

"The junior admin's problem isn't about clicking faster. It's a fundamental architectural flaw in their process. My job is to elevate their thinking from 'How do I do this task better?' to 'How do I eliminate this task forever?'"

The Architectural Solution:

"I'd tell them, 'You've stumbled upon the most important problem in identity management. Let's solve it properly.

Level 1 Solution (The Guest List): First, let's stop managing individuals. Create one **Assigned Group** called 'Sales Team.' Grant access for those 10 resources to this single group. Now, onboarding a new sales rep is one action: add them to the 'Sales Team' group. You've just reduced 500 clicks to 50.

Level 2 Solution (The Rule): Now, let's eliminate the task completely. We'll create a **Dynamic Group**, also called 'Sales Team,' with a simple rule: `user.department -eq "Sales"`. Now, when our HR system creates a new user and sets their department attribute to 'Sales,' Entra ID automatically adds them to this group. Onboarding is now zero clicks. More importantly, when someone leaves and their account is disabled or their department changes, they are *automatically removed*. The security hole is sealed instantly.'"

The Outcome:

"We've transformed onboarding from a high-friction, error-prone manual task into a zero-touch, automated workflow. New sales reps are productive on day one, not day two. Admin overhead is drastically reduced. And our security posture is massively improved because access is now tied to a single source of truth—the user's role in the company—not a checklist that humans can forget."

What I Learned:

"The goal of a mature IAM system isn't to manage permissions. It's to build a system where permissions manage themselves. You move from being a gatekeeper to being the architect of the gates."

🎯 The Memorable Hook

"An assigned group is a list of people you trust. A dynamic group is a system that proves why they should be trusted. Good admins manage lists. Great architects build systems of proof."

This reframes the concept from simple organization to a profound statement about trust, automation, and verifiable identity—the core of a zero-trust architecture.

💭 Inevitable Follow-ups

Q: "Dynamic groups require a premium license. How do you justify the cost to the business?"

Be ready: "The cost is an investment in risk reduction and efficiency. Calculate the hours saved in admin time per year. More importantly, quantify the cost of a single security breach from a lingering account. The license doesn't just buy a feature; it buys an automated security control that's always on, which is far cheaper than the cost of one human error."

Q: "What are the limitations of dynamic groups?"

Be ready: "The rules are powerful but not infinitely complex. They depend on having clean, consistent data in user attributes (like `department` or `jobTitle`). This forces good data hygiene, which is a benefit in itself. Also, membership updates aren't instantaneous, so you need to be aware of the processing time."

Q: "How do groups enable other governance features?"

Be ready: "They are the foundation. You can scope an **Access Review** to a group ('Certify the members of the 'Domain Admins' group every 90 days'). You can make a role eligible for **Privileged Identity Management (PIM)** through a group. Groups turn abstract policies into concrete actions on a well-defined set of users."

🔄 Adapt This Framework

If you're junior: Focus on mastering the efficiency gain of assigned groups. Explaining the "guest list" model and how it reduces 500 clicks to 50 is a powerful, concrete demonstration of understanding.

If you're senior: The conversation must be about automation and governance. Frame dynamic groups as a critical component of a 'Joiner-Mover-Leaver' (JML) identity lifecycle strategy, integrated with an HR system as the source of truth.