Identification, Authentication, Authorization and Accountability
Every access control system runs the same four steps in the same order, and a large number of exam questions are really asking which step has just failed. Identification is the claim of who you are. Authentication is the proof of that claim. Authorization decides what the proven identity may do. Accountability records what it actually did, so that actions can be traced back to a person afterwards. The order is not negotiable, and each step depends on the one before it, which is why a shared account destroys accountability no matter how strong the authentication was.
Exam tip. If a scenario says a valid user accessed something they should not have, the failure is authorization, not authentication. If it says nobody can tell which administrator made a change, the failure is accountability and the root cause is almost always a shared account.
Authentication Factors, MFA and Biometric Accuracy
Authentication evidence comes in three classic types: something you know, something you have and something you are. Multifactor authentication means combining different types, and that distinction is where most exam traps live, because a password plus a security question is two things you know and therefore only one factor. Biometrics bring their own vocabulary of accuracy, and the exam expects you to know that the two error rates trade against each other, that the crossover between them is the headline quality measure, and which of the two errors is the security problem.
Exam tip. Check that the two factors in an answer come from different categories, because the most common distractor pairs two knowledge factors. For biometrics, remember that the lowest crossover error rate wins a general comparison, but a question about a highly sensitive facility wants the lowest false acceptance rate specifically, even at the cost of rejecting legitimate users more often.
Access Control Models: DAC, MAC, RBAC and ABAC
An access control model is simply the rule that decides who gets in, and the exam distinguishes them by one question: who makes the decision and on what basis. Under discretionary control the data owner decides. Under mandatory control the system decides from labels and no user can override it. Role-based control decides from the job function rather than the person. Attribute-based control evaluates a policy over characteristics of the subject, the object and the context. Scenario questions describe the decision-making, not the name, so learning the decider is what makes them quick.
Exam tip. Read the stem for who is doing the granting. If a user can share a file at their own discretion, it is DAC. If labels and clearances appear and nobody can override the system, it is MAC. If access follows job title and changes automatically when someone transfers, it is RBAC. If the decision depends on device, time or location as well as identity, it is ABAC.
Federated Identity: SAML, OAuth and OIDC
Federation lets one organization trust identities that another organization authenticates, so a user signs in once at their home identity provider and is accepted elsewhere without a second account. The three technologies you must separate are frequently confused because they overlap in practice. SAML is the XML-based standard behind most enterprise web single sign-on. OAuth 2.0 is about delegated authorization, granting an application limited access to resources on your behalf, and it is not an authentication protocol. OpenID Connect is the identity layer built on top of OAuth 2.0 that turns it into one.
Exam tip. OAuth on its own is authorization, never authentication, and treating it as a login mechanism is the single most common error in this area. If a scenario needs to know who the user is, the answer is OpenID Connect or SAML. If it needs an application to reach a user's data at another service without receiving their password, the answer is OAuth.
Kerberos and Single Sign-On Inside the Enterprise
Kerberos is the authentication protocol behind single sign-on in most corporate domains, and the exam tests both the ticket flow and the operational consequences of how it works. It is entirely symmetric: a trusted Key Distribution Center shares a secret with every principal, so the user's password never crosses the network and no service ever sees it. That design produces two well-known weaknesses you should expect to be asked about. The KDC is a single point of failure and a very high value target, and because tickets carry timestamps, clocks across the domain must stay closely synchronized or authentication simply stops working.
Exam tip. Any Kerberos scenario where authentication suddenly fails across the domain should point you at time synchronization first. Remember that Kerberos is symmetric and realm-internal, so it is not the answer to a question about trusting identities across organizational boundaries, which is federation territory.