Archer Archer-Expert Archer Certified Administrator-Expert Exam Practice Test

In Advanced Workflow (AWF) , logic-based branching is handled by the Evaluate Content node. As taught in the Advanced Workflow Beyond the Basics course, this node acts as a "decision engine" within the workflow. An administrator configures one or more rules within the node that evaluate the fields of the record currently in the workflow.

Based on whether these rules evaluate to true or false, the record is routed down different paths (outbound transitions). For example, an Evaluate Content node might check the "Risk Rating" of a record; if the rating is "High," it transitions to an Executive Approval node; if it is "Low," it transitions directly to the Archive node. This is distinct from a User Action node (Option D), where the path is chosen manually by a person, or an Update Content node (Option B), which simply changes a field value without necessarily redirecting the workflow path.

In modern Archer environments (post-version 6.x), the Archer Job Engine Service is the primary service responsible for executing asynchronous tasks, including Data Feeds. When a Data Feed is initiated, it is placed in the queue. If the status remains "Pending," it indicates that the task has been recognized by the database, but no service has "picked it up" to begin processing.

As detailed in the Archer Administration II troubleshooting modules, the Job Engine is the "worker" that handles these requests. If this service is stopped, paused, or stuck on the application server, all scheduled and manual feeds will remain in a "Pending" state indefinitely. While the Queuing Service (Option D) is involved in the initial placement of the task, the actual execution and the transition out of "Pending" into "In Progress" is the responsibility of the Job Engine. The Indexing Service (Option C) handles search keyword indexing and is unrelated to data feed execution.

Archer is a Windows-based enterprise application that relies on the Microsoft technology stack. As detailed in the Archer Installation and Troubleshooting guide, there are three primary prerequisites for a successful deployment:

IIS (Internet Information Services): This is the web server that hosts the Archer web interface and APIs.

SQL Server: Archer requires a Microsoft SQL Server database to store all application data, metadata, and the instance configurations.

Microsoft .NET Framework: Archer is built on .NET; specific versions (such as 4.7.2 or higher, depending on the Archer version) must be installed for the web and service components to function.

Apache (Option A) is an alternative web server used primarily for Linux-based environments and is not a prerequisite or a supported web server for the Archer platform.

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.

In a standard corporate environment where users are already logged into a Windows Domain, Windows Integrated SSO (WIA) is considered the "easiest" and most seamless method. According to the Archer installation guides, WIA utilizes the NTLM or Kerberos protocols already built into the Windows OS and Internet Information Services (IIS).

Because the web server and the user's workstation share a common trust via Active Directory, the user is authenticated automatically without needing to provide credentials or interact with a third-party identity provider (IdP). While Federated SSO (Option C), like SAML, is more robust for cloud or multi-platform environments, it requires significantly more configuration, including certificate exchanges and metadata mapping. Token Based SSO (Option B) often requires custom coding or specialized header injection. For a pure Windows-based internal environment, Windows Integrated SSO provides the most "out-of-the-box" experience for both the administrator and the end-user.

The Security Events Report is the primary auditing tool for tracking administrative and sensitive user actions within the Archer platform. According to the Archer Administration II curriculum, this report captures a broad spectrum of "event-based" security data that standard access reports do not cover.

Specifically, it logs every failed login attempt , which is critical for identifying potential brute-force attacks. It also tracks metadata changes to the security infrastructure, such as when an Access Role is created or deleted , providing an audit trail of who modified the system's permissions. Furthermore, it records password changes initiated by users. While the "Locked Accounts Report" (Option B) only shows users currently barred from the system, the Security Events Report provides the historical context of why those events occurred. It is an essential resource for compliance officers and system auditors to ensure that the integrity of the Archer environment's security configuration remains intact.

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.

When moving data between two applications within the same Archer environment (often called an "Archer-to-Archer" feed), the Archer Web Services Transporter is the standard and recommended method. As detailed in the Archer Administration II Data Feed module, this transporter uses Archer’s own API (Web Services) to authenticate and "read" a report from the source application.

The transporter then passes that data to the Target section of the feed for mapping. Using a Database Query Transporter (Option C) directly against the Archer back-end SQL tables is strongly discouraged and often unsupported because it bypasses the application logic and security layers. The File Transporter (Option B) would require an intermediate step of exporting data to a CSV first. The Web Services Transporter allows for a direct, secure, and API-compliant way to keep data synchronized between inter nal applications, such as feeding "Findings" from various modules into a centralized "Master Findings" application.

In the Archer Security Parameters configuration (found in the Archer Control Panel or the Administration workspace), administrators define the "Maximum login attempts." According to the Archer Administration II curriculum, when a user exceeds this threshold (e.g., five failed attempts), the system automatically updates their account status to Locked .

It is important to distinguish "Locked" from "Inactive" or "Disabled." An Inactive or Disabled account usually implies an administrative action or a termination of the user's employment. A Locked status is a temporary security measure triggered by the system to prevent "brute force" attacks. Depending on the Security Parameter settings, a locked account may automatically unlock after a specified duration (e.g., 30 minutes), or it may require an administrator to manually click the "Unlock" button within the user's profile. This distinction allows administrators to run reports specifically on "Locked" users to identify potential security threats or users who simply need assistance with their credentials.

In a distributed Archer environment, the Archer Configuration Certificate is used to encrypt and secure communication between the Archer Control Panel (ACP) and the various server nodes. As taught in Archer Administration II , this certificate ensures that only authorized servers can join the instance and access the encrypted configuration files (like settings.config).

The certificate must be installed on all Web and Services servers. The Web server requires it to process user requests and communicate with the ACP, while the Services server (which handles the Job Engine, Indexing, and Workflow) requires it to decrypt the task instructions it receives. The SQL Server (Option B and C) does not require the Archer Configuration Certificate because it interacts with Archer via standard SQL authentication or Windows Authentication protocols at the database layer; it does not run the Archer Configuration Service. "DC servers" (Domain Controllers) are also outside the scope of this certificate requirement.

In the Archer Questionnaire platform, "Target" records (the actual assessments sent to users) are dynamically linked to the Questionnaire Template . Unlike standard applications where record data is "frozen" in the database structure, Questionnaires are highly sensitive to template changes.

According to the Questionnaires and Assessment Maintenance curriculum, if you delete a question from a template, that question (and any responses previously provided) will disappear from all records currently using that template, including existing ones. Conversely, if you add a new question, it will immediately appear on all active assessments that have not yet been "submitted" or "locked." This is why Archer administrators are strictly cautioned to version their questionnaires or "retire" old templates rather than modifying an active one mid-campaign. Making direct changes to an active template causes immediate, global updates across the entire record set, potentially leading to data loss for the deleted items and unexpected work for users seeing the new items.

To build a hierarchical view within a single application (like a "Manager" field in the Contacts application that points back to another record in the Contacts application), Archer utilizes Internal References . As taught in the Archer Administration II Advanced Search module, when an application references itself, you can use Directional Search logic to traverse the hierarchy.

By configuring the search to look "Upstream" or "Downstream" through the internal reference, Archer can recursively find all subordinates under a manager or all managers above an employee. This allows the system to flatten a complex organizational tree into a readable report. External References (Option B) are used between different applications, and Statistical Search (Option D) is used for mathematical aggregations (Sum, Count, Average). Only the combination of Internal References and Directional Search provides the specialized recursive logic required to map out a multi-level organizational hierarchy.

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.

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.

In the Archer platform, a "Calculated Field" is not a separate field type you select from the initial list (like Text or Date). Instead, almost any standard field type can be transformed into a calculated one. According to the Archer Administration II curriculum, the foundational step is to create the field first and then go into the field’s General Tab properties to check the box labeled "Calculate its value."

Once this option is enabled, the "Formula" and "Calculation Properties" tabs appear, allowing the administrator to define the logic. You cannot write a formula (Option A) or validate it (Option D) until the field has been designated as a calculated field. Option C is irrelevant as a "first step," as calculations can be applied to many field types, not just User/Groups lists. By enabling the calculation property first, you signal to the Archer Calculation Engine that this field's value will be managed by the system rather than by manual user input.

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.

In the Data Feed Manager , the "Target Record Processing" setting on the Run Configuration tab determines how Archer handles records that are not present in the current source file. As taught in Archer Administration II , selecting the Delete radio button (often referred to as a "destructive feed" or "mirroring") instructs Archer to compare the source file to the target application.

If the feed finds records in the target application that do not match the keys provided in the source file, it will delete them. In this scenario, since there are only 20 entries in the source file, Archer will keep (or create) those 20 records and delete the remaining 80 records that were already in the system but were missing from the source. Consequently, the final count in the target application will be 20. This setting is typically used for synchronization tasks where Archer must exactly match an external "system of record." Administrators are cautioned when using this setting, as it can lead to massive data loss if the source file is accidentally truncated or filtered incorrectly.

The Data Import tool is designed for strict adherence to application business rules. According to the Archer Administration II curriculum, required fields are mandatory for the creation of any record. If a source file contains even a single row that is missing data for a "Required" field, the validation engine will trigger an error.

Unlike the Data Feed Manager , which can be configured to "Skip" errors and continue, a standard Data Import is an "all or nothing" operation by default when it encounters critical structural failures like missing required data. The import process will stop, and no records from that file will be committed to the database. This ensures that the application does not end up with "broken" records that bypass the logic intended by the administrator. To fix this, the administrator must either populate the missing data in the source file or temporarily make the field "Not Required" in the application builder before re-attempting the import.

In the Advanced Workflow Beyond the Basics curriculum, the Wait for Content Update node is identified as the primary tool for time-based automation. While its name suggests it is waiting for a user to change a field, its secondary function is to act as a SLA (Service Level Agreement) timer .

Within the node configuration, an administrator can define an "Escalation" or "Timeout" path. You can set a specific duration (e.g., 5 days). If the expected content update does not occur within that timeframe, the node "times out" and automatically reroutes the record down a secondary transition path—typically to a manager's review or an automated notification. While a User Action node (Option B) can have a "due date," it does not automatically move the record to a different path solely based on time without the Wait for Content Update node logic. Update Content (Option D) and Send Notification (Option A) nodes are instantaneous actions and do not possess the ability to "pause" and monitor for duration.

The Mail Merge functionality in Archer allows administrators to take record data and push it into a pre-formatted Word or PDF template. This is a common requirement for generating formal "Exception Letters" or "Audit Reports."

As taught in the Archer Administration II curriculum, when a user is viewing a record and wishes to generate one of these documents, they must click the Export button. Upon clicking Export, the user is presented with several options: standard exports (like CSV or Rich Text) and any Mail Merge Templates that have been associated with that specific application and made available to the user's role. Option B (Email) is used for sending on-demand notifications, not for generating formatted document templates based on Word/PDF layouts.

The Archer Job Monitor is a dedicated administrative interface found within the "Administration" workspace. It is the primary dashboard for monitoring the health of the Archer Job Engine . According to the curriculum, the Job Monitor provides visibility into both scheduled and ad-hoc background tasks, including Data Feeds, Data Publication, Notifications, and Recalculations.

The report displays a chronological list of jobs, their current status (Queued, In Progress, Completed, or Failed), and their start/end times. This is the first place an administrator looks if a notification wasn't sent or a data feed didn't update. Unlike "User access logs" (which track logins) or "System performance metrics" (which are found in the ACP or IIS), the Job Monitor is focused strictly on the execution history of background system tasks, allowing administrators to identify bottlenecks or specific job failures without needing access to the server's event logs.