サンプル問題 1： As an Archer administrator, you need to run calculations on Exception Requests daily to see if they have expired and update the Overall Status field accordingly. However, when you enable the Recalculation Schedule for the application, the job is taking a long time to run. What step(s) are recommended to speed up the process?
A: Create a Schedule and use a filter to run the calculation only for those Exception Requests that are Approved.
B: Update the Overall Status calculation to include an IF statement based on the Expiration Date.
C: Use Data-Driven Events by creating a Set Values List action to update the status and associate it with a rule that evaluates the Expiration Date.
D: Update the value manually.
正解：A
Explanation: In the Archer platform, the Recalculation Schedule (found within the application's General Tab) is a powerful tool, but it can become a performance bottleneck if not configured efficiently. When a recalculation job is triggered, the Archer services must evaluate every record in the application to determine if calculations need to be updated. According to the Archer Administration II curriculum, the most effective way to optimize this process is by using Calculation Filters. By selecting option A, you are instructing the system to ignore records that are irrelevant to the specific business logic (e.g., records that are already "Expired," "Rejected," or "Draft"). By filtering the schedule to run only for "Approved" requests, the job engine processes a significantly smaller subset of data, which reduces the load on the Async Service and speeds up the completion time. Option B would likely slow the system down further by adding logical complexity to the calculation itself. Option C (Data-Driven Events) is not suitable for date-based triggers because DDEs only fire upon a record "Save" event; they cannot proactively "watch" a date to trigger a change without user intervention or a scheduled recalculation
サンプル問題 2： Which statement best describes the advantages of using SSO in Archer?
A: All these answers are correct
B: Reduced Password Fatigue and Help Desk Costs
C: Increased Productivity
D: Improved Security
正解：A
Explanation: According to the Archer Administration and Security documentation, Single Sign-On (SSO) integration provides a multi-faceted advantage for both the end-user and the system administrator. Reduced Password Fatigue occurs because users no longer need to remember unique credentials for Archer, which directly leads to a decrease in Help Desk Costs associated with password reset requests. Increased Productivity is achieved through seamless access; users can move from their workstation or corporate portal directly into Archer without the interruption of a manual login prompt. +1 Furthermore, Improved Security is a primary driver for SSO. By leveraging centralized authentication providers (like Active Directory via SAML 2.0 or Windows Integrated Authentication), Archer administrators ensure that corporate password policies (complexity, rotation, and MFA) are strictly enforced. When an employee leaves the organization and their account is disabled in the central directory, their access to Archer is revoked instantaneously. This eliminates the risk of "orphan accounts" existing within the Archer user database. Therefore, because SSO addresses administrative overhead, user experience, and enterprise-grade security protocols simultaneously, "All these answers are correct" is the verified professional standard.
サンプル問題 3： What should you do if the LDAP status remains QUEUED for an extended period?
A: Reconfigure the LDAP settings
B: Restart the server
C: Check the network connection
D: Ensure the Archer LDAP synchronization service is running
正解：D
Explanation: In the Archer environment, LDAP synchronization is an asynchronous process managed by the Archer Support Tools and specific Windows services. When an administrator triggers a manual LDAP sync or a scheduled sync begins, the job is placed into a processing queue within the Archer database. If the status remains "QUEUED" and never progresses to "IN PROGRESS" or "COMPLETED," the primary culprit is almost always the underlying service responsible for picking up that task. As detailed in the Archer Administration II technical troubleshooting modules, the Archer LDAP Synchronization Service (or in newer versions, the Archer Queuing/Job Engine service) must be in a "Started" state on the web or application server to process these requests. If the service is stopped, hung, or crashed, the job will sit in the queue indefinitely. While network connections (Option C) and configuration settings (Option A) are important, they typically result in an "FAILED" status with an error log rather than a "QUEUED" status. Restarting the entire server (Option B) is an inefficient "last resort" that doesn't address the specific root cause as directly as verifying the service status in the Services console.
