050-SEPROGRC-01 · Question #42
All of the following might be reasons to restart the Archer Job Engine, EXCEPT:
The correct answer is A. A user cannot login. The RSA Archer Job Engine handles asynchronous background tasks such as notifications, data imports, and calculated field updates - user login failures are processed by the web application layer, not the Job Engine.
Question
All of the following might be reasons to restart the Archer Job Engine, EXCEPT:
Options
- AA user cannot login
- BNotifications are not being sent
- CA data import is not being processed
- DCalculated fields are not being recalculated
How the community answered
(37 responses)- A78% (29)
- B11% (4)
- C3% (1)
- D8% (3)
Why each option
The RSA Archer Job Engine handles asynchronous background tasks such as notifications, data imports, and calculated field updates - user login failures are processed by the web application layer, not the Job Engine.
User authentication and login are handled by the Archer web application and the underlying identity or session management components, not the Job Engine - restarting the Job Engine would have no effect on login issues.
Notification delivery is an asynchronous background task managed by the Archer Job Engine, so a stalled engine would cause notifications to stop being sent.
Data feed imports are queued and executed as background jobs by the Archer Job Engine, so a non-functional engine would halt import processing.
Recalculation of calculated fields is triggered and processed as a background job by the Archer Job Engine, making it a valid reason to restart the service.
Concept tested: RSA Archer Job Engine responsibilities and scope
Source: https://community.rsa.com/t5/archer-platform-documentation/tkb-p/archer-platform-documentation
Topics
Community Discussion
5The answer is A, a user cannot login. Login failures have nothing to do with the Job Engine, they are an authentication or session issue you trace to the web server, the database connection, or account lockout settings, not a background processing service. The Job Engine handles background tasks like notifications, data imports, and field calculations, so options B, C, and D are all valid reasons you would restart it. If someone comes to you on exam day with this question, mark A fast and move on, it is a quick 30-second win, do not let it eat your clock.
If login fails, why would restarting a background job engine fix it?
Figured D was the culprit, but login issues have nothing to do with background job processing.
Right, login problems point to authentication or directory services, not anything sitting in a job queue.
Option A feels weird at first because login issues sound serious enough to restart everything, but login problems are usually an authentication or session config issue, not something the Job Engine handles. The Job Engine is specifically responsible for background processing like notifications, data imports, and calculated field updates, so A is the right exception here.