050-696 · Question #155
One of your clients owns a company that runs three shifts of employees each day. To save money, the client has purchased only enough workstations for a single shift of employees. Each employee…
The correct answer is A. Force periodic password changes. C. Restrict user logins times to the user's shift hours. Shared workstations across shifts combined with high employee turnover call specifically for time-based login restrictions and forced password changes to contain both concurrent and post-employment access risks.
Question
Options
- AForce periodic password changes.
- BUse a volume other than SYS for home directories.
- CRestrict user logins times to the user's shift hours.
- DAvoid assigning rights through the All Properties option.
- EAssign file attributes in addition to file trustee assignments.
How the community answered
(40 responses)- A70% (28)
- B5% (2)
- D18% (7)
- E8% (3)
Why each option
Shared workstations across shifts combined with high employee turnover call specifically for time-based login restrictions and forced password changes to contain both concurrent and post-employment access risks.
Forcing periodic password changes limits the window of exposure when employees leave after only 6-9 months, ensuring that a departed employee's credentials expire and cannot be used for unauthorized access.
Storing home directories on a volume other than SYS is a best practice for disk space and fault tolerance but does not address the security risks of shared workstations or high turnover.
Restricting login times to a user's specific shift prevents employees from using shared workstations outside their assigned hours, directly mitigating the risk of cross-shift unauthorized access on shared machines.
Avoiding the All Properties rights assignment option is a general least-privilege practice but is not specifically relevant to the shift-sharing or turnover concerns described.
Adding file attributes alongside trustee assignments provides granular file-level protection but does not address the core risks of shared login sessions or credential reuse after termination.
Concept tested: Login time restrictions and password policy for shared workstations
Source: https://www.novell.com/documentation/nw65/index.html
Topics
Community Discussion
8
Yusuf A.May 17, 2026The answers are A and C, and once you think about the scenario it makes a lot of sense. My supervisor walked me through a similar setup last month and the first thing he pointed out was that shared workstations with rotating users are basically a credential-leakage waiting to happen, so forcing periodic password changes (A) limits how long a departed employee's password stays valid, which matters a lot when average tenure is only 6 to 9 months. Restricting login times to shift hours (C) is equally important here because if three employees share one machine across three shifts, you do not want someone from the night shift able to authenticate during the day shift when they should not even be on site. The other options are legitimate security practices in general but they do not directly address the two biggest risks this scenario is describing, which are stale credentials from turnover and unauthorized access outside of assigned work hours. When you see a question that describes a specific environment like this one, look for the answers that map directly to the details they gave you, those details are almost always the hint.
Hiroshi T.May 3, 2026The high turnover detail is what tips A, and the three-shift shared-workstation setup is a direct argument for C, so both are clearly supported by the scenario. B is a red herring that trips people up because it sounds like an NDS best practice, but nothing in the scenario about shared workstations or turnover makes volume placement the priority here, so keep your answer at A and C.
Orla P.May 6, 2026Both A and C are the right call here. With 6-9 month turnover you want passwords cycling so a departed employee's credentials go stale fast, and locking login times to each shift means a night-shift worker's account simply cannot be used at 10 a.m. even if someone has the password.
Samuel O.May 8, 2026Time-based login restrictions are solid, but they only help if the system clock is centralized and trustworthy, which is worth verifying before you lean on that control in your policy.
Samuel O.May 9, 2026Shift workers sharing stations got me, but A and C clicked instantly, login times and forced resets mirror exactly what I pushed for at my last manufacturing gig.
Hiroshi T.May 12, 2026The blueprint also ties this squarely to account management controls under the security domain, so if your rationale went straight to audit logs and authentication policy rather than physical access, you already have the right mental model for any related drag-and-drop the live exam might throw at you.
Ingrid P.Apr 25, 2026I have D locked in as one of my two picks and I am not moving on it. The scenario is basically a perfect storm for rights creep: high turnover means accounts get created constantly, shared machines mean you cannot rely on physical access controls alone, and if someone is assigning rights through All Properties they are handing out broad object-level access that is extremely difficult to audit or cleanly revoke when that six-month employee walks out. The All Properties right covers every NDS property on an object, so one lazy trustee assignment quietly grants far more than the administrator intended, and with rapid churn you end up with a permissions landfill. My second pick is C, restricting login times to shift hours, because the shared-workstation setup literally tells you the access window, and there is no reason a first-shift employee's credentials should authenticate at 2 a.m. I have separate cards for why A is a distractor here: forced password changes address credential staleness but do nothing about the scope of rights already granted, which is the actual structural problem the scenario is describing.
Hiroshi T.Apr 27, 2026Ingrid, the Novell blueprint actually pairs A with C here, because forced password changes directly address the credential-staleness risk that high turnover creates, ensuring a departed employee's last password does not persist as a live attack surface. The All Properties concern is real in general NDS hardening, but the two controls the scenario is specifically testing for are the time-restriction and the periodic password reset.