Domain 3 · Identity and Access Management Concepts · Lesson 3 of 5
Give each identity only the access it needs
About 16 minutes · Introductory draft · Checked 2026-10-22
AI editorial review for introductory study; independent review and complete exam alignment remain pending. Read course scope and remaining gaps.
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
What you will learn
- Distinguish identification, authentication, authorization and accounting.
- Apply least privilege and separation of duties.
- Manage human and automated identities through their lifecycle.
Follow a request through access control
Identification states an identity, such as a username. Authentication checks the claimed identity. Authorization decides which action that authenticated identity may perform. Accounting records activity so it can be reviewed. Logging in successfully does not imply permission to open every customer record.
Multi-factor authentication combines different factor types, such as something known and something possessed. Two passwords are still the same factor type. Recovery methods also need protection. A shared administrator account makes individual accountability difficult even if it has a strong password.
Constrain permission and conflicts
Least privilege grants only permissions needed for a task, for only as long as needed. Role-based access associates permissions with job roles. Attribute-based decisions can also consider attributes such as resource classification or device condition. Review the rule that grants access as well as the identity using it.
Separation of duties divides conflicting responsibilities: one person requests a supplier payment and another approves it. Giving a requester an approver role for convenience removes that check. Temporary elevated access should have an owner, a justified purpose, an expiry and a record of use.
Manage joiners, movers, leavers and services
Provision an identity from an approved request. When a person changes jobs, remove obsolete permissions rather than simply adding new ones. Review access periodically with resource owners. When a person leaves, disable access promptly through the agreed process and revoke active sessions and credentials as appropriate.
Automated services and AI agents also need distinct identities, scoped permissions and accountable owners. A reporting bot that reads invoices does not need permission to approve payments. Rotate or revoke its secrets through the approved lifecycle and retire the identity when the service ends.
Work through a scenario
Fictional facts for learning. This exercise is not scored.
A support analyst moves to sales but retains access to password resets. What lifecycle step was missed, and how should the organization respond?
Compare your reasoning
The mover review missed removal of obsolete permissions. Confirm the new role with the manager and resource owner, remove the old reset permission, inspect relevant use if indicated and correct the transfer checklist. Merely adding a sales role increases access rather than enforcing least privilege.
Applied study · Added 2026-10-22
Control the whole identity lifecycle
Continue beyond the introduction. Work through the evidence before opening the model answer.
See it · Try it · Recall it
Picture the topic
Remember this: Join move leave: access must follow the role.
Explore the anchors
Approve and provision necessary access.
Concept matching activity
Match this task or description to its concept:
Remove old rights and grant new ones.
Choose a concept before checking the explanation.
Access-decision sandbox
Try to edit a fictional record as a reader. Then change one condition and evaluate again. This simplified policy requires authentication, object scope and action permission; real policies have more conditions.
Change the request, then evaluate it.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
Visual recap for topic 3.1. Open its full syllabus chapter.
Treat transfers and departures as access changes
An identity lifecycle includes approval, provisioning, review, changes and removal. A transfer may require removing an old role before adding a new one; simply adding access accumulates privilege. Human accounts, service accounts, shared secrets and emergency access all need owners and review. Removing a user from a directory may not revoke an already issued session or an independent application account. Use a checklist tied to actual applications, tokens and devices, then verify the outcome rather than assuming one central switch removed every path.
Distinguish access models and authentication factors
Role-based access groups permissions around job responsibilities. Attribute-based decisions can also consider properties such as resource classification, location or approved project. Least privilege limits access to the task, while separation of duties prevents one person completing incompatible stages alone. Multi-factor authentication combines different factor types; a password and a PIN are both knowledge factors. Strong authentication does not replace authorization, and neither removes the need to review privileged activity. Request only the evidence necessary to verify a role and handle account records as protected information.
Evidence case
Fictional facts for learning; no real organization or person is described.
- A buyer transfers to the supplier-payments team. Their old ability to create suppliers remains active.
- The new role can approve supplier payments. Both roles use the same named account with multi-factor authentication.
Your task
- Identify the conflicting permissions.
- Describe an access change and a verification step.
Compare with the model answer
The user can now create a supplier and approve payment to it, combining incompatible stages. Ask the process owner which old permissions must be removed, apply the approved role change and test that the account cannot complete both actions. Keep the approval and test result as evidence. Multi-factor authentication helps identify the user but does not resolve this separation-of-duties conflict. Review other transferred users for the same role accumulation.
This case has two original scenario questions in the expanded practice bank. Practice this course · Edition, coverage and remaining study
Remember
- Authentication proves a claim; authorization permits an action.
- Access reviews include job changes and automated identities.
- Separate incompatible duties and make exceptions time limited.
Orientation and further reading
Original examples and explanations. Background references do not establish complete exam coverage.