Human identity
A fictional user account representing a person who signs in through an approved authentication and authorization process.
High School IntermediateModule I13Lesson 2 of 8
I13.2 Cloud Identities, Roles, and Least Privilege
Learn how defenders review fictional cloud users, service identities, groups, roles, policies, federation, sessions, privilege paths, temporary access, emergency accounts, lifecycle, access reviews, and least-privilege evidence without touching any real cloud tenant.
Lesson Progress
Cloud Identities, Roles, and Least Privilege
High School Intermediate • I13: Cloud Security Basics • Lesson 2 of 8
25% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Role Name Does Not Reveal the Full Privilege Path
The fictional Northbridge export automation role appears simple, but its effective access comes from a direct role, storage resource policy, workload identity, project guardrail, private-service condition, and application configuration. A completed migration left one extra storage collection in scope. The assignment supports a least-privilege gap, but it does not prove the service used that access or that any data was disclosed.
Weak analysis
Read the role name, count every listed permission as used, blame the identity owner, and remove access without checking dependencies or rollback.
Professional analysis
Map effective access, business need, ownership, lifecycle, session conditions, application dependencies, alternatives, evidence limits, and a staged validation plan.
Objective 1
Explain the difference between fictional human users, groups, service identities, application identities, federated identities, roles, policies, sessions, and temporary access.
Objective 2
Evaluate fictional effective permissions by comparing assigned roles, inherited access, resource policies, service controls, session conditions, and business need.
Objective 3
Apply least privilege, separation of duties, just-in-time access, approval, review, lifecycle, and break-glass concepts without accessing any real cloud account.
Objective 4
Separate direct observations from supported findings, alternatives, confidence, limitations, impact boundaries, and missing evidence.
Objective 5
Create a portfolio-safe fictional cloud identity-and-access review with identity maps, role analysis, findings, remediation, validation, monitoring, and owner decisions.
Why This Matters
Cloud Access Can Expand through Layers That No Single Team Sees
Fictional cloud access may come from direct role assignment, nested group membership, resource policy, service controls, federation, delegated role assumptions, explicit denies, session conditions, and application authorization. A narrow role can become powerful through chaining. A broad role may be reduced by guardrails. A periodic access review must therefore evaluate effective access, business need, ownership, lifecycle, monitoring, and practical dependencies together.
Core Concept
Use the Identity–Task–Access–Lifecycle Model
Identity
Which fictional person, workload, service, partner, administrator, or emergency account is involved, and who owns it?
Task
Which fictional business action must the identity perform, on which resource, under which conditions, and for how long?
Access
Which fictional roles, groups, resource policies, guardrails, denies, sessions, and application rules create effective permission?
Lifecycle
How is the fictional identity created, approved, reviewed, changed, suspended, expired, monitored, and removed?
Key Vocabulary
Cloud Identity and Privilege Terms
Service identity
A fictional nonhuman identity used by an application, automation, workload, function, or managed service.
Federated identity
A fictional identity authenticated by one trusted system and accepted by another through an approved trust relationship.
Role
A fictional collection of permissions assigned to users, groups, service identities, or sessions.
Policy
A fictional rule document or control describing which actions are allowed or denied on which resources under which conditions.
Effective permission
The fictional access that results after assigned roles, inheritance, resource policies, service controls, explicit denies, and session conditions are combined.
Least privilege
Granting only the fictional permissions needed for the approved task, for the shortest practical time, on the smallest practical scope.
Separation of duties
Dividing fictional approval, execution, review, and evidence responsibilities so one identity cannot complete every sensitive step alone.
Privileged identity
A fictional identity with powerful administrative, security, billing, identity, network, data, or recovery permissions.
Temporary access
Fictional access granted for a limited task and time with approval, expiration, monitoring, and review.
Just-in-time access
Fictional privileged access activated only when needed through an approved request and removed automatically after expiration.
Standing privilege
Fictional powerful access that remains continuously available rather than being activated only for a specific need.
Break-glass identity
A fictional emergency identity protected, monitored, rarely used, independently reviewed, and tested under strict procedures.
Identity lifecycle
The fictional process for creating, changing, reviewing, suspending, and removing identities and access as roles or business needs change.
Access review
A fictional periodic or event-driven review confirming whether identities, roles, permissions, and exceptions remain necessary and correctly owned.
Privilege path
A fictional sequence of memberships, roles, trust relationships, sessions, or delegated permissions that results in sensitive access.
Identity Types
Six Fictional Identity Patterns and Their Risks
Human user
Purpose
Supports fictional interactive work by an approved person.
Strong controls
Federated sign-in, strong authentication, lifecycle ownership, role-based access, session monitoring, and periodic review.
Common gap
Access remains after job change, group inheritance expands scope, or one person holds approval and execution duties.
Review evidence
Directory record, group membership, role assignment, sign-in audit, access review, manager approval, and lifecycle event.
Service identity
Purpose
Supports fictional application, function, job, automation, integration, or managed-service activity.
Strong controls
Single workload purpose, minimal role, protected credential or managed identity, rotation concept, monitoring, and owner review.
Common gap
Shared use, unknown owner, broad storage or database access, no expiration, stale credential, or missing workload mapping.
Review evidence
Workload configuration, identity assignment, role policy, invocation record, secret reference, deployment, and owner record.
Federated identity
Purpose
Allows a fictional external identity provider to authenticate users or workloads into the cloud tenant.
Strong controls
Approved trust, audience and issuer validation, role mapping, lifecycle synchronization, conditional access, and trust monitoring.
Common gap
Overbroad role mapping, stale partner access, unreviewed claim rules, or unclear offboarding ownership.
Review evidence
Federation configuration, claim mapping, partner agreement, sign-in audit, role session, lifecycle sync, and trust review.
Privileged administrator
Purpose
Performs fictional high-impact identity, security, network, data, billing, or recovery administration.
Strong controls
Separate admin identity, approval, just-in-time activation, strong authentication, session logging, peer review, and emergency process.
Common gap
Standing privilege, daily-use admin account, broad scope, shared credential, no approval, or incomplete monitoring.
Review evidence
Privileged role, activation request, approval, session record, administrative event, reviewer signoff, and expiration.
Break-glass identity
Purpose
Provides fictional emergency access when normal identity systems or approval paths are unavailable.
Strong controls
Very limited quantity, isolated protection, strong monitoring, tested access, documented owner, and independent post-use review.
Common gap
Never tested, unmonitored, used for convenience, weakly protected, or missing ownership.
Review evidence
Emergency procedure, custody record, test event, alert configuration, post-use review, and owner approval.
External partner identity
Purpose
Supports fictional vendor, contractor, school, customer, or partner access to approved resources.
Strong controls
Sponsor, expiration, limited role, contractual purpose, need-to-know scope, monitoring, and periodic recertification.
Common gap
No sponsor, long expiration, broad group membership, missing offboarding, or access beyond the partner task.
Review evidence
Sponsor approval, agreement, identity record, role assignment, sign-in audit, expiration, and access review.
Effective Access
Eight Permission Layers to Review
Direct role assignment
Which fictional role is assigned directly to the identity at the tenant, account, project, or resource level?
Analysis risk
A broad role may apply farther than the owner realizes.
Evidence needed
Role assignment record, scope, conditions, owner, approval, and expiration.
Group or team inheritance
Which fictional access is inherited through groups, teams, nested membership, or organizational units?
Analysis risk
Nested membership may create hidden privilege paths.
Evidence needed
Group graph, membership source, lifecycle owner, role mapping, and review record.
Resource policy
Does the fictional storage, database, key, queue, function, or service define additional access?
Analysis risk
Resource policies may grant access even when the identity role appears narrow.
Evidence needed
Resource policy, principal, action, resource, condition, source, and owner.
Service control or guardrail
Do fictional tenant, organization, project, or provider controls limit otherwise allowed actions?
Analysis risk
A role policy alone may overstate effective access when a higher-level deny exists.
Evidence needed
Guardrail policy, inheritance, explicit deny, exception, test result, and control owner.
Session condition
Do fictional source, device, network, authentication, time, tag, approval, or session-duration conditions restrict access?
Analysis risk
Static role review may miss temporary or contextual restrictions.
Evidence needed
Session record, condition evaluation, device context, network path, approval, and expiration.
Delegation or role chaining
Can the fictional identity assume another role or delegate access to a service or partner?
Analysis risk
A narrow starting role may lead to a powerful downstream role.
Evidence needed
Trust policy, assume-role event, chain, session name, target role, conditions, and owner.
Explicit deny
Which fictional deny rules override an apparent allow?
Analysis risk
Ignoring explicit denies can exaggerate practical access.
Evidence needed
Deny statement, scope, condition, inherited source, evaluation result, and exception.
Application authorization
Does the fictional application add its own permissions after cloud authentication succeeds?
Analysis risk
Cloud role and application role may combine to create or reduce access.
Evidence needed
Application role, tenant mapping, business rule, session, object access, and audit record.
Least-Privilege Worksheet
Eight Fields for a Reviewable Access Decision
Business task
Purpose
Defines the exact fictional job the identity must complete.
Fictional example
Read approved course content and write generated export packages.
Quality standard
Specific enough to compare with each permission.
Required actions
Purpose
Lists the fictional operations needed for the task.
Fictional example
List approved content, read selected objects, and write to the export collection.
Quality standard
Avoids broad manage or administrator actions when narrower actions work.
Required resources
Purpose
Limits fictional access to the smallest practical resource scope.
Fictional example
One approved content collection and one export collection.
Quality standard
Excludes unrelated collections, accounts, projects, and regions.
Conditions
Purpose
Restricts fictional access by source, service, network, tag, device, approval, time, or session.
Fictional example
Only from the export function's approved workload identity and private service path.
Quality standard
Conditions are testable and do not silently break the workflow.
Duration
Purpose
Defines how long fictional access remains active.
Fictional example
Continuous minimal service role or two-hour approved administrator session.
Quality standard
Temporary access expires automatically when possible.
Owner and approver
Purpose
Identifies who owns the fictional identity, role, resource, and final decision.
Fictional example
Operations owns the function; Identity Governance approves the role; Content Owner approves collection access.
Quality standard
Approval and execution duties are separated for sensitive access.
Monitoring and review
Purpose
Defines fictional logs, alerts, reviews, and evidence used to confirm appropriate use.
Fictional example
Invocation audit, storage access events, role-change alert, and quarterly recertification.
Quality standard
Coverage, retention, ownership, and source health are verified.
Removal and validation
Purpose
Explains how fictional excess access is removed and the approved workflow is tested.
Fictional example
Remove archive-secondary read access, run staged export validation, monitor errors, and preserve rollback.
Quality standard
The change is reversible, reviewed, and supported by completion evidence.
Access Review
Northbridge Fictional Identity Review Records
NLC-IAM-01
export-automation-role
Service identity roleHighOwner
Learning Operations Team
Assigned access
Read approved-content and archive-secondary; write export-packages
Business need
Read approved-content; write export-packages
Finding
Read access to archive-secondary exceeds the documented workflow.
Limitation
No supplied evidence supports misuse.
NLC-IAM-02
content-admin-group
Human administrator groupHighOwner
Content Platform Owner
Assigned access
Manage course content, storage policy, and retention settings
Business need
Content editors need object management; policy and retention changes require separate approval
Finding
One group combines daily content work with sensitive policy administration.
Limitation
Effective access must include application and resource-policy correlation.
NLC-IAM-03
migration-partner-role
Federated partner roleHighOwner
Migration Program Sponsor
Assigned access
Read source collections and write staging packages
Business need
Migration completed forty-five fictional days ago
Finding
The partner role and trust remain active without a current business need.
Limitation
No post-migration sign-in or data access is supported by the supplied records.
NLC-IAM-04
cloud-security-admin
Privileged administratorMedium-HighOwner
Cloud Security Operations
Assigned access
Standing tenant-wide security administration
Business need
Periodic policy review and incident response
Finding
Standing privilege can be reduced to approved just-in-time activation.
Limitation
Emergency response timing requirements require owner validation.
NLC-IAM-05
backup-restore-service
Service identityHighOwner
Continuity and Recovery Team
Assigned access
Read backups and restore to approved recovery targets
Business need
Continuous backup verification and approved restore tests
Finding
The assigned role matches the documented task and resource scope.
Limitation
Key access and network conditions require separate confirmation.
NLC-IAM-06
learning-support-user
Human support userHighOwner
Learning Support Manager
Assigned access
View support cases and limited application status
Business need
Troubleshoot user-reported access and course-progress issues
Finding
The role appears aligned with current duties and excludes direct database access.
Limitation
Application-level permissions must remain included in future reviews.
NLC-IAM-07
emergency-admin-01
Break-glass identityHighOwner
Identity Governance Lead
Assigned access
Emergency tenant administration
Business need
Use only when normal federation and privileged activation are unavailable
Finding
Ownership and alerting exist, but the last access test is overdue.
Limitation
Protection strength cannot be inferred beyond supplied custody and monitoring records.
NLC-IAM-08
analytics-reader-group
Human analyst groupHighOwner
Learning Data Owner
Assigned access
Read aggregated progress dataset
Business need
Read de-identified reporting views
Finding
Group membership includes one user whose fictional role changed to content operations.
Limitation
No evidence supports access after the role change.
Defensive Workflow
Complete a Fictional Cloud Identity Review
Confirm the fictional access question
Restate the approved identities, resources, business tasks, owners, time window, evidence sources, privacy limits, and prohibited real-account actions.
Output: Identity-review objective and scope.
Build the identity inventory
Record fictional human, service, federated, partner, privileged, and emergency identities with owners, sponsors, lifecycle state, and business purpose.
Output: Cloud identity register.
Map assigned and effective access
Compare fictional direct roles, group inheritance, resource policies, guardrails, explicit denies, session conditions, delegation, and application authorization.
Output: Effective-permission and privilege-path map.
Compare with least privilege
Match fictional actions, resources, conditions, duration, owners, approvals, monitoring, and removal rules to the documented business task.
Output: Least-privilege gap register.
Test alternatives and impact
Consider fictional migration, emergency, backup, integration, support, ownership, and compensating-control explanations without assuming misuse.
Output: Alternative explanations and bounded findings.
Design safe remediation
Assign fictional owners, approvals, staged changes, expiration, validation, rollback, monitoring, communication, and completion evidence.
Output: Identity-remediation action plan.
Review lifecycle and recurrence
Confirm fictional joiner, mover, leaver, partner expiration, service-owner review, privileged activation, emergency testing, and periodic recertification.
Output: Identity-governance and review schedule.
Report and close
Document fictional observations, findings, alternatives, confidence, limitations, residual risk, reviewer approval, and portfolio-safe communication.
Output: Reviewed cloud IAM package.
Fake Dashboard
Fake Northbridge Cloud Identity Dashboard
Training dashboard for fictional IAM evidence only.
Identities reviewed
8
Human, service, partner, privileged, emergency, support, analytics, and recovery identities are mapped.
Least-privilege gaps
5
Broad role, combined duties, stale partner trust, standing privilege, and stale group membership require action.
Supported misuse events
0
The supplied fictional evidence supports governance gaps but no confirmed misuse.
Fake SOC Alert
Completed Migration Left a Broad Service Role Active
Source: Fake Cloud IAM Review Console • Time: 10:32 AM
The fictional export automation role can read archive-secondary even though the current business workflow requires only approved-content and export-packages.
Defensive recommendation: Confirm effective access across direct roles, resource policies, guardrails, conditions, and application configuration. Preserve the migration explanation, verify owner and dependency needs, avoid claiming misuse, stage the permission reduction, validate the export workflow, retain rollback, monitor access and failures, and document completion.
Fake Log Panel
Fake Northbridge IAM Review Records
training-log-viewer.log
09:00 REVIEW scope='cloud identities and roles' tenant='NLC' 09:08 IDENTITY count='8' owners='mapped' 09:14 ROLE export-automation='approved-content,archive-secondary,export-packages' 09:18 REQUIREMENT export-automation='approved-content,export-packages' 09:24 HISTORY archive-secondary='migration access' project='closed' 09:31 PARTNER migration-role='active' sponsor='expired' 09:37 ADMIN cloud-security='standing privilege' activation='available' 09:43 BREAKGLASS owner='assigned' alerting='enabled' test='overdue' 09:49 GROUP analytics-reader='stale member detected' 09:55 SUPPORT role='aligned' database_access='none' 10:02 FINDING overpermission='supported' misuse='not supported' 10:10 ACTION stage='permission reduction' rollback='preserved' 10:18 VALIDATION export_test='required' monitoring='enabled' 10:25 REVIEW lifecycle='joiner,mover,leaver,partner,service' 10:32 PORTFOLIO fictionalization='required'
Training note: this is fake data for defensive analysis practice only.
Findings Matrix
Northbridge IAM Findings and Limits
NLC-IAM-F01
The fictional export automation role has read access to one storage collection beyond its documented business requirement.
HighEvidence support
Role assignment, effective-access record, business workflow, storage scope, application configuration, and migration history.
Alternative
A continuing migration dependency is possible but not supported by current owner records.
Limitation
No evidence supports misuse, data access, or external disclosure.
NLC-IAM-F02
The content-admin group combines routine content work with sensitive storage-policy and retention administration.
HighEvidence support
Group membership, role mapping, application duties, storage policy permissions, and change history.
Alternative
A small-team staffing model may explain the design but does not remove separation-of-duties risk.
Limitation
Actual use of the sensitive actions is not established by assignment alone.
NLC-IAM-F03
The migration partner role and federation trust are stale because the project ended and no current sponsor approval is supplied.
HighEvidence support
Project closure, role assignment, federation configuration, sponsor record, expiration field, and access review.
Alternative
A delayed post-migration validation task is possible but undocumented.
Limitation
No post-project sign-in or resource access is supported by the supplied logs.
NLC-IAM-F04
The cloud-security administrator can reduce standing privilege through approved just-in-time activation.
Medium-HighEvidence support
Privilege scope, task frequency, activation capability, incident workflow, session logging, and owner review.
Alternative
Continuous access may be required for specific emergency duties, but that need requires documented validation.
Limitation
Availability and response-time requirements must be tested before implementation.
NLC-IAM-F05
The emergency administrator has ownership and monitoring but requires an overdue controlled access test.
HighEvidence support
Emergency procedure, identity owner, alert configuration, custody record, and test schedule.
Alternative
A recent undocumented test is possible but no evidence is supplied.
Limitation
The lesson does not test or use any real emergency identity.
NLC-IAM-F06
The analytics-reader group contains one stale member after a fictional job change.
HighEvidence support
HR role-change record, group membership, data-owner requirement, lifecycle synchronization, and access review.
Alternative
Temporary dual-role access is possible but no approved exception is supplied.
Limitation
No post-change data access is supported by the supplied evidence.
Analyze the Evidence
What Does the Broad Export Role Actually Prove?
The fictional role can read approved-content and archive-secondary and can write export-packages.
The current export workflow requires approved-content read and export-packages write.
Archive-secondary access was added during a completed migration.
No current exception or sponsor approval supports continued archive-secondary access.
The supplied audit records do not show post-migration reads from archive-secondary.
A staged permission reduction and export validation are available.
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Cloud IAM Analysis
Reviewing only direct fictional role assignments and ignoring groups, resource policies, guardrails, delegation, explicit denies, session conditions, and application permissions.
Treating a broad role as proof that the identity used every permission.
Treating a service identity as proof of a specific human actor or intent.
Assuming all managed identities, temporary credentials, or federated sessions are automatically least privilege.
Leaving temporary migration, partner, incident, or project access active after the business need ends.
Using one shared fictional service identity for several unrelated workloads without clear ownership or evidence.
Assigning daily-use and privileged administration to the same human account when separation is practical.
Keeping standing privilege because just-in-time access requires additional design or testing.
Creating a break-glass identity without independent ownership, protection, monitoring, testing, and post-use review.
Removing access without validating service dependencies, rollback, monitoring, and owner approval.
Failing to document who owns the identity, role, resource, approval, review, and final risk decision.
Treating absence of sign-in records as proof of no activity without verifying source health, retention, and event coverage.
Ignoring role changes, departures, sponsor loss, application retirement, and service-owner changes.
Using or exposing any real cloud account, identity, role, policy, session, credential, tenant, storage, database, log, owner, or private record.
Safe Practice Lab
Build the Northbridge Cloud Identity and Least-Privilege Review
Your fictional assignment
Identity Inventory, Effective Access, Findings, and Remediation
Use only the supplied fictional Northbridge records to complete an end-to-end cloud identity review.
Required deliverables
- Identity register with type, owner, sponsor, lifecycle state, and business purpose.
- Assigned-role, group, resource-policy, guardrail, deny, session, delegation, and application map.
- Effective-permission and privilege-path diagram.
- Least-privilege worksheet for all eight fictional identities.
- Findings with alternatives, confidence, limitations, and impact boundaries.
- Staged remediation with approval, expiration, validation, rollback, monitoring, and completion evidence.
- Joiner, mover, leaver, partner, service-identity, privileged, and break-glass review schedule.
- Technical summary, leadership summary, and portfolio-safety statement.
Do not access or modify any real identity system or cloud tenant. Complete the lab only with fictional records displayed in this lesson.
Scenario Decision Lab
A Broad Service Role Has No Supported Misuse
The fictional export automation role exceeds the documented business need, but the supplied records do not show post-migration access to the extra collection.
Scenario Decision Lab
A Privileged Administrator Has Standing Access
The fictional cloud-security administrator performs occasional policy reviews and incident response, and the platform supports approved temporary activation.
Defender Habits
Cloud Identities, Roles, and Least-Privilege Checklist
Check Your Understanding
I13.2 Mini Quiz: Cloud Identities, Roles, and Least Privilege
Choose your answers first. Explanations appear only after submission.
1. What is a fictional effective permission?
2. Which statement about a broad fictional service role is strongest?
3. What is separation of duties?
4. What is the purpose of just-in-time fictional access?
5. What should happen to a fictional partner role after the project ends?
6. Which control is most important for a fictional break-glass identity?
7. What makes a fictional cloud IAM finding defensible?
Portfolio Prompt
Portfolio Prompt
Create a fictional Cloud Identity, Roles, and Least-Privilege Review for the Northbridge Learning Cloud. Include identity inventory, owner and sponsor map, direct roles, groups, resource policies, guardrails, denies, session conditions, delegation, application permissions, effective access, privilege paths, business need, findings, alternatives, confidence, limitations, remediation, validation, rollback, monitoring, lifecycle reviews, and a portfolio-safety statement.
Use only fictional tenants, identities, roles, groups, policies, sessions, credentials, owners, resources, logs, dates, and decisions.
Do not treat assigned permission as proof of use, misuse, intent, or impact.
Map every access decision to a business task, resource scope, owner, approval, expiration, and evidence source.
Make remediation reversible, validated, monitored, and reviewable.
Key Takeaways
What You Should Remember
1.Cloud access is created by several interacting layers rather than one role name.
2.Least privilege compares effective access with a specific business task, resource scope, condition, duration, and owner.
3.Service identities require the same ownership, review, monitoring, and lifecycle discipline as human identities.
4.Broad access supports a governance finding but does not independently prove misuse or intent.
5.Temporary partner, migration, project, and privileged access should expire or be explicitly renewed.
6.Just-in-time privilege can reduce standing access when emergency and availability requirements are safely validated.
7.Portfolio artifacts should use fully fictional identity evidence and never expose real cloud accounts or credentials.
Navigation