Free Practice Questions for Relativity RCA Exam

The correct answer is A. Everyone . Relativity’s official instance security documentation states that all users in any instance of Relativity are members of the Everyone group . This means that when a user account is created, that user is automatically part of the built-in Everyone group, even before any additional group assignments are made.

This is an important distinction because Relativity also documents that users are then manually added to other groups for operational permissions and workspace access. The Users documentation explains that you create users and then add them to groups, which are associated with workspaces. That confirms that while administrators normally assign users to functional groups after creation, the system-wide Everyone group already applies automatically.

The other options are incorrect. All Users is not the Relativity built-in group name documented by Relativity. Users are not automatically added to a group is false because the Everyone group membership exists by default. Domain Users is a Windows or directory-services style concept, not the Relativity group referenced in the platform’s own security model. For RCA purposes, this matters because the Everyone group has baseline, environment-level significance and certain permissions are managed with that universal membership in mind. Therefore, the correct answer is Everyone .

The correct answer is C. Branding queue . Relativity’s official Production queue documentation states that during a production job, Relativity sends a job to the branding queue for stamping redactions, headers, or other image modifications, and any change to the priority of a job in the production queue changes its priority in the branding queue . This is a direct match to the question.

This linkage exists because branding is a dependent production-stage activity. When administrators reprioritize a production job, Relativity keeps the related branding work aligned so that downstream stamping and production preparation happen in the proper order. The other queues listed in the answers are separate queue systems and are not documented as automatically inheriting production queue priority changes. Therefore, from a Productions administration perspective, the queue whose priority is also changed is the Branding queue .

The correct answer is A. The field mapping section is disabled because only the control number is needed. Relativity’s official Integration Points documentation for promoting data between workspaces states that when you select Copy Images , the field mapping section is disabled because only the control number is required and available in this scenario . It further notes that if you want to transfer other field metadata, you must create a separate integration point without choosing to copy images.

That directly rules out the other options. Relativity does not state that the native file must be included to transfer images in this scenario. It also specifically notes that you are not required to have Integration Points installed on the destination workspace , so option C is incorrect. Option D is wrong because metadata is not automatically mapped and migrated in the Copy Images path; in fact, field mapping is disabled in that configuration.

From an RCA and data-movement perspective, this is a common distinction: image promotion through Integration Points is streamlined and relies on control number matching , not standard metadata field mapping. Therefore, the true statement is A .

The correct answer is D. Remove key terms from the dtSearch index noise words. Relativity’s dtSearch documentation explains that if a word in the search phrase is part of the noise words list, and that word is important to the search, you must remove it from the dtSearch noise words list and then rebuild the index. The documentation gives this exact type of guidance for terms like “and” when the term must be treated as part of the actual phrase instead of being ignored.

This makes options B and C incorrect because changing or deleting the attorney’s search terms would alter the intended search logic rather than making the index capable of respecting the requested phrase. Option A is also incorrect because the alphabet file is for searchable characters and tokenization behavior, not for managing ignored noise words. Therefore, before running the Search Terms Report, the correct step is to remove those key terms from the dtSearch index noise words list and rebuild the index if needed.

The correct answer is A. Ignore Numbers. Relativity’s near duplicate documentation explains that when Ignore Numbers is set to true, the similarity calculation considers only tokens beginning with letters, which means numbers are excluded from the similarity percentage calculation. That is directly relevant for invoice populations, because many invoices share nearly identical wording while differing mainly by dates, invoice numbers, quantities, or amounts. In a set like the one described, toggling Ignore Numbers is the setting most likely to change how those documents are grouped and help you assess whether the current near duplicate results can be improved.

The other options do not fit this use case. MD5Hash Verifier is related to hash-based duplicate validation rather than textual near duplicate tuning. Relativity Compare is a review tool for examining differences after grouping, not a setting that changes how the grouping is calculated. Auto-recognize Dates is not the structured analytics tuning option documented for this scenario. Therefore, for invoice-heavy data where numerical differences are driving questionable textual near duplicate results, the correct setting to toggle is Ignore Numbers.

The correct answer is B. dog not cat. Relativity’s dtSearch syntax guidance explains that the NOT operator can be used by itself at the beginning of an expression, or in the middle of an expression only when combined with either AND or OR. Relativity gives examples such as apple OR NOT pear and applesauce and NOT pear as valid syntax. That means expressions like dog OR NOT cat and dog AND NOT cat are valid, while dog NOT cat is missing the required connector and therefore causes a syntax problem.

Relativity’s Search Terms Report error documentation further explains that STRs surface syntax errors when the search index cannot process the term because of invalid syntax. In this case, dog not cat violates the dtSearch operator rule, so it is the option most clearly expected to fail with a syntax error in a search terms report. Option A is a standard Boolean expression and is valid. Options C and D both include the required connector before NOT, which matches Relativity’s documented dtSearch usage. Therefore, among the listed queries, dog not cat is the one that would cause a syntax error on an STR.

The correct answer is A. After a production is exported. Relativity’s official documentation on OCR for redacted production documents explains that you create an OCR set and then point the OCR set to the completed Production . The workflow explicitly states that OCR is performed against the completed production , and once the OCR job is complete, the resulting text becomes ready to export. This means the production must already exist before OCR is run against it. In practical terms, OCR is performed after the production has been run/exported as a completed production set , not before the production exists.

The reason for this is that Relativity OCR in this workflow can operate on production images containing burned-in redactions . That allows the exported text to reflect the redacted version rather than unredacted underlying extracted text. Running OCR before the production is run would not achieve this production-specific result, because the final production images would not yet exist. Option D is too broad and incomplete because a document being redacted does not itself define the OCR timing; the documented process is tied to a completed production . Therefore, under the Productions topic, the correct answer is that you run OCR after the production is exported/completed , because that is when the production images are available for OCR processing.

The correct answer is B. Name conflicts: Rename or map Fields. Relativity’s Troubleshooting application installation errors documentation explains that for Name conflicts , the available resolution options include Rename and Map Field . The page specifically instructs admins to use the Resolve Errors drop-down and choose either Rename or Map Field to address the conflicting artifact during application installation.

The other choices are inconsistent with the documentation. For locking conflicts , Relativity says you can resolve them by selecting the Unlock checkbox, so option A is incorrect. For restricted file types , the documented resolution is to remove the external resource from the application and re-install , not simply “run a re-install,” so option D is incomplete and inaccurate. Option C is also too vague and not one of the documented named error-resolution pairings. Therefore, the correct expected application installation error and solution is Name conflicts: Rename or map Fields

The correct answer is C. You cannot use Audit to revert coding decisions on required fields back to a null state. Relativity’s official Audit documentation states that certain field types, including single choice , can be reverted. However, it also explicitly states that you cannot revert a required field if doing so would return that field to a blank null value . That is exactly what this scenario describes: the field was changed from null to Responsive, and reverting would restore it to null. If the field is required, Relativity blocks that revert because required fields cannot be blank.

This means option A is incorrect because single-choice fields can be reverted in Audit. Option B is also incorrect because Relativity supports both individual and mass revert workflows depending on the situation. Option D is not the documented reason for the failure. The controlling issue is the required-field constraint. From an RCA perspective, this is a subtle but important administrative behavior: the Audit system can revert field changes, but only where the resulting value remains valid under Relativity’s field rules. If the revert would violate a field’s required setting, the system will not allow it. Therefore, the most accurate reason is that Audit cannot revert the value because the revert would place a required field back into a null state .

The correct answer is C. The fields returned by the Searchable Set saved search are all empty for this document. Relativity documents that dtSearch indexes are built against a Searchable Set, and administrators must manually update those indexes when the underlying document search sets change. Relativity also describes dtSearch as indexing the content made available through the configured search/index setup rather than magically finding text that is not present in the indexed fields. If the document is part of the saved search but the fields being indexed for that document are empty, there is effectively no searchable text for dtSearch to return for that record.

Option B is not the best answer because an incremental build is a maintenance activity for adding new documents, not the documented reason a single already-known document cannot be found. Relativity notes that incremental builds look for new documents in the searchable set and do not re-index previously indexed records with changed content, which is a different issue. Option D is unrelated because Review Center queue assignment does not control whether a document is searchable through a dtSearch index. Option A is also not the best explanation for this question; dtSearch availability is driven by index/searchable-set configuration and accessible indexed text, not by parent-email folder access in the way the option suggests. So the best RCA-aligned answer is that the document has no indexed searchable content in the fields returned by the searchable set.