The code snippet below controls all electronic door locks to a secure facility in which the doors should only fail open in an emergency. In the code, "criticalValue" indicates if an emergency is…

Question

Options

• ARewrite the software to implement fine-grained, conditions-based testing
• BAdd additional exception handling logic to the main program to prevent doors from being opened
• CApply for a life-safety-based risk exception allowing secure doors to fail open
• DRewrite the software's exception handling routine to fail in a secure state

• A
  27% (16)
• B
  55% (33)
• C
  7% (4)
• D
  12% (7)

Explanation

The scenario describes door-lock software where doors must fail open only during legitimate emergencies (signaled by 'criticalValue'). The vulnerability is that a software exception could trigger all doors to unlock at an inappropriate time - not during a real emergency. Option B is correct: adding exception handling logic to the main program creates a guard that prevents doors from opening unless the criticalValue legitimately signals an emergency, closing that gap. Option D ('fail in a secure state') sounds appealing from a security standpoint, but for a physical door lock, 'secure state' means 'locked/closed.' In a life-safety environment, failing locked during a software error could trap occupants and violates life-safety requirements - so D is incompatible with the stated facility requirement. Option A addresses testing methodology, not runtime behavior. Option C is avoidance, not remediation.

No community discussion yet for this question.