Campus placement workflow

I'd treat the student's placement status as the single source of truth and change it only inside a database transaction. On acceptance, I lock the student's status row with SELECT FOR UPDATE and check the active policy version, including any dream-tier upgrade allowance. Then I insert the accepted offer and update the status. A partial unique index on accepted offers per student per season is the backstop if code has a bug. In the same transaction I write an outbox event, which later withdraws the student's pending applications and notifies recruiters. The acceptance endpoint is idempotent, so a retried click doesn't create a second record. Every decision is logged with the policy version, so disputes can be replayed exactly.

I would split it into services that own clear data: identity (institute SSO), profile and verification, drive and rule-set management, the eligibility engine, applications and opt-ins, assessment integration, scheduling, evaluation, offers, notifications and reporting. Each service writes state changes to its own store and emits domain events through a transactional outbox to a durable log. The audit store consumes those events as append-only records. Reporting builds projections from the same events, so published numbers trace back to records. External parties, meaning the proctoring vendor, calendar APIs, SMS gateway and DigiLocker, sit behind adapters with retries, signature checks and circuit breakers. The offer service holds the one-offer invariant in a single strongly consistent database. Everything else can be eventually consistent.

Student holds identity from SSO. ProfileField holds a value, a verification state and a version, and each verified field links to a VerificationRecord with maker, checker, source document reference and timestamps. ResumeVersion is an immutable rendering pinned to a set of profile field versions. Drive has role, CTC band and locations, plus a RuleSet with a version number and a declarative criteria document. EligibilitySnapshot links a drive, a rule version and per-student results with reasons. Application links a student, a drive, a resume version and a status history. AssessmentResult stores the vendor event ID, score and raw payload hash. InterviewSlot and Reschedule record times and reasons. Evaluation is versioned per panelist. Offer has a state, and PlacementStatus is a single row per student, guarded during acceptance.

A maker from the placement cell reviews the student's submitted values against a source: a DigiLocker-issued document where available, a university feed, or an uploaded marksheet. The maker proposes 'verified' or 'rejected' with notes. A different user, the checker, approves or sends it back. The system enforces maker not equal to checker at the database or service level, not only in the UI. Each transition is an event carrying user IDs, document reference and hash, and timestamps. On approval the field version is locked. Any later edit creates a new field version in 'pending' state and reopens verification. Eligibility only reads the latest verified version, so an edit never silently changes outcomes. I would also add a queue with SLAs so verification backlog does not block drives.

I verify an HMAC or asymmetric signature over the raw request body using a per-vendor secret kept in a secrets manager, and I use a constant-time comparison. I require a timestamp in the signed content and reject anything outside a short window to block replays. I use the vendor's event ID as an idempotency key so redeliveries do not create duplicates. I validate that the candidate and drive mapping exists and that the candidate actually opted in. Otherwise I quarantine the event. I store the raw payload hash for audit, acknowledge quickly, and process asynchronously. Secrets rotate with an overlap period in which both keys are accepted. Mutual TLS or IP allow-listing can add defence in depth, but neither replaces the signature check.

The evaluation service enforces this at the API level. A panelist's read access to other panelists' scores for a candidate is denied until that panelist's own submission is locked. Hiding scores only in the UI is not enough, because the API could still leak them. Aggregates are not exposed either until the panel is complete or the panelist has submitted. Each submission is stored with the panelist ID, timestamp and rubric version, and becomes immutable. If a panelist needs to correct a score after seeing others, the correction is a new version with a mandatory reason and a flag showing it was made after the reveal. That keeps the independence property auditable and lets reviewers spot score anchoring.

The Digital Personal Data Protection Act, 2023, together with its rules, requires a lawful basis for processing, clear notices, purpose limitation, security safeguards, breach handling and support for data principal rights. In practice I would record explicit, granular consent or another valid basis for sharing data with recruiters, per drive. I would share only the fields a recruiter needs and keep recruiters out of the backlog history unless a criterion requires it. I would also record retention periods, offer access and correction requests, and keep a breach response process. Recruiters act on data we share, so contracts must cover their handling. I would involve the institute's legal team for the specifics rather than guess at obligations.

Eligibility runs as deterministic rules over verified fields only, never over self-declared data. The rule set is versioned and approved by the placement cell before publishing. At publish time I freeze a snapshot: the student ID, the rule version, and the pass or fail result for each criterion. A student can then see exactly why they were excluded, for example 'CGPA 6.8 below 7.0'. If a record is corrected after publishing, the student isn't added silently. An officer files an override with a reason, which is logged and visible in the audit trail. Sensitive attributes are excluded from rule inputs entirely. Periodic reports compare eligibility and selection rates across branches so the cell can spot skewed criteria.

I model it as slot allocation. Panels publish availability, and the student's calendar includes their other confirmed interviews, assessments and exam timetable. The scheduler assigns slots greedily by shortlist order with buffer time, then lets students swap within limits. Slot booking uses a unique constraint on panel and time so two students can't take the same slot. Calendar invites go out through Google or Microsoft APIs with video links. Reschedules and no-shows are recorded with reasons, because they affect fairness reviews later. When a panel runs late, the system pushes updated times through the notification queue instead of WhatsApp groups. Feedback forms open only for the assigned panelists once the slot starts.

I would store criteria as a declarative document, not code: allowed branches, a minimum CGPA with an explicit comparison operator, a maximum active or historical backlog count, graduation years, and optionally policy flags such as already-placed status. Each approved change creates an immutable new version with author, approver and diff. The engine is a pure function: it takes a rule version and verified field versions and returns a verdict per criterion. Because it is deterministic and pure, I can re-run any historical evaluation and get the same answer. Recruiter-specific logic that cannot be expressed declaratively gets pushed back to the placement cell rather than allowed as custom scripts, because scripts are hard to audit.

It stores the drive ID, rule-set version, engine version, evaluation time, and for every student considered, the verdict plus the exact field versions used and the per-criterion outcome, for example 'CGPA 7.4 is at least 7.0: pass'. Freezing it means notifications, opt-ins and recruiter views all refer to one fixed list, rather than a list that shifts as profiles change. It also gives a stable audit answer to the question 'why was I excluded?' If data or rules change later, I create a new snapshot linked to the previous one instead of mutating it. That way the history of who was eligible and when is preserved.

I would not quote real numbers without the institute's data, so I would parametrise. Suppose S final-year students, D drives per peak day, and each publish notifies E eligible students over three channels. Notifications are about 3 × E × D messages, sent through a queue. For a few thousand students this is small for compute, so the real limits are SMS gateway throughput and template rules. Opt-in traffic is bursty near deadlines, perhaps a large share in the last hour, so I would size the application API for that peak and make writes idempotent. The eligibility evaluation is S rule checks per drive, which is trivial. Storage is dominated by resume PDFs and assessment payloads, not relational rows.

I never rely on webhooks alone. After the assessment window closes, a reconciliation job calls the vendor's results API, if one exists, and compares results against what we received for every opted-in candidate. Missing scores get fetched, and mismatches get flagged for review. For ordering, each event carries a vendor timestamp or sequence number. I apply a state machine, for example started, submitted, scored, rescored, and ignore stale transitions instead of overwriting newer data. Shortlisting is gated on a 'results complete' state for the drive, so we never shortlist from a partial set. Candidates with technical failures, such as disconnects, go to a review queue rather than being scored zero automatically.

Audit records are append-only events: actor, action, entity, before and after references, reason, request ID and time. Services write them through the outbox in the same transaction as the state change, so no change happens without an event. The audit store accepts only inserts, and the application role has no update or delete grants. For tamper evidence I would hash-chain records per entity or per day and periodically anchor the chain head in write-once storage. Clock skew is handled with server timestamps plus sequence numbers. Reading the audit trail is itself access-controlled and logged. Finally, the audit trail must be sufficient to replay decisions, so it references rule versions, field versions and rubric versions rather than copying only display text.

Statistics are projections built from audit events, with a versioned metric definition: the numerator, the denominator, filters, and which offer states count. When a number is published, I store a report record with the metric definition version, the event log offset or cutoff time, and the list of contributing student or offer IDs, or a reproducible query over them. Anyone authorised can drill from 'placed: N' to the list of records and from each record to its acceptance event. Because projections are deterministic, I can rebuild them from the log and check that they match. Published reports are immutable. Corrections create a new version with a reason, so earlier brochures stay explainable.

The revocation is a new event on the offer, with the actor, reason and approval from the placement cell. Nothing is deleted. The placement status transaction then recomputes the student's state. Under most institute policies the student becomes eligible again, but that is a policy decision, so I make it a versioned policy setting rather than hard-code it. Applications that were withdrawn because of the acceptance are not silently revived, because those drives may have moved on. Instead, the student is notified and can opt in to drives that are still open, and the cell can manually restore specific applications with a logged reason. Statistics treat the revoked offer according to the metric definition, and earlier published reports keep their version.

I would use RBAC for broad roles and attribute-based checks for scope. A recruiter can see only applicants who opted in to that recruiter's own drives, and only the fields that consent allows. Panelists see only the candidates assigned to their slots, and only during the evaluation window. Placement cell makers and checkers have separate permissions, so one person cannot do both steps on the same record. Admin actions require MFA and are logged. Authorisation is enforced server-side in a shared policy layer, ideally declarative, so it can be tested and reviewed. Bulk exports are restricted, watermarked and logged. I would also run periodic access reviews, because staff and recruiter contacts change every season.

I would model the placement policy as versioned configuration, separate from drive rules: for example, tiers by CTC band, which tiers a placed student may still apply to, and how many upgrades are allowed. The acceptance transaction evaluates the active policy version and records it on the acceptance event. Pending application withdrawal uses the same policy, so withdrawal and eligibility never disagree. Policy changes mid-season need approval and an effective date, and they do not retroactively alter decisions already made. Students see the policy that applies to them. I would keep the policy language small and testable, because every additional exception multiplies edge cases in the concurrency-critical path.

The audit trail can reconstruct the whole path: the eligibility snapshot and rule version, the opt-in and resume version, the assessment score with the vendor event, the shortlisting rule and cutoff version, the interview slot, each panelist's locked rubric scores and recommendation, and the recruiter's final decision with the actor and time. What is shared with the student is a policy choice. Many institutes share stage-level outcomes but not individual panelist notes. The system should support both an internal full explanation and a student-facing summary. The key design requirement is that every selection decision references a recorded input and a named actor, so there is never a decision with no recorded reason.

Notifications are produced through an outbox after the publish commits, then fanned out by channel workers. SMS must use templates registered on the DLT platform under TRAI's regulations, with the registered header and template ID. Only the variable parts change, so templates are managed as configuration and the code cannot send free-form SMS. Each message has a deterministic idempotency key, such as drive, student, channel and template, so retries do not spam students. Workers apply provider rate limits and exponential backoff, and dead-letter permanent failures. Delivery receipts update status. In-app alerts are the reliable fallback, and the portal itself remains the source of truth for deadlines, not the SMS.

Generating resumes from structured fields keeps them consistent with verified data, so a student cannot claim a CGPA in the PDF that differs from the verified record. It also lets recruiters compare candidates in a uniform format. Each resume version is immutable and records which field versions and template it was rendered from. When a student opts in, the application pins a specific resume version ID. If the student later edits their profile, the recruiter still sees what was submitted, and the audit trail shows exactly what the recruiter saw. Free-text sections such as project descriptions can be student-authored, but verified fields are rendered only from locked values and are marked as verified.

The server's clock is authoritative, synchronised by NTP, and the deadline is stored in UTC with the display time zone, which is IST for most users. The opt-in write checks the deadline inside the same transaction that creates the application, so a request that started before the cutoff but committed after it is rejected consistently. Clients show a countdown but are never trusted. I would load-test the last-minute spike and keep the opt-in path lightweight, because a slow system at the deadline is itself unfair. If an outage occurs near the cutoff, the placement cell can extend the deadline for everyone as a logged, versioned change, rather than accepting individual late requests.

The edit creates a new pending version, and verification reopens. Existing snapshots and applications keep pointing to the old verified version, so in-flight drives are not disrupted by unverified data. For new drives, eligibility uses the last verified version until the new one is approved. The system flags the student's active applications so that the placement cell can see a pending change. If the change is a correction that makes the student ineligible, for example a newly reported backlog, the cell decides on in-flight applications through a logged action under a written policy. The change does not automatically eject the student, because that decision must be explainable and reviewed.

Our database is the source of truth for slot reservations. When the scheduler assigns a slot, it creates a tentative hold with a unique constraint on panel and time range, then calls the calendar API to create the event. If the call fails, a retry job reconciles it. Before assigning, it reads free/busy data, but free/busy can change after the read, so a nightly and pre-drive reconciliation compares our reservations with the external calendars and flags conflicts for rescheduling. Calendar writes use idempotency keys or stored external event IDs to avoid duplicates. Webhooks or push notifications from the calendar provider, where supported, help detect changes faster but do not replace reconciliation.

Every reschedule is an event with an initiator (student, panel or system), a reason code, free text and timestamps. Policies define limits, for example how many student-initiated reschedules are allowed per drive, and which reasons are always allowed, such as an exam clash or a medical issue. A no-show is recorded by the panel, but the student gets a short window to report a technical or genuine issue before the status becomes final. Reporting on reschedules by initiator lets the cell spot panels or recruiters that move slots repeatedly. The point is that outcomes like 'absent, not evaluated' are visible and contestable rather than silently rejecting candidates.

Because the engine is a pure function, it is very testable. I would keep a golden dataset of synthetic students covering boundary cases: CGPA exactly at the cutoff, rounding of CGPA values, zero versus one backlog, active versus cleared backlogs, dual degrees, lateral entry and mismatched graduation years. Property-based tests check invariants, for example that loosening a criterion never removes an eligible student. Every rule version change runs a diff report against the previous version on real verified data, which the placement cell reviews before approval. Engine code changes are versioned too, and the snapshot records the engine version, so a historical result can be reproduced exactly.

The change goes through the same approval as the original: a new rule version, approved by the placement cell, with the reason recorded. The engine produces a new snapshot linked to the previous one. Loosening criteria adds students, who get notified, and the deadline may be extended so that they get a fair window. Tightening criteria is more sensitive, because students may have opted in and taken assessments. Policy should either forbid it after opt-ins open or require explicit cell approval, with affected students informed of the reason. The old snapshot stays intact, so anyone can see who was eligible under each version and why the list changed.

Flags are evidence, not decisions. The vendor's flags and any snapshots are stored with the assessment result, and drive policy defines which flags trigger human review. A reviewer from the placement cell or the recruiter looks at the evidence and records a decision with a reason. Only then can a candidate be disqualified. Students should be able to respond, because false positives happen, for example from poor lighting, shared rooms or unstable connections. Proctoring media is sensitive personal data, so I keep it access-restricted, encrypted, and on a short retention period agreed with the vendor contract, and I share it only with the people who need to review it.

I separate identity and personal data from decision records. Audit events reference a pseudonymous student ID, and personal fields live in a separate store or are encrypted with per-student keys. When retention ends or deletion is legally required, I delete the personal data or destroy the key, which is called crypto-shredding, while the audit structure and aggregate statistics remain intact. Some records may need to be kept longer for legal or accreditation reasons. Those retention periods are defined with the institute's legal team and documented. Proctoring video and resume PDFs typically get shorter retention than offer records. Deletion jobs are themselves audited.

Not for everything. Full event sourcing gives perfect replay, but adds complexity in schema evolution, projections and debugging, and most of this system is simple CRUD with a strong audit need. I would use conventional tables as the operational state, with a transactional outbox that emits domain events into an append-only audit log. This gives me the explainability of an event log without forcing every read through projections. The offer and placement status path stays in a relational database with transactions, because that invariant needs strong consistency. Reporting is the one area that is naturally event-sourced, because metrics must be rebuildable and traceable from events.

First, I keep the acceptance path small and dependency-free. It touches only the offers and placement status tables, and notifications go out later through the outbox. Then a downstream outage cannot block acceptance. Requests carry idempotency keys, so a client retry after a timeout returns the original result instead of failing or double-processing. If the database is unavailable, acceptance fails cleanly and is not queued for later. A queued acceptance could violate the policy when replayed. The incident is logged, and the placement cell can extend offer deadlines as a recorded action. Monitoring alerts on the acceptance error rate during known deadline windows.

I would set availability and latency SLOs on student-facing write paths near deadlines: opt-in, acceptance and the scheduling confirmation. I would also track verification backlog age, because unverified students are silently excluded from drives. For integrations, I would watch webhook signature failures, reconciliation mismatches, SMS delivery rates and calendar sync conflicts. For correctness, I would run invariant checks as monitors: no student with more accepted offers than the policy allows, no application without a snapshot reference, and no evaluation readable before submission. Audit outbox lag shows whether events are reaching the audit log. Dashboards are split per drive, because problems usually show up in one drive at a time.

University results usually arrive as a file or API feed. I would stage each import as a batch with a checksum and source, validate the schema, and match records on enrolment number, not on name. The system then compares imported values with student-entered values field by field. Exact matches can be presented to the maker as pre-verified evidence, but they still go through maker-checker approval. Mismatches go to a review queue with both values shown. The import is idempotent, so reloading the same batch does nothing. A later corrected batch creates new field versions, which reopen verification. Every verified field links back to the batch ID and the row it came from.

1. ACheck that the request's User-Agent header matches the vendor name
2. BVerify a signature over the raw body using a shared secret or vendor public key, and check a signed timestampCorrect answer
3. CAccept requests only over HTTPS
4. DCompare the candidate's email in the payload with our database

Why: A signature over the raw body proves authenticity and integrity, and a signed timestamp limits replay. HTTPS and headers alone do not authenticate the sender.

1. AReject all retries after the first delivery attempt using an HTTP 400 response
2. BAsk the vendor to disable retries
3. CInsert each delivery and average the scores
4. DUse the vendor's event ID as an idempotency key with a unique constraintCorrect answer

Why: An idempotency key makes redeliveries harmless while still allowing at-least-once delivery. Retries are what make lost deliveries recoverable.

1. AUse a transactional outbox written in the same transaction, relayed to the queue afterwardsCorrect answer
2. BUse a distributed two-phase commit with the SMS gateway
3. CSend from the browser after the page reloads
4. DSend the notifications before committing the transaction

Why: The outbox couples the event to the database commit without needing the external system to join the transaction.

1. ALock the student's status row in a transaction and back it with a partial unique indexCorrect answer
2. BUse a client-side flag to disable the accept button after one click
3. CRun a nightly job that cancels duplicate acceptances
4. DCheck the student's status in the application, then insert the offer

Why: A row lock serialises the concurrent requests, and the unique index guarantees that a second accepted offer cannot be stored even if application logic fails. The other options either race or fix the problem too late.

1. AThe checker must be senior to the maker
2. BThe checker must be a different user from the maker, enforced server-sideCorrect answer
3. CThe maker can approve their own work if the document comes from DigiLocker
4. DThe checker only needs to approve rejections

Why: The control depends on two distinct people. Enforcing it only in the UI could be bypassed through the API.

1. AThe last verified value of the fieldCorrect answer
2. BIt skips the student and sends no result
3. CAn average of the old and new values
4. DThe new unverified value the student entered

Why: The engine evaluates verified data only. Using the last verified version keeps the outcome explainable from locked records.

1. AThe recruiter's email and the drive title
2. BA screenshot of the eligibility page
3. COnly the list of eligible student IDs
4. DThe rule-set version, engine version, and the field versions used, with per-criterion resultsCorrect answer

Why: Reproducing a decision requires the exact rules, logic version and input data versions. A bare list cannot explain why someone was excluded.

1. ANo, the API denies access until the panelist's own submission is lockedCorrect answer
2. BYes, but only the average score
3. COnly if the recruiter allows it per drive
4. DYes, as long as the UI hides them

Why: Independence must be enforced server-side. Hiding data only in the UI still leaks it to anyone using the API.

1. AAppend a new version with a reason and keep the originalCorrect answer
2. BAsk an admin to edit the database directly
3. CUpdate the locked row in place
4. DDelete the submission and resubmit

Why: Appending versions preserves history, so the correction and its timing stay visible in the audit trail.

1. AThe sent message must match a registered template, with only the declared variable parts changingCorrect answer
2. BTemplates are needed only for messages sent at night
3. COnly the sender's IP address must be registered
4. DAny message text is allowed if it is under 160 characters

Why: Under TRAI's commercial communication rules, messages are checked against registered templates and headers. Content outside the template is liable to be blocked.

1. AThe time the student clicked the button, sent by the client
2. BThe time the confirmation email arrives
3. CThe student's device clock
4. DThe server's synchronised clock, checked in the transaction that creates the applicationCorrect answer

Why: Client clocks can be wrong or manipulated. Checking at commit time gives a single consistent rule for everyone.

1. AEvery field in the student profile, including backlog history and verification notes
2. BApplicants of all drives in the same CTC band
3. CAll students in the batch, to source candidates
4. DOnly applicants who opted in to that recruiter's drives, limited to the fields needed and consented toCorrect answer

Why: Purpose limitation and data minimisation reduce privacy risk and match what students agreed to share.

1. ACreate a new rule version and a new snapshot linked to the old one, and notify newly eligible studentsCorrect answer
2. BIgnore the change until next season
3. CAdd the new students manually without recording a rule change
4. DEdit the existing rule set and snapshot in place

Why: Versioning keeps both lists explainable, and notifying new students gives them a fair chance to opt in.

1. AIn a nightly batch job
2. BIn the same transaction that records acceptance, with notifications sent after commitCorrect answer
3. COnly when the student withdraws them manually
4. DWhen the recruiter next logs in

Why: Doing it atomically prevents a window in which the student could progress in a blocked drive. Notifications can safely follow asynchronously.

1. AThe maker-checker identity check
2. BThe one-offer check during acceptance
3. CDashboards and placement statistics that tolerate slight lagCorrect answer
4. DThe opt-in deadline check

Why: Reporting tolerates staleness. Invariant checks must read from the primary inside the transaction to stay correct.

1. AKeep the frozen snapshot and allow a logged officer override with a reasonCorrect answer
2. BDelete the drive and republish it
3. CSilently re-run eligibility and add the student
4. DIgnore the change for all future drives

Why: Freezing the snapshot keeps the list explainable, and a logged override corrects the case fairly while keeping the audit trail complete. New drives use the corrected verified record automatically.

1. ATotal offers released
2. BAll students enrolled in the batch
3. CEligible students who opted into placementsCorrect answer
4. DStudents who attended at least one interview

Why: Eligible opted-in students reflect who the placement process actually served. Counting offers double counts students, and using the full batch includes those who chose higher studies or opted out.

1. AMaking the worker faster
2. BDisabling queue redelivery
3. CExactly-once delivery guaranteed by the queue
4. DA deterministic idempotency key checked against a sent-messages recordCorrect answer

Why: Queues typically deliver at least once. Deduplicating on a stable key makes reprocessing safe, although a crash between send and record can still rarely duplicate.

1. AThe Copyright Act, 1957
2. BThe Negotiable Instruments Act, 1881
3. CThe Right to Information Act, 2005
4. DThe Digital Personal Data Protection Act, 2023Correct answer

Why: The DPDP Act, 2023 sets obligations for processing digital personal data, including notice, consent and safeguards.

1. ANothing until the student re-applies
2. BBoth versions, merged into one document
3. CThe latest profile automatically
4. DThe pinned resume version that was attached at opt-inCorrect answer

Why: Pinning an immutable resume version makes the application auditable and prevents changes after the deadline.

1. AThe student's other drives' assessments and the academic exam timetableCorrect answer
2. BThe recruiter's office holidays only
3. CNothing else, because interviews always take priority over other commitments
4. DOnly the panelist's lunch break

Why: The workflow requires avoiding clashes with the student's other drives and exams, so both must be inputs.

1. ARetry until the calendar API returns success
2. BLet the panelist resolve conflicts manually
3. CRead the external calendar's free/busy status just before booking
4. DA unique constraint or exclusion constraint on panel and time range in our own databaseCorrect answer

Why: Our database is the source of truth and can atomically reject overlaps. Free/busy checks are racy and external.

1. AGive admins update rights so that they can fix mistakes
2. BStore it in the same table as operational data
3. CHash-chain records and periodically anchor the chain head in write-once storageCorrect answer
4. DCompress it daily

Why: Chained hashes reveal any alteration, and write-once anchoring prevents rewriting the chain undetected.

1. AAs custom scripts uploaded by each recruiter
2. BAs a declarative, versioned rule document evaluated by a single engineCorrect answer
3. CAs free-text notes interpreted by staff
4. DAs SQL queries pasted by the placement cell

Why: Declarative rules are reviewable, testable and reproducible. Arbitrary scripts and free text are hard to explain or audit.

1. AAppend a revocation event with actor and reason, and recompute placement status under the active policyCorrect answer
2. BChange the offer's CTC to zero
3. CMark the student inactive
4. DDelete the offer row

Why: Events preserve history for audit and statistics, and policy determines the student's resulting status.

1. ARoute the case to human review with the evidence, and record the decision and reasonCorrect answer
2. BDelete the score
3. CLower the score by a fixed percentage
4. DDisqualify the candidate automatically

Why: Flags can be false positives. A human decision with recorded reasons keeps selection explainable from the audit trail.

1. ARecalculate from the current table state only
2. BEstimate the change manually
3. CEdit the previously published numbers
4. DReplay audit events through a new versioned projection, and publish as a new report versionCorrect answer

Why: Deterministic replay with versioned definitions keeps old and new numbers traceable and reproducible.

1. ASend them synchronously in the publish request
2. BEnqueue them and let workers send within provider rate limits with backoffCorrect answer
3. CSend only email, to avoid SMS limits
4. DSpread the publish over several days

Why: Queueing decouples the publish from delivery and respects provider throughput limits without failing the publish.

1. AOnly the vendors' webhook endpoints
2. BOnly student accounts
3. CPlacement cell makers, checkers and admins who can verify data or change policyCorrect answer
4. DNone, because SSO is sufficient

Why: These roles can change records that drive eligibility and offers, so they are the highest-value targets.

1. AOverwrite names with asterisks in the audit log
2. BMove the data to a different cloud region
3. CDelete the audit events too
4. DKeep personal data encrypted with per-subject keys and destroy the key, while audit events use pseudonymous IDsCorrect answer

Why: Crypto-shredding makes the personal data unrecoverable without breaking append-only audit records.

1. AAs a versioned shortlisting rule or cutoff applied to complete results, with the actor and timeCorrect answer
2. BAs an email from the recruiter to the cell
3. CAs scores sorted in the UI
4. DAs a recruiter's spreadsheet uploaded without metadata

Why: A recorded rule applied to a complete result set lets every shortlist decision be explained and reproduced.

1. ACreate an application automatically
2. BQuarantine the event and alert for investigationCorrect answer
3. COverwrite the result of another candidate with the same name
4. DSilently drop the event without any record

Why: A valid signature does not make the mapping valid. Quarantining preserves evidence without corrupting application data.

1. AA student with CGPA 9.5
2. BA student with CGPA exactly 7.0, including stored rounding variantsCorrect answer
3. CA student with no CGPA field in a different batch
4. DA student in a branch outside the criteria

Why: Boundary values expose operator and rounding mistakes, such as greater-than versus greater-than-or-equal, which are a frequent source of unfair exclusions.