AE-C (NBRC) common mistakes
AE-C · Understand the traps and how to avoid them.
Treating local directory accounts as if they were network accounts: creating a local user to solve a login problem, then expecting that account to authenticate against the network directory or inherit managed preferences.
Candidates memorize that accounts can be local, network, or mobile but never internalize that a local account has no directory node backing, so password policies, group membership, and managed settings from the directory never apply. Scenario questions about a user who can log in offline but not on the network expose this gap.
What to do instead
Before answering, classify the account by its authentication source: where does the password get verified, and where do group memberships and policy come from? If the requirement is central policy or network authentication, the answer must involve a directory-bound or mobile account, never a standalone local account.
Assuming deleting a user record removes the home folder and all associated data, or conversely that deleting the home folder removes the account.
The delete-account workflow offers separate decisions about the account record and the home directory, and candidates collapse them into one action. Lab practice usually rushes through the confirmation dialog, so the distinction is never reinforced.
What to do instead
State explicitly in your reasoning which artifact is being removed: the account record in the directory, the home folder on disk, or both. When a question asks how to reclaim disk space while preserving user data for later, the answer preserves the home folder and removes only the record, and vice versa for a clean deprovision.
Configuring a static IP address on a client without also setting the correct subnet mask, router, and DNS servers, then blaming the address itself when name resolution or off-subnet traffic fails.
Candidates focus on the IP field because it is the one they can verify with a quick ping, and forget that DNS and the default gateway are separate fields that a DHCP lease would otherwise have supplied automatically.
What to do instead
Treat manual network configuration as a bundle of four values: address, mask, router, and DNS. When a static-configured host can reach local peers but not the internet, check the router and DNS fields first, and verify the mask matches the segment so the host does not send off-subnet traffic to the wrong place.
Choosing DHCP for a server or network device that must be reachable at a predictable address, or leaving a client on a self-assigned link-local address and calling it a DNS problem.
A 169.254.x.x address looks like a configuration error but is really the symptom of a failed DHCP exchange, and candidates misread it as an addressing scheme choice rather than a lease failure. Separately, they equate 'automatic' with 'correct' for infrastructure hosts.
What to do instead
Learn to read the link-local prefix as 'no lease obtained' and troubleshoot the DHCP path: server reachability, scope exhaustion, VLAN or relay configuration. For infrastructure hosts, require a static or reserved address so clients and services have a stable target.
Answering permission questions by thinking only in POSIX owner/group/other bits and ignoring inherited permissions, access control entries, or the difference between a share-level and file-system-level restriction.
The classic three-tier permission model is taught first and is easy to recall, so candidates apply it to scenarios that actually hinge on inheritance or on an additional ACL layer. The result is a plausible answer that fails on the specific user described.
What to do instead
For every permission scenario, identify the effective access for the named user by walking the chain: share or service permission first, then file-system permission, then inherited versus explicit entries. The most restrictive layer wins, and a deny entry overrides an allow.
Assuming a shared folder is accessible once permissions are set, without verifying that the sharing service is enabled and that the protocol in use (for example SMB versus AFP) is actually offered by the server.
Candidates conflate 'the folder exists and permissions look right' with 'the service is reachable.' They also carry over assumptions from older protocol guidance and forget that a legacy protocol may be disabled by default on current systems.
What to do instead
Check the service layer separately from the permission layer: is the sharing service running, is the specific protocol enabled, and does the client negotiate that protocol? When a client cannot connect at all, troubleshoot reachability and service availability before touching permissions.
Adding a printer by IP address and then assuming driver selection is irrelevant, or expecting a queue configured for one protocol to work identically when the client uses another.
Modern driverless printing makes setup look automatic, so candidates stop reasoning about the print path. They also forget that a queue must advertise the protocol the client speaks, and that a paused or held queue looks like a hardware failure.
What to do instead
Trace the print job end to end: client, protocol, queue on the print server, driver or driverless profile, and device. When jobs stall, check queue state and protocol match before suspecting the printer itself, and confirm the driver matches the device's capabilities.
Disabling a security control to make a peripheral or service work, such as turning off a firewall or weakening a gatekeeper-style policy, and presenting that as the fix.
Under time pressure in a lab, the fastest path to a working device is often to remove the obstacle, and candidates carry that habit into scenario questions where the correct answer must preserve the security posture.
What to do instead
Prefer the narrowest exception: allow the specific service, port, or signed application rather than disabling the control wholesale. If an answer removes a security layer entirely, look for an alternative that scopes the change to the one item that needs it.
Treating a certificate as valid merely because it exists and is not expired, without checking that its trust chain terminates in a trusted root and that the hostname it was issued for matches the name the client uses.
Expiry is the most visible failure and the easiest to check, so candidates stop there. Trust anchor problems and name mismatches produce warnings that look identical to the user but require entirely different fixes.
What to do instead
Evaluate a certificate on three axes: validity period, trust chain to a trusted root, and subject or subject alternative name matching the address used by the client. When a warning appears, identify which axis failed before choosing a remedy such as reissuing, installing an intermediate, or correcting the name.
Confusing a keychain item's stored credential with the keychain's own lock state, or assuming a login keychain password is automatically synchronized with the account password after an administrative reset.
Candidates model the keychain as a simple password store rather than as a locked container whose unlock secret is separate from the account credential. Administrative password resets that leave the old keychain intact are a common real-world trap.
What to do instead
Separate the two questions: can the keychain be unlocked, and does the item inside hold the right credential? After an administrative password change, plan for the keychain to need its old password or a reset, and treat 'keeps prompting for password' as a lock-state symptom rather than a wrong-password symptom.
Assuming a configuration profile or management enrollment applies to every user and every setting on the machine, rather than reasoning about scope, precedence, and whether the payload targets the device or the user.
Deployment tooling presents profiles as a single install action, so candidates miss that payloads can be device-scoped or user-scoped and that a locally set value may be overridden or locked by policy.
What to do instead
For management scenarios, ask three questions: is the payload device-scoped or user-scoped, is the setting locked or merely defaulted, and which scope takes precedence? A setting that reverts after a change usually means a profile is enforcing it, not that the change failed.
Jumping to a reinstall or erase as the diagnostic step when a targeted check of logs, disk health, or startup state would isolate the fault.
Reimaging feels decisive and is easy to describe, so it becomes the default answer. Candidates also skip log inspection because reading a log excerpt requires interpreting severity and subsystem rather than recalling a fact.
What to do instead
Order diagnostics from least destructive to most: reproduce the symptom, read the relevant log or console output, check disk and startup state, then repair. Reserve erase-and-reinstall for confirmed corruption or as an explicitly last resort, and say so in your reasoning.