Library patrons treat 'logging in' as the entire AAA model. Which statement correctly separates the AAA functions?

AAA separates three functions: authentication verifies identity, authorization determines what an authenticated subject may do, and accounting records what occurred for audit and accountability. Library patrons who treat "logging in" as the entire AAA model miss that login is primarily authentication (and session establishment), while permission checks and audit trails remain distinct. Correct separation keeps municipal access design coherent across cards, SSO, and applications.

The distractor that swaps meanings—authentication grants permissions, authorization proves identity, accounting encrypts sessions—reverses and invents definitions. Encryption of sessions is a confidentiality/transport control, not accounting. The claim that authorization "only means MFA" and authentication "only means writing audit logs" collapses MFA (an authentication strengthener) and audit logging (accounting support) into the wrong buckets. The idea that accounting replaces authentication whenever SSO is enabled is false: SSO still authenticates, then applications authorize, and systems should still account for access events.

Exam caveat: SY0-701 expects crisp AAA vocabulary. MFA strengthens authentication; RBAC/ABAC express authorization; logs and session records support accounting. Do not let vendor "login" marketing erase the triad.

Operational check: for library and city apps, map identity proofing and MFA to authentication, group and role assignments to authorization, and centralized logging of sign-in and privileged actions to accounting. Test that a valid login without the right role still fails authorization, and that denials and successes both produce accountable records.