IM-CCM common mistakes
IM-CCM · Understand the traps and how to avoid them.
Treating authentication, authorization, and identification as interchangeable terms when answering scenario questions, so the candidate picks the option that describes login when the question is actually asking about entitlement enforcement.
The three concepts are used loosely in everyday speech, and exam stems often describe a user 'getting access' without signalling which control layer is being tested.
What to do instead
Before selecting, restate the stem in one sentence and label the control being asked about (proving who you are, deciding what you may do, or asserting an identity attribute). Eliminate options that answer a different layer than the one labelled.
Choosing the strongest-sounding authentication factor (for example, a hardware token) when the scenario's stated risk, usability constraint, or assurance level calls for a different control.
Candidates equate 'most secure' with 'correct' and ignore the requirement language embedded in the stem, such as a shared kiosk, a call centre, or a low-value internal app.
What to do instead
Extract the explicit constraint from the stem (assurance level, population size, device ownership, offline operation) and score each option against that constraint, not against general strength.
Confusing role-based access control with attribute-based access control and picking RBAC for scenarios that describe dynamic, context-dependent decisions such as time of day, device posture, or resource classification.
RBAC is the most familiar model, and many candidates default to it whenever job titles or groups appear in the stem.
What to do instead
Look for a decision input that is not a job function. If access depends on environmental or subject attributes evaluated at request time, choose ABAC or a policy-based model; reserve RBAC for static entitlement sets tied to a role definition.
Answering joiner-mover-leaver questions with a manual review or periodic recertification when the scenario describes a user changing departments and retaining old entitlements.
Candidates conflate detective controls (access reviews) with preventive lifecycle controls and pick the control they studied most recently.
What to do instead
Map the scenario to the lifecycle stage first. A mover problem requires an automated role or entitlement recalculation triggered by the HR event, with recertification as a backstop rather than the primary answer.
Selecting 'revoke all access' or 'disable the account' as the answer to separation-of-duties conflicts when the question asks for the appropriate remediation given business continuity constraints.
Candidates read 'conflict' and jump to the most decisive action, missing language about the user needing to keep performing one of the functions.
What to do instead
Identify whether the conflict is toxic (no legitimate business justification) or mitigable. Where the stem implies the work must continue, choose removal of the conflicting entitlement or a compensating control, not wholesale deprovisioning.
Treating privileged access management as equivalent to standard identity governance, so the candidate applies ordinary access-review cadence and approval workflows to administrative and service accounts.
The tooling and vocabulary overlap heavily, and candidates underweight the distinct controls that apply to elevated accounts.
What to do instead
When the stem mentions administrative, root, service, or shared accounts, screen options for PAM-specific controls: vaulting, session recording, just-in-time elevation, and checkout approval. Reject options that only describe standard recertification.
Recommending standing privileged access with strong authentication instead of just-in-time or brokered elevation when the scenario involves third-party or break-glass access.
Candidates reason that MFA makes standing access safe and overlook the reduced attack surface of time-bound elevation.
What to do instead
Check whether the stem mentions vendors, contractors, or emergency accounts. For those populations, prefer ephemeral or checked-out credentials with automatic expiry and full session logging over permanently assigned admin rights.
Mixing up the roles in a federated flow, such as naming the identity provider as the party that enforces the service provider's local authorization policy, or reversing assertion direction.
SAML and OIDC terminology is abstract, and candidates memorise acronyms without tracing which party issues the assertion and which party consumes it.
What to do instead
Draw the two parties and the direction of the assertion before answering. The identity provider authenticates and asserts; the relying party or service provider consumes the assertion and makes its own authorization decision.
Assuming federation removes the need for local account lifecycle management, so the candidate picks 'provision users in the IdP only' for scenarios that still require downstream entitlement management.
Candidates overgeneralise single sign-on and forget that authentication federation does not automatically deliver authorization data to every application.
What to do instead
Separate the authentication question from the provisioning question. If the stem involves application-specific roles or entitlements, include a provisioning or SCIM-style synchronisation component in the answer alongside the federated sign-in.
Confusing control types when answering audit and compliance items, labelling a log review or access certification as a preventive control and a policy or approval gate as detective.
Candidates focus on what the control achieves operationally and lose track of when it acts relative to the event.
What to do instead
Ask whether the control acts before the action (preventive), discovers it afterwards (detective), or reduces impact once it occurs (corrective). Assign the type first, then evaluate whether the option matches the evidence the auditor is requesting.