Intranet Exam System Selection and Private Deployment on Domestic IT Stacks: A Practical Guide

As domestic IT innovation initiatives continue, an internal exam system is no longer just an “online question authoring and answering tool.” It is a business infrastructure component that connects personnel management, role-based training, qualification certification, score archiving, and audit supervision. For defense organizations, government agencies, and other organizations with closed network environments, the system must also support local data retention, compatibility with domestic hardware and software, offline operation, centralized exams, permission isolation, and full-process audit trails.

Selection therefore cannot focus only on the number of question types or page-level features. It should be evaluated across infrastructure adaptation, business completeness, system integration, security controls, performance assurance, and long-term operations and maintenance.

1. Define Business Boundaries and Deployment Constraints First

Before building the exam system, the project team should complete a requirement classification. Different scenarios impose significantly different architectural requirements. If boundaries are unclear, later stages may suffer from duplicate procurement or large-scale rework.

1.1 Centralized Exams on a Closed LAN

This scenario is usually deployed in an isolated server room or a dedicated intranet, and exams do not depend on the Internet during the test period. The system should provide the following baseline capabilities:

• All static resources, question banks, candidate information, and authentication components can run locally.
• The browser side must not depend on public network scripts, fonts, CAPTCHA services, or third-party authentication services.
• After external networks are disconnected, login, answering, submission, grading, and score queries can still be completed.
• The system supports fixed exam rooms, fixed terminals, and batches of candidates entering an exam at the same time.
• The system can record key events such as login, exam start, screen switching, disconnection, exam resumption, and submission.

Closed deployment should not be understood simply as “moving servers into the intranet.” If front-end resources, notifications, or identity verification still depend on external services, the system may become unusable after a physical network disconnection. Acceptance testing must therefore include a real offline test.

1.2 Parallel Intranet and Internet Access

Some organizations need both internal centralized exams and remote training or non-sensitive assessments. In this case, a partitioned intranet/Internet deployment can be considered, but internal exam services should not be directly exposed to external networks.

A safer approach is to divide business domains by data sensitivity level. Ordinary training can run in an external business zone, while important exams remain on the internal network. Necessary data can be transferred through an approved exchange mechanism. The two zones should have separate access controls, log auditing, and administrative permissions to avoid uncontrolled interconnection.

1.3 Integration with Existing Collaboration and Office Systems

An exam system usually needs to receive organization, department, personnel, and position information, and return training records or exam results to collaboration, HR, or archive systems. Selection should therefore confirm in advance:

• Which system is the master data source for personnel?
• Who is responsible for account creation, transfer, and deactivation?
• Whether score data needs to be returned?
• Whether interfaces use real-time calls or scheduled synchronization?
• How compensation works when the network is unavailable?
• How duplicate data is identified and handled?
• Which department is responsible for troubleshooting interface failures?

Only after data ownership is clarified can organizations avoid maintaining personnel information in multiple systems at the same time, which can cause account conflicts and incorrect score attribution.

2. Domestic Adaptation Is More Than a Compatibility List

Domestic IT environments typically involve domestic processors, operating systems, databases, and middleware. A supplier’s compatibility statement is only an initial reference and cannot replace validation in the actual environment.

2.1 Processor and Operating System Adaptation

The system should run on the organization’s existing domestic server environment. Evaluation should focus on:

• Whether installation packages or runtime components support the target processor instruction architecture.
• Whether there are binary dependencies that work only in specific environments.
• Whether service startup, process supervision, and file permissions comply with the target operating system’s requirements.
• Whether logs, temporary files, uploaded files, and backup directories can be configured independently.
• Whether system upgrades require Internet access.
• Whether installation and upgrade can be performed offline.

The browser side should also be validated. Exam pages should be compatible with the organization’s standard desktop environment, with particular attention to rich-text questions, image scaling, audio and video playback, input methods, full-screen display, and file upload.

2.2 Domestic Database Adaptation

“Can connect to the database” does not mean database adaptation is complete. Databases may differ in pagination syntax, field types, indexing behavior, transaction isolation, and case-sensitivity rules. During formal selection, the following tests should be completed using real business data:

• Bulk import of candidates and question banks.
• Random and fixed paper generation.
• Concurrent saving of answer progress by multiple candidates.
• Automatic submission and duplicate submission handling.
• Subjective question grading and score aggregation.
• Connection stability during long exams.
• Data backup, recovery, and consistency verification.

Key tables should also have appropriate indexes. For example, exam records are often queried by exam ID, candidate ID, status, and submission time. If indexing is poorly designed, even a small-scale test may pass while a centralized exam shows significant latency.

2.3 Middleware and File Storage

Question attachments, candidate uploads, and exported files can consume substantial storage. During deployment, application, database, and file storage should be planned separately to avoid concentrating everything on a single disk.

In a multi-node architecture, attachments must not be stored only in a local directory on one application server. Otherwise, files may be missing after traffic switching. An organization’s shared internal file storage can be used, but access permissions, backup policies, and capacity alerting must be confirmed.

3. Exam Business Capabilities Should Cover the Full Loop

A long-term exam platform should cover the complete process from personnel and question bank to paper, exam, grading, results, and archives.

3.1 Organization and Candidate Management

The system should support multi-level organizational structures, bulk personnel import, position tags, personnel status control, and exam scope configuration. After an account is disabled, historical exam records should not be deleted so that archives remain traceable.

Temporary candidates should have expiration dates and applicable exam scopes to prevent temporary accounts from remaining active indefinitely. Batch administrator operations should record the operator, operation time, affected scope, and result.

3.2 Question Bank and Paper Generation

Question bank management should support not only common objective and subjective questions, but also question versions, category permissions, duplicate question detection, and batch review. Important questions should go through authoring, review, and publishing steps so that unreviewed content does not enter formal exams.

Random paper generation needs clear rules, such as question counts by knowledge point, difficulty ratios, score limits, and exclusion conditions. The system should save the paper generation rules and the final paper snapshot so that later question bank changes do not affect historical exam reviews.

3.3 Exam Process Control

Common controls include exam start time, late-arrival limits, duration, allowed attempts, resumption after disconnection, and automatic submission. These policies need to balance security and usability.

For example, resumption after disconnection should not rely only on browser-local cache. The server should also save answer status periodically. When a candidate re-enters the exam, the system should verify identity, exam status, and remaining time to prevent extra answering time through repeated login.

3.4 Grading and Result Archiving

Objective questions can be scored automatically, while subjective questions require manual grading. For important exams, multi-person review or question-level grading can be used, and every score change should be recorded.

Results should support a review workflow before publication. Once results are archived, modifications must be strictly limited and fully audited. When necessary, a verification digest can be generated for archived results to detect unauthorized modification.

4. SSO and Business System Integration

When integrating the exam system with existing collaboration systems, standardized and loosely coupled interfaces should be preferred over direct reads from another system’s database. Direct database operations expand the permission boundary and can cause failures when table structures change.

4.1 Basic SSO Flow

A typical flow is as follows:

1. A user enters the exam entry from the collaboration portal.
2. The portal generates a short-lived login credential.
3. The exam system verifies the credential signature, validity period, and scope.
4. The system finds or synchronizes the account by unique personnel identifier.
5. A local session is created, and the user is redirected to the exam page.
6. The authentication result and failure reason are recorded throughout the process.

Login credentials should not contain sensitive information such as passwords and should not remain valid for long periods. The system should also prevent credential replay and validate request source and time skew.

The following is a neutral interface data example. Fields should be adjusted according to organizational standards:

{
  "request_id": "unique request identifier",
  "user_id": "unique personnel identifier",
  "display_name": "display name",
  "department_code": "department code",
  "issued_at": 1710000000,
  "expires_at": 1710000300,
  "nonce": "one-time random value",
  "signature": "signature digest"
}

This example only illustrates field design. It is not a fixed interface for any specific product. In actual implementation, the signature algorithm, key management, and validity period should be determined by unified security requirements.

4.2 Organization and Personnel Synchronization

Personnel synchronization should support creation, modification, transfer, and deactivation, not only bulk overwrite. A stable unique personnel ID should be used as the association key. Names and department names should not be used as the sole identifier.

Interfaces should also be idempotent: repeated submission of the same request must not create multiple accounts or duplicate records. Each synchronization should return the number of successes, the number of failures, and specific failure reasons so that operations staff can locate data issues.

4.3 Result Return

Result return should include at least exam ID, personnel ID, score, pass/fail status, submission time, and result status. If retakes or multiple exams exist, the system should define whether it returns the highest score, the latest score, or all records.

If an interface fails, data should not be discarded. Records pending return can be placed in a local task queue and processed through retries and manual compensation to achieve eventual consistency.

5. Security Should Cover Data, Permissions, and Auditing

Private deployment means that data is controlled by the organization, but it does not automatically mean security compliance. The system still needs protection across network, account, data, and operations layers.

5.1 Network and Communication Security

Even if the system is deployed on an intranet, encrypted transmission is recommended for administrative and exam endpoints to prevent accounts, questions, and scores from being transmitted in plaintext. Database ports and administrative ports should not be exposed to general candidate network segments.

Access zones can be divided by business role:

• Candidates can access only the exam entry.
• Graders can access only authorized papers.
• Question bank administrators can manage only specified categories.
• System administrators manage configuration but do not have full question-viewing permission by default.
• Auditors only read logs and do not participate in business modifications.

5.2 Least Privilege

The system should use role-based access control and support further restrictions by organization, exam, or question bank scope. High-risk operations such as deleting an exam, batch-changing scores, exporting a complete question bank, and changing administrator permissions should require secondary confirmation or an approval step.

Permissions for departing or transferred personnel should be revoked promptly. Organizations should not merely disable front-end accounts while retaining back-end access.

5.3 Logs and Auditing

Audit logs should cover at least:

• Successful and failed logins.
• Account, role, and permission changes.
• Question creation, modification, deletion, and export.
• Exam publication, suspension, and termination.
• Score modification, review, and publication.
• Data import, export, and backup.
• System configuration and API call exceptions.

Logs should not record sensitive content such as plaintext passwords or complete login credentials. Log retention periods, archiving methods, and viewing permissions should comply with organizational policies.

6. Concurrent Exams Require Dedicated Capacity Assessment

Intranet centralized exams have obvious burst-concurrency characteristics: many candidates may log in, load papers, and submit answers within a few minutes. Average traffic therefore does not represent the system’s real load.

Capacity testing should simulate the following stages:

1. Concentrated login before the exam.
2. Simultaneous paper retrieval.
3. Periodic answer saving.
4. Loading of questions containing images or audio/video.
5. Concentrated submissions near the end.
6. Administrators monitoring exam progress at the same time.
7. Batch statistics and export after the exam.

The test environment should be as close as possible to production, including server processors, database type, disk performance, network bandwidth, and browser versions. In addition to response time, teams should observe processor usage, memory usage, database connections, slow queries, disk reads and writes, and error rates.

System capacity should include headroom; “just passing the test” should not be the goal. Before an exam, data that can be generated in advance should be pre-generated to reduce computation pressure at exam start.

7. Backup and Recovery Matter More Than “Having Done Backups”

The backup strategy should cover the database, question attachments, configuration files, key material, and audit logs. Backing up only the database may not restore image-based questions and uploaded materials; copying only files cannot restore exam status.

The project should define two metrics:

• The acceptable range of data loss.
• The allowed recovery time after a failure.

More importantly, recovery drills should be performed regularly. The existence of backup files does not prove successful recovery. Only after restoration, login, querying, and score verification are completed in an isolated environment can the backup be considered effective.

A complete backup should be created before upgrades, and a rollback plan should be prepared. Database schema upgrades require particular caution. If migration fails, it should be possible to restore a consistent pre-upgrade state.

8. Procurement and Acceptance Should Use a Quantifiable Checklist

Procurement documents should not contain only broad statements such as “supports domestic IT stacks” or “supports SSO.” These should be converted into testable items.

Acceptance should include at least:

• Offline installation in the specified domestic base environment.
• Completion of a full exam after physically disconnecting the Internet.
• Import of personnel and question bank data at the specified scale.
• Stress testing at the planned concurrency level.
• Verification of resumption after disconnection, automatic submission, and duplicate submission handling.
• Completion of personnel synchronization, SSO, and result return.
• Checking administrator permission isolation and audit logs.
• Database and attachment backup and recovery.
• Verification of upgrade, rollback, and failover processes.
• Handover of deployment documents, operations manuals, API documents, and emergency plans.

At the same time, the scope of authorization, upgrade method, service term, and future expansion boundaries should be clarified to avoid usage impact after launch due to unclear licensing or maintenance conditions.

9. Conclusion: Move from Feature Procurement to System-Level Construction

For exam systems used by defense organizations, government agencies, and closed-network environments, the real selection focus is not a single feature. It is whether the system can run stably on domestic infrastructure, complete the business loop offline, securely integrate with existing identity and collaboration systems, and remain available in the long term through auditing, backup, and emergency mechanisms.

Project teams should follow an implementation path of “define boundaries first, then verify adaptation; stress test and rehearse first, then go live.” Real-environment testing, interface integration, security checks, and recovery drills can help avoid a system that works only in a demo environment but exposes compatibility, performance, and data consistency issues during a formal centralized exam.

For scenarios involving sensitive information or special management requirements, a dedicated assessment should also be conducted in accordance with applicable confidentiality rules, cybersecurity policies, and internal approval processes. Technical solutions must comply with security boundaries. Any cross-network access, data exchange, or mobile terminal usage should be implemented only after compliance review.