Skills Demonstrated
Groups & Teams Setup
Admin Center → Teams & Groups → Active teams & groups
Configured three distinct Microsoft 365 group types — each serving a different organisational purpose. Validated all functionality end-to-end including live email routing tests and member management through the admin portal.
Created to control resource access. Permission-based only, no email address.
Shared email address routing support tickets to all helpdesk members.
Created with linked Teams workspace, SharePoint, and shared mailbox auto-provisioned.
Added and removed members; confirmed Teams sync happened automatically.
Sent test email to distribution list; confirmed delivery in all member inboxes.
Microsoft Teams channel auto-appeared after M365 Group creation.
Evidence — Groups & Teams Screenshots
"IT Team" security group listed under the Security groups tab — created May 26, 2026
Adding David Wilson and Sarah Smith to the IT Department Microsoft 365 Group — Teams status column confirms linkage
Removing Sarah Smith from IT Department — confirms admin can manage team membership via the portal
David Wilson receives "Welcome to the IT Department Group" email — confirms M365 Group and Teams workspace created successfully
David Wilson sends "Test helpdesk request" to the Helpdesk distribution list address — email routing initiated
Sarah Smith (distribution list member) receives the helpdesk email in her inbox — confirms email routing works correctly
Key Takeaway — Groups & Teams
- Three distinct group types serve different purposes: security groups control access, distribution lists route email, M365 Groups do both and auto-create a full collaboration workspace
- Creating an M365 Group with "Create a team" enabled automatically provisions Teams, SharePoint, and a shared mailbox in seconds
- Email routing through distribution lists was verified end-to-end using real accounts across the tenant — sender and receiver both confirmed
Role-Based Access Control (RBAC)
Admin Center → Roles → Role Assignments
Assigned three distinct admin roles to test users and validated each role's permissions by logging in as each user in a separate incognito browser window. This exercise demonstrated the principle of least privilege — a critical concept in IT security and helpdesk operations.
Can reset passwords only. Blocked from licenses, billing, and security settings.
Can create/delete users and assign licenses. Blocked from billing and high-level roles.
Read-only view of all admin settings. Cannot create, edit, or change anything.
Logged into each role in incognito and tested permitted and restricted actions.
Helpdesk Admin successfully reset a user password — core permitted action.
License edit and Mail tab both blocked — confirms RBAC boundaries enforced.
Evidence — RBAC Role Assignments
Helpdesk Admin → John Smith
User Admin → Sanjeel Thomas
Global Reader → David Wilson
Evidence — Role Profile & Permission Testing
John Smith's profile shows "Roles: Helpdesk Administrator" — viewed while logged in as David Wilson (DW) in incognito, confirming Global Reader read-only access
Helpdesk Admin successfully resets John Smith's password — the core permitted action for this role, confirmed via incognito session
"You don't have permissions to edit licenses" — Helpdesk Admin correctly restricted from license management
"You don't have permission to view this information" on Mail tab — demonstrates limited scope of Helpdesk Admin role
Key Takeaway — Role-Based Access Control
- RBAC enforces least privilege — each admin role has precisely scoped permissions, reducing the risk of accidental or malicious changes across the tenant
- Helpdesk Admin can reset passwords but is fully blocked from license management, billing, and mail settings — exactly as intended
- Testing roles via incognito windows is an effective real-world technique to validate permission boundaries without logging out of Global Admin
- Global Reader provides full visibility for auditors or senior staff without any ability to make changes — a safe read-only admin pattern