How Should a Security Administrator Prevent a Former Developer from Modifying Code After a Role Change?
A software developer changed positions within a company and is now a sales engineer. The security team discovered that the former software developer had been modifying code to implement small features requested by customers. Which of the following would be the best thing for the security administrator to implement to prevent this from happening?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests the principle of least privilege as it applies to role changes; RBAC ensures that a user’s permissions are tied to their current job function, not their past role.
When an employee transfers from a software development role to sales, the best control is role-based access control (RBAC), which automatically removes access based on the new role. Community consensus overwhelmingly supports B, RBAC, as the correct answer.
Choosing A (software patching policy) is a common mistake because it sounds like it involves reviewing code, but patching policies address software updates and vulnerabilities, not authorization to modify source code.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option B (a role-based access control policy) is correct because the employee changed roles, and RBAC grants or revokes access based on current job responsibilities. As one commenter explained, "You're on the Sales team, not the Dev team. We're denying your access to the code repository now." This aligns with the security principle of least privilege, ensuring that a user only has access necessary for their current role. The former developer no longer needs code modification rights, so RBAC would remove them.Why the Other Options Are Wrong
A software patching policy (A) governs how and when updates are applied to software, not who can modify source code, so it would not prevent unauthorized code changes. Firewalls on development servers (C) could block network access, but they would not prevent an authorized user with valid credentials from modifying code. Longer, more complex passwords (D) address authentication strength, not authorization; the developer already has legitimate credentials.Community Comment Notes
Most commenters (87% of votes) selected B, and several explained it clearly: one noted that after the role change, RBAC would deny access to the code repository. Another provided the formal definition of RBAC, emphasizing that access is regulated based on roles within the enterprise. One commenter suggested A was plausible, but acknowledged that B is the standard answer. The consensus is clear: role-based access control is the best fit for this scenario.Official Reference
Exam Strategy
Focus on the employee's changed role and remember that RBAC assigns permissions based on current job functions, not past positions. Eliminate options that address unrelated issues like patching, network firewalls, or password strength, and apply the principle of least privilege to select the answer that directly prevents unauthorized code access.