“It [ACL] specifies a list of users [subjects] who are allowed access to each object” CBK, p. 188
A capability table is incorrect. “Capability tables are used to track, manage and apply controls based on the object and rights, or capabilities of a subject. For example, a table identifies the object, specifies access rights allowed for a subject, and permits access based on the user’s posession of a capability (or ticket) for the object.” CBK, pp. 191-192. The distinction that makes this an incorrect choice is that access is based on posession of a capability by the subject.
To put it another way, as noted in AIO3 on p. 169, “A capabiltiy table is different from an ACL because the subject is bound to the capability table, whereas the object is bound to the ACL.”
An access control matrix is incorrect. The access control matrix is a way of describing the rules for an access control strategy. The matrix lists the users, groups and roles down the left side and the resources and functions across the top. The cells of the matrix can either indicate that access is allowed or indicate the type of access. CBK pp 317 -318.
AIO3, p. 169 describes it as a table if subjects and objects specifying the access rights a certain subject possesses pertaining to specific objects.
In either case, the matrix is a way of analyzing the access control needed by a population of subjects to a population of objects. This access control can be applied using rules, ACL’s, capability tables, etc.
A role-based matrix is incorrect. Again, a matrix of roles vs objects could be used as a tool for thinking about the access control to be applied to a set of objects. The results of the analysis could then be implemented using RBAC.
References:
CBK, Domain 2: Access Control. AIO3, Chapter 4: Access Control