Objective: distinguish identity from permission
After lesson 03, use a retained customer responsibility—access decisions—to explain IAM. Authentication establishes an identity. Authorization determines whether a requested action on a resource is allowed. Passing one decision does not settle the other. A person may sign in successfully yet lack permission to read a particular resource. Conversely, a written description of a permitted task is not itself proof of the caller’s identity. Keep these two questions separate when reading a case, even if the interface displays them in one apparent workflow.
Temporary access and least privilege
AWS recommends federated access with temporary credentials for human users, and IAM roles with temporary credentials for workloads. Least privilege scopes actions to the resources and conditions required for a task. Temporary credentials answer a credential-lifetime concern; permission scope answers a different concern. A temporary administrator identity may still be far too broad. A narrowly scoped identity with an unnecessarily permanent shared secret also fails a different requirement. These are conceptual choices here, not instructions for changing a real account. Documented exceptions exist, so do not claim that long-term credentials are technically impossible.
Worked example: a guest instructor’s permissions
Fictional teaching case: a guest instructor must upload teaching material to one training collection for a limited workshop. The instructor must not read students’ separate responses. An employee reviewer needs to read those responses but must not replace the teaching material. First authenticate each person through the organization’s access process. Next write the action/resource matrix: guest, upload, teaching collection; reviewer, read, response collection. Finally retain the limited workshop duration for the guest’s access arrangement. Federated temporary access can support the visiting instructor, but it must carry the appropriate restricted permissions. The conclusion is two intentionally different scopes, not a shared powerful login. Check it with two negative cases: the guest should not gain response-reading authority merely by signing in, and the reviewer should not acquire upload authority from the guest’s task.
Root and MFA are separate safeguards
The root identity has complete account access and should not be used for everyday tasks. Its credentials require safeguarding. MFA adds an authentication challenge response; it does not choose which training collection someone may read. An organization can therefore need both strong authentication and restricted authorization. Do not replace the action/resource matrix with “MFA enabled.” Similarly, a workload running on EC2 or Lambda can use a role with temporary credentials rather than receiving a shared employee key, while still needing the proper service-action permissions.
Transfer check and check basis
Pause and decide: a background application signs requests with valid temporary role credentials but tries an action outside the role’s permitted resources. Should temporary credentials alone make the action legitimate? Check basis: no. Credential validity and lifetime do not expand the authorized scope. The explanation should identify the requested action/resource and compare it with permission, instead of recommending root access. Now retrieve cards aws-clf-card-10–12 and attempt aws-clf-q-013–016. For each task, explicitly label the authentication, credential-lifetime, and authorization issues that are actually present; do not invent a requirement the scenario did not give.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Security best practices in IAM - AWS Identity and Access ManagementWhat is IAM? - AWS Identity and Access Management