Free Practice Questions for Archer Archer-Expert Exam

The primary driver for Single Sign-On (SSO) in an Archer environment is user convenience and centralized identity management. As taught in Archer Administration II , the "goal" of SSO is to reduce the friction of accessing the platform. By allowing users to leverage their existing corporate credentials (via SAML, Windows Integrated, or LDAP), they can access Archer without needing to maintain a separate, "native" Archer password.

This strategy improves security by centralizing credential management in a single Identity Provider (IdP), where Multi-Factor Authentication (MFA) and account revocation policies can be strictly enforced. Option A is incorrect because SSO actually helps enforce enterprise security parameters rather than bypassing them. Option B is false because SSO is intended for all users, not just admins. Option C describes the opposite of SSO. Ultimately, the successful implementation of SSO ensures that users have a seamless transition into Archer while the organization maintains a high standard of access control.

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.

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.

While the standard Archer Application Builder supports a wide array of field types, the Questionnaire module uses a more specialized subset of fields within the Question Library . According to the Questionnaires and Assessment Maintenance curriculum, questions are designed to gather specific response data that can be scored.

Valid question types include Values List (for multiple choice), Date (for timestamped responses), Numeric (for quantitative data), and Text (for qualitative comments). The User/Groups List is also a valid question type, often used to identify stakeholders or owners during an assessment. However, an Attachment is not a standalone question type in the library. In Archer Questionnaires, attachments are typically handled as "supporting evidence" linked to a specific question or the record as a whole, but you cannot define a question as an "Attachment type" in the same way you define a "Values List" question.

This is a critical performance and behavior concept taught in Archer Administration II . Conditional Layout (CL) rules are intended to be "dynamic," meaning they should fire as the user interacts with the record (on-the-fly). However, Archer's Calculation Engine primarily runs on the server side during a "Save" event. If a CL rule depends on the value of a Calculated Field , the UI cannot determine the rule's outcome until the calculation has been processed by the database.

Consequently, the section remains hidden while the user is editing because the calculated value hasn't been updated in the current session yet. To make CL rules fire "instantly" before a save, administrators should use non-calculated fields (like Values Lists or Text fields) as the trigger. If a calculated field must be used, the behavior described—where the layout only updates after the record is committed to the database—is the expected platform limitation. Options C and D would not specifically cause a "save-only" refresh; a Date field (unless it is a calculated date) would trigger the CL rule immediately upon selection.

The Data Import Wizard offers three distinct processing modes: "Add New Records," "Update Existing Records," and "Add New and Update Existing Records." According to the Archer Administration II curriculum, the "Update Existing Records" mode is highly restrictive. It is used when an administrator only wants to modify records that already reside in the system.

During the import, Archer uses the specified Key Field(s) to find matches between the source file and the target application. If a match is found, the existing record is updated with the new data from the source file. However, if a row in the source file does not have a corresponding match in Archer, that row is simply ignored and discarded . No new records are created. This is a safety measure to prevent the accidental creation of "orphan" or duplicate data when the intent is strictly maintenance of existing content. If an administrator wishes to both update matches and create new records for non-matches, they must specifically choose the "Add New and Update Existing Records" (Upsert) option.

Archer's functionality is governed by a License Key . As taught in Archer Administration II , all the code for all use cases usually exists within the installer, but they are "locked" based on your organization's specific entitlements.

When a new use case is purchased, Archer provides a new alphanumeric license key. The System Administrator must log into the Archer Control Panel (ACP) , navigate to the "Instance" settings, and update the license key field. Once saved, the new use case—including its applications, workflows, and reports—becomes available for installation or activation. You do not need to perform a full system upgrade (Option C) or wait for a "push" from Archer (Option B). While you may need to download the specific Package File (.zip) for the use case from the Archer Community, the "step to gain access" and unlock the rights within your specific instance is the application of the license key in the ACP.

This statement is TRUE and represents the standard architecture for Federated Single Sign-On. In the context of SAML (Security Assertion Markup Language), Archer acts as the Service Provider (SP) , which is the application the user wants to access. The Identity Provider (IdP) , such as Okta, PingFederate, or Azure AD, is the system that holds the user's credentials and performs the actual authentication.

As detailed in the Archer installation and security guides, when a user attempts to log into Archer via SAML, Archer sends an authentication request to the IdP. The IdP authenticates the user and sends a "SAML Assertion" (a signed digital token) back to Archer. Archer then validates this token and allows the user access without them ever having to type their password directly into the Archer interface. This workflow is a cornerstone of modern enterprise security, allowing for centralized identity management and the enforcement of Multi-Factor Authentication (MFA) at the IdP level.

In the Archer architecture, search operations—particularly Global Search and Indexing —are handled by the Search service, which operates under the broader Job Framework . According to the Archer Installation and Troubleshooting guide, when a user executes a search that is technically "valid" (meaning the syntax is correct) but fails to return expected results or fails during execution, the details are captured in the Job Framework log files .

These logs provide insight into how the Search service is interacting with the Lucene indexes. If the index is corrupt or if the search query is timing out, the Job Framework logs (usually found in the \Logs directory on the Services server) will contain the specific stack traces or warnings. The Configuration Service (Option A) only logs system-level startup and ACP connectivity, and the Data Feed Service (Option D) is irrelevant to UI search queries. Reviewing the Job Framework logs is the standard first step for administrators when users report that "search isn't working" despite records clearly existing in the system.

The manual Data Import tool has specific structural limitations compared to the more robust Data Feed Manager. As taught in Archer Administration II , Data Imports are designed to handle standard Applications and their associated Sub-Forms .

When importing into an application that contains a sub-form, the administrator can map source columns to the sub-form fields to create multiple sub-form line items for a single parent record. However, Questionnaires (Option A, B, and D) cannot be populated via the standard Data Import tool. Questionnaires utilize a unique "Target/Assessment" architecture that requires either manual launching via a Campaign or the use of the Data Feed Manager with a specialized "Questionnaire" transporter. Because the Data Import tool lacks the ability to handle the complex relationship between the Question Library, the Questionnaire Template, and the Target record, it is restricted to standard application and sub-form data ingestion.