School & university management system

I'd separate authentication from authorisation. Keycloak handles login, with SSO for staff and OTP for parents. Authorisation then combines roles with relationships stored in the student system, such as guardian-of, teaches-section and advises-student. Every query is scoped by tenant_id through Postgres row-level security, and the service layer checks the relationship before returning a record, so a missing check in one endpoint cannot leak data across schools. Guardian links are created only from verified admission data, and changes to them need staff approval. Sensitive views like medical notes need an extra permission. Every read of personal data is logged so we can answer who saw what, which also supports DPDP obligations and parent grievances.

I would use a hybrid. Most schools share a database and a schema, and every table carries a tenant_id. Postgres row-level security enforces the tenant filter from a session variable that the gateway sets, so a missed WHERE clause in application code cannot leak rows across tenants. Large universities, or customers with contractual isolation or residency needs, get their own database, which a tenant routing table resolves. Shared schema keeps cost low and makes migrations simple across thousands of small schools. Dedicated databases limit the blast radius and noisy-neighbour risk for the big tenants. One codebase serves both models, because the data-access layer always resolves a connection from the tenant. Tests then confirm that no query can run without tenant context.

The mobile app writes each mark to local storage with a client-generated UUID. It also records the natural key (tenant, student, date, period), the teacher, the device time and a local sequence number. On sync it sends batches, and the server upserts on the natural key, storing the UUID so that a retried batch has no effect. When two devices submit the same period, I would not silently use last-write-wins. The rule is that the assigned teacher or a later explicit edit wins, and the server keeps the full history for audit. Late syncs still emit absence events, but the notification hub suppresses alerts once the school's cutoff has passed. Teachers see a sync status per class, so an unsynced register is visible instead of failing silently.

Results move through a state machine: draft, submitted, moderated, approved, locked, published. Teachers can edit marks only while the result is in draft. Submitting freezes that section's sheet. Moderation applies scaling or rechecks and records every change with its reason. The HOD or exam controller then approves, and the system enforces maker-checker, so the approver cannot be the person who entered the marks. Approval creates an immutable, versioned snapshot together with a content hash. Publication is a separate, scheduled action that refers to a specific approved version. The portal reads only from published snapshots and never from working tables. The publish commit and its outbox event are written in one transaction. Every transition is audited, and the service rejects any skipped state.

Results are read-heavy and immutable once published, so I precompute them. At publish time a job renders each student's result into a document or JSON blob in object storage, keyed by an unguessable token. The portal API checks authorisation, which is cheap because relationships are cached, and then returns the precomputed artefact or a short-lived signed URL. Nothing joins live marks tables. I would pre-scale the API tier and warm the caches ahead of the scheduled publish time. Tenants can also release results in staggered batches. Login, especially OTP, is often the real bottleneck, so I would raise SMS throughput in advance and keep existing sessions valid. Per-tenant rate limits stop one university's result day from affecting other tenants.

First, I create an order with an idempotency key before redirecting to the gateway. The client redirect only shows a pending state. The truth comes from the signed webhook: I verify the signature, deduplicate on the gateway payment ID, and post a double-entry ledger entry with the receipt in the same transaction, followed by an outbox event. Webhooks can be lost, so a scheduled job polls pending orders and runs a daily reconciliation against settlement reports, flagging mismatches for the accounts team. Refunds and concessions are new ledger entries, never edits to old ones. With this design, a user who retries or double-clicks cannot be charged twice or receive a false receipt.

Timetabling is a constraint optimisation problem, so I'd use a solver such as Timefold rather than hand-written rules. Hard constraints include no teacher or room double-booked, room capacity, lab requirements, and staff availability. Soft constraints include spreading a subject's lectures across the week, avoiding gaps for students, and respecting faculty preferences. The solver runs asynchronously within a time limit and produces a draft that admins can pin and adjust before publishing. After publishing I freeze it. Leave and room changes become substitutions or local re-solves with most assignments pinned, so students don't see their whole week reshuffle. Electives create student-level clashes, so I include enrolment data in the model.

Each programme or class has a seat inventory row that holds capacity, the number accepted and the number held. Accepting an offer runs one transaction. It checks that the offer is still valid and before its deadline, then increments the accepted count with a conditional update such as 'accepted < capacity'. A database constraint backs this up. If the update affects no rows, the applicant is waitlisted. Offers can deliberately exceed seats when a school expects some applicants to decline, but acceptances never can. When offers expire, a scheduled job releases the holds and moves to the next merit-list candidate. However, the acceptance transaction itself checks the deadline, so a late job never lets an expired offer through. The application fee and the acceptance fee use the normal ledger flow.

I would state the assumptions first. Say 2,000 tenants average 1,000 students each, which is 2 million students, with 8 periods a day. That gives about 16 million attendance records a day. Most of them arrive in a window of roughly six school hours, which averages around 750 writes per second. Marks come in bursts at the start of each period, so I would plan for perhaps ten times the average and design for 10,000 records per second. Batching each class register into one request cuts the request rate by about 40 times. Records are small, a few hundred bytes, so storage per day is single-digit gigabytes. That fits Postgres partitioned by month and tenant. Absence events are a fraction of the writes and drive the notification load.

I would use double-entry accounting. A journal_entries table records the header: tenant, timestamp, source type and source ID, such as a webhook event, and an idempotency key with a unique constraint. A journal_lines table holds each account, debit or credit, amount in paise as an integer, and currency, and the lines of every entry must balance to zero. The accounts include student receivable, gateway clearing, bank, concession expense and late-fee income. Invoices are a separate table that links to receivable lines. An invoice's paid status is derived from what has been allocated against it, not stored as a flag that someone can edit. Entries are append-only, and a correction is a reversal plus a new entry. Gateway settlement reports move money from clearing to bank, and any reconciliation difference goes to a suspense account for a person to review.

First, it checks each guardian's channel preferences and recorded consent before sending anything. It also respects quiet hours, except for urgent safety alerts. Second, Indian regulatory constraints apply. Commercial SMS must use TRAI DLT-registered headers and templates, and WhatsApp business messages need approved templates and user opt-in. Third, delivery must be reliable. The hub uses a dedup key of event ID, recipient and channel, retries with backoff, and fails over to another channel or provider. It records delivery receipts. Fourth, it localises messages, because guardians prefer different languages. Fifth, it protects privacy by keeping sensitive details, such as marks, out of SMS bodies and sending a link that requires login. Finally, it applies per-tenant quotas and cost tracking, since SMS volume costs money.

The Digital Personal Data Protection Act 2023 treats anyone under 18 as a child. Processing a child's data needs verifiable consent from a parent or lawful guardian, and the Act bars tracking, behavioural monitoring and targeted advertising aimed at children. The 2025 rules allow certain exemptions for educational institutions, but I would confirm the current scope with counsel rather than assume. In the design, consent records carry the purpose, the version and the guardian's identity. The system collects only the data each purpose needs and applies retention schedules. It supports access, correction and erasure requests where law permits, and it has a breach-response runbook. Analytics never profile children for marketing. The platform acts as processor for the school, which is the data fiduciary, so contracts and audit logs must support that relationship.

The guardian relationship is the source of truth in the SIS, and it has an effective-from date and a status. Revoking it commits the change and an outbox event in one transaction. The authorisation layer checks relationships at request time, using a cache keyed on user and student with a short TTL. The revocation event also invalidates that cache entry explicitly, so enforcement takes seconds rather than waiting for the TTL to expire. Active sessions and refresh tokens for that user are revoked for that student, and the system cancels pending notifications to the removed guardian. Sensitive changes like this require maker-checker approval and are audited. Previously sent documents cannot be recalled, so the school is warned that history is not retroactively hidden from the parent.

The gateway applies rate limits and concurrency quotas per tenant, with tiers by plan. Heavy work, such as bulk report generation, timetable solving, merit-list runs and statutory exports, goes to async job queues with fair scheduling per tenant, so one university's export cannot starve other tenants. Database protection comes from statement timeouts, separate read replicas for reporting queries, and the reporting store itself, which keeps analytics off the OLTP database. Metrics broken down by tenant show who is consuming resources. If one tenant keeps dominating, I would move them to a dedicated database or cell. Over time the deployment becomes cells, each holding a group of tenants, which limits the blast radius of any incident.

The locked version is never edited. Someone raises a correction request with a reason, for example after revaluation or because of a data-entry error, and attaches the changed marks. The request goes through the same moderation and approval path, and the approver must be different from the requester. Approval creates version N+1 with a link to version N and a diff. Publishing the new version marks the old one as superseded, while keeping it in the audit trail. The portal shows the current version with a note that it was revised, and downloaded marksheets carry a version number and a verification QR code or hash. The system sends a results.corrected event, so guardians are notified and downstream systems, such as scholarship or promotion logic, recompute from the new version.

External identifiers are not under our control. A new applicant may not have an APAAR ID yet. Numbers get entered wrongly and corrected later. Universities reissue enrolment numbers after a transfer. Some students never get certain IDs at all. If one of these were the primary key, every correction would cascade through attendance, the ledger, results and events. A surrogate ID, such as a UUID or ULID generated by the SIS, never changes, and external IDs sit in an identifiers table with type, value, verification status and validity dates. Each type has a uniqueness constraint per tenant where that makes sense. Events and the reporting store carry the internal ID or a pseudonym of it, which also keeps government identifiers out of logs and analytics.

The relay can crash after publishing a message but before marking the row as sent. That produces duplicates, so delivery is at-least-once and every consumer deduplicates on event ID. The relay can also fall behind, so I would alert on outbox lag and on the age of the oldest unsent row. Ordering matters for each student, so events are keyed by student or aggregate ID and the relay keeps commit order within a key. The outbox table grows without limit unless sent rows are purged or partitions are dropped. A CDC-based relay such as Debezium reads the outbox from the WAL, which avoids polling load. A poison event that a consumer keeps failing on goes to a dead-letter topic, and the consumer keeps processing other messages.

I would replace direct identifiers such as name, phone, APAAR and Aadhaar-linked fields with a keyed hash, an HMAC with a secret for each tenant, applied during CDC. Joins across tables still work because the same input always gives the same pseudonym. Free text such as remarks is dropped. Quasi-identifiers such as date of birth, pincode and category are made coarser where dashboards do not need full detail. Dashboards suppress small cells, for example by hiding counts below a threshold, so nobody can single out a student. Pseudonymised data is still personal data under the DPDP Act, so access is role-based and logged. Statutory exports that need real identities are produced through a controlled job that re-identifies under authorisation. The key never sits in the warehouse.

Once a timetable is published, people depend on it. Students, teachers and room bookings are planned around it. A full re-solve can move hundreds of slots to fix one absence, and the solver's objective does not value stability unless you model that explicitly. A substitution is local. It finds a free, qualified teacher for that slot, checks hard rules such as clashes and maximum load, and records it as an overlay with a date range, so the base timetable stays the same. Notifications go only to the people affected. A re-solve makes sense at term boundaries or after structural changes. Even then I would add a penalty for each change compared with the current timetable, so the new solution stays close to the old one.

Every read of sensitive resources, such as health notes, marks and documents, and every write produces an audit record. The record holds the actor, their role and relationship, the tenant, the resource, the action, the purpose, time, IP address and request ID. Records go asynchronously to an append-only store. The services themselves cannot delete or alter it, because it uses WORM object storage or hash chaining, where each batch includes the previous batch's hash. Logs never contain the personal data itself, only references to it. Retention follows the policy and the law. Schools can query who accessed a child's record, and alerts catch anomalies, such as a staff account reading hundreds of profiles outside its sections.

Each form is a versioned JSON schema with field types, validation rules, conditional visibility and document requirements, plus a UI layout. An application stores the form version it was submitted against, so later edits never make old submissions invalid. Fields that drive business logic, such as category, date of birth for age eligibility and the marks used for merit, are mapped to canonical attributes so that merit rules and reports work across schools. Other answers go into a JSONB column. Merit lists are configurable formulas, evaluated in a sandbox and versioned, and they can be explained per applicant. Tenants can publish a new form version only after a validation preview, and published versions are immutable.

The client asks for a presigned upload URL scoped to one object key, with limits on size and content type. The file goes straight to object storage, into a quarantine prefix. An event then triggers malware scanning and file-type verification, and optionally OCR. Only files that pass move to the clean prefix and become visible to staff. Files are encrypted at rest with tenant-scoped keys, and downloads go through short-lived signed URLs issued after an authorisation check. Each document is linked to the application and to a retention rule. Documents from rejected applicants are deleted after the retention period. Thumbnails or previews never go into public buckets, and every view is audited.

Each fee plan is a versioned rule set that resolves, by class, category and optional components such as transport, into an invoice schedule of instalments with due dates. Concessions and scholarships are separate ledger entries, debiting concession expense and crediting the receivable, so the original fee stays visible. A scheduled job posts late fees according to the plan's rules, and a waiver is a reversal approved by an authorised role. A partial payment is allocated across open instalments using a deterministic rule, oldest due first, unless staff override it. Because the paid amount is derived from allocations, dues dashboards always agree with the ledger. Changing a plan mid-year affects only future instalments. Invoices already issued are corrected through adjustments.

A grading scheme is a versioned configuration. It defines the assessment components and their weights, the mark-to-grade bands, grade points, rules for passing and grace marks, credit weighting and rounding. Each exam or course offering refers to a specific scheme version, so results are reproducible even after the rules change. Calculation runs in a pure, deterministic function that is unit-tested against reference examples the controller supplies. It stores the inputs and outputs together, and it records the scheme version in the result snapshot. Teachers enter raw marks against components, and grades are always derived. Universities add credit-based aggregation, backlogs and re-attempts as course attempts linked to the student and term.

I would set targets according to the cost of losing data. The fee ledger and results need an RPO near zero, which means synchronous replication within the region, point-in-time recovery and immutable backups that sit in a separate account to resist ransomware. Attendance can tolerate an RPO of minutes, because devices keep a local copy and can re-sync. The reporting store can be rebuilt from CDC or from snapshots. For RTO, the portal and payments should come back within an hour or so, while reporting can wait longer. Data residency in India constrains where the DR region can be. Restores are drilled regularly per tenant, because an untested backup is not a real backup. Per-tenant restore is a feature in its own right, because one school's accidental bulk delete should not require a platform-wide rollback.

Staff identity comes from the school's identity provider through SSO. SCIM provisioning, or an HR event, disables the account, and the gateway rejects their tokens. Short token lifetimes and session revocation close any remaining window. Section and subject assignments end on the leaving date. That date drives the teacher-of-section relationship, so attribute-based checks fail straight away even if a cached token survives. Records the teacher created, such as attendance, marks and remarks, keep the author reference for audit. Pending work, including unsubmitted mark sheets and substitutions, appears on an admin dashboard so it can be reassigned. Timetable slots trigger substitutions until a replacement teacher joins.

Each mark sheet, meaning one section and one assessment, carries a version number. Saves are conditional updates on that version, which is optimistic locking. If the version has changed, the save is rejected and the client shows the conflicting cells so the user can merge them. Pessimistic locking would hold locks across slow mobile sessions, so I would avoid it. Only the assigned teacher can edit, so true conflicts are rare. They come mostly from the same teacher on two devices, or from a co-teacher. Each cell edit is recorded in history. Once the sheet is submitted, it is frozen, and later changes go through moderation, which removes the risk of concurrent edits during approval.

I would tie SLOs to user journeys. Examples are portal login and page success rate and latency, attendance sync success, the gap between the cutoff and the parent absence alert, the time from payment to receipt, and the result publish completing on schedule. Alerts would cover outbox and consumer lag, webhook verification failures, reconciliation mismatches, and receipts stuck in a pending state, plus notification delivery failure rates per provider and channel and authorisation denials that spike unexpectedly. I would also monitor invariants as well as uptime. Ledger entries that do not balance, a published result without an approved version, and cross-tenant query attempts that RLS blocks should each page someone immediately, because they signal a correctness or security bug.

Kafka guarantees order only within a partition, so I would choose keys by the aggregate whose order matters. Attendance and SIS events use the student ID as the key, so a student's enrolment change is never processed after a later attendance mark. Payment events use the invoice or payment ID. Keys combine the tenant and the ID, which spreads load while keeping order. I would avoid using the tenant alone as the key, because one big university would create a hot partition. I would size partition counts for peak throughput, with headroom for consumer parallelism. Consumers still check versions or timestamps, because retries and the outbox can deliver duplicates. Cross-aggregate ordering is not guaranteed, so workflows rely on state checks rather than on events arriving in order.

I would provide import templates and a staged pipeline. The pipeline uploads the data, validates it against canonical schemas, and shows the school an error report and a preview. Only then does it commit, in idempotent batches keyed by a source record ID, so the import can be re-run safely. Students, guardians and relationships are imported first, then historical fees as opening balances in the ledger rather than replayed transactions, and then past results as archived read-only records. Guardian contact numbers need verification and consent before the system sends notifications. The tenant stays in a sandbox mode until the school signs off, so test notifications never reach real parents.

The student's identity and internal ID stay the same. What changes is the enrolment, which I model as an effective-dated record of student, section, term, valid from and valid to. A move closes the old enrolment and opens a new one. Attendance, marks and timetable lookups resolve the section that applies on the relevant date, so history is preserved correctly. Teachers of the old section lose access from the move date, apart from completing assessments for the period they taught, which is an explicit exception scoped by time. Fee differences between campuses produce ledger adjustments. Moving between separate tenants is a formal transfer, with an export, guardian consent, and APAAR serving as the portable record.

I would check the hard constraints independently of the solver. A separate, simple checker confirms there are no teacher, room or section clashes, that teacher availability and required periods per subject are respected, and that rooms suit the subject, such as labs. The checker runs on every draft before an admin sees it. I would use property-based tests with generated instances, and a regression suite built from real anonymised tenant datasets, tracking soft-constraint scores and solve time. For infeasible inputs, the solver should report which constraints conflict instead of timing out silently. Solves run as async jobs with time limits and return the best solution found so far, and admins can pin slots before re-solving.

I would use a schema registry with Avro or Protobuf and enforce backward compatibility, so new fields are optional with defaults, nobody removes or reuses fields, and types do not change incompatibly. Events carry an envelope with event ID, type, version, tenant, aggregate ID and occurred_at. For a breaking change I would publish a new event type or topic version, run the old and new in parallel, migrate consumers, and then retire the old one. Consumers ignore fields they do not know. Contract tests in CI check producers against the schemas that consumers expect. Payloads carry IDs rather than full personal data where possible, which also shrinks the privacy impact of a long-retention topic.

1. AAdding an index on tenant_id
2. BPrefixing table names per tenant
3. CRow-level security policies driven by a session tenant variableCorrect answer
4. DEncrypting the tenant_id column

Why: RLS enforces the tenant filter in the database for every query, so a bug in application code cannot bypass it.

1. ANatural key (tenant, student, date, period) with an upsertCorrect answer
2. BAuto-increment row ID
3. CServer receive timestamp
4. DDevice ID only

Why: Upserting on the natural key means a repeated sync overwrites the same logical record instead of inserting a duplicate.

1. AVerifying the HMAC signature with the shared secretCorrect answer
2. BChecking that the request came over HTTPS
3. CChecking that the amount is positive
4. DChecking the User-Agent header

Why: Signature verification proves the gateway sent the payload and that nobody tampered with it.

1. AFix it only in the reporting store
2. BEdit the locked marks directly as an admin
3. CCreate a new version that goes through approval and supersedes the old oneCorrect answer
4. DDelete the result and re-enter it

Why: Locked versions are immutable, so corrections need a new approved version with an audit link to the previous one.

1. AThe browser redirect back from the payment page
2. BA verified gateway webhook or reconciliation recordCorrect answer
3. CThe parent uploading a screenshot
4. DThe payment button being clicked

Why: Only a signature-verified server-side webhook, or a match in the settlement reconciliation, confirms that money actually moved. Redirects can be lost or forged.

1. ATransactional outboxCorrect answer
2. BClient-side retry
3. CCron-based polling of the UI
4. DDual write to the database and Kafka

Why: The outbox writes the event in the same database transaction as the result, and a relay publishes it afterwards. This avoids lost or phantom events.

1. ACheck the seat count in the UI before submitting
2. BA conditional update such as 'accepted < capacity' inside the acceptance transactionCorrect answer
3. CA nightly job that cancels excess acceptances
4. DCaching the seat count in Redis with a TTL

Why: An atomic conditional update in the database serialises concurrent acceptances against the real count.

1. AAmounts are stored as floats
2. BTotal debits equal total creditsCorrect answer
3. CEach entry has exactly one line
4. DCredits always exceed debits

Why: Double-entry requires each entry to balance, which makes errors and missing money detectable.

1. AEdit the receipt PDF
2. BUpdate the amount on the existing line
3. CDelete the entry and repost it
4. DPost a reversal entry, then a correct entryCorrect answer

Why: Ledgers are append-only, and reversals keep a complete, auditable history.

1. AThe tenant ID alone
2. BA tenant-qualified student IDCorrect answer
3. CA random UUID
4. DThe event type

Why: Kafka orders messages within a partition, and keying by student sends all of a student's events to one partition without creating tenant-level hot spots.

1. AVerifiable consent of a parent or lawful guardianCorrect answer
2. BThe student's own click-through consent
3. CNo consent, because schools are exempt from the whole Act
4. DOnly an internal policy document

Why: The Act treats people under 18 as children and requires verifiable parental consent, subject to notified exemptions.

1. AAt-most-once
2. BNo ordering at all
3. CAt-least-once, so consumers must be idempotentCorrect answer
4. DExactly-once by default

Why: The relay can publish and then crash before marking the row sent, which causes redelivery.

1. AServe precomputed per-student results after an authorisation checkCorrect answer
2. BDisable authentication to reduce load
3. CJoin the live marks tables for each request
4. DEmail all results instead of using the portal

Why: Published results are immutable, so precomputing removes expensive queries while access control stays in place.

1. AA nightly batch job
2. BWaiting for the access token to expire after 30 days
3. CChecking relationships at request time and invalidating the cache through a revocation eventCorrect answer
4. DAsking the parent to log out

Why: Request-time checks combined with event-driven cache invalidation close the access window within seconds.

1. AAsk the user to pay again
2. BKeep the payment pending and confirm it through the gateway's status API or reconciliationCorrect answer
3. CCancel the order immediately
4. DMark the invoice paid based on the redirect URL

Why: Only verified server-side confirmation should post to the ledger, and polling or reconciliation covers lost webhooks.

1. A160 million
2. B16 thousand
3. C16 millionCorrect answer
4. D1.6 million

Why: 2,000 × 1,000 = 2 million students, and 2 million × 8 periods = 16 million records.

1. AAsking the tenant to export at night
2. BPer-tenant quotas and fair-scheduled async job queuesCorrect answer
3. CBigger instances for everyone
4. DDisabling exports

Why: Per-tenant limits and fair queuing stop one tenant from consuming shared capacity.

1. ARBAC cannot handle logins
2. BRoles cannot express per-record relationships like guardian-of a specific studentCorrect answer
3. CRBAC is too slow for schools
4. DRBAC does not support mobile apps

Why: Every parent has the same role, so access to a specific child's records must be decided by relationship or attribute checks on each record.

1. AMessage body hash only
2. BEvent ID + recipient + channelCorrect answer
3. CRecipient phone number only
4. DSend timestamp

Why: It suppresses repeated sends of the same event to the same person on the same channel, while still allowing different channels.

1. ARegistered sender headers and templates on TRAI's DLT platformCorrect answer
2. BAn Aadhaar link for each recipient
3. CNothing, if the parent provided the number
4. DOnly a GST registration

Why: TRAI's regulations require DLT registration of entities, headers and templates, and operators block unregistered messages.

1. AIt can be shared publicly
2. BIt needs no retention policy
3. CIt is anonymous, so privacy law no longer applies
4. DIt is still personal data, and access must be controlled and loggedCorrect answer

Why: Pseudonymised data can be re-identified with the key or with other data, so it remains personal data.

1. AA teacher cannot be scheduled in two places in the same periodCorrect answer
2. BTeachers prefer free first periods
3. CHeavy subjects should be in the morning
4. DMinimise gaps between a teacher's classes

Why: A teacher clash makes the timetable infeasible, while the other options are preferences scored as soft constraints.

1. ACancel the classes automatically
2. BRe-solve the whole timetable
3. CUnpublish the timetable
4. DApply a dated substitution overlay for the affected slotsCorrect answer

Why: Substitutions are local and keep the published base timetable stable.

1. ADatabases cannot index strings
2. BIt changes every academic year
3. CIt may be missing, entered wrongly or corrected laterCorrect answer
4. DIt is always longer than 64 characters

Why: External IDs are outside the platform's control, and a stable surrogate key avoids cascading updates.

1. ASending the OTP by email as well
2. BAllowing unlimited attempts
3. CShort OTP expiry plus per-number and per-IP attempt limitsCorrect answer
4. DLonger SMS text

Why: Short validity and attempt limits make guessing the OTP infeasible.

1. ATable-level locks held during editing
2. BDisabling mobile entry
3. COptimistic locking with a version numberCorrect answer
4. DLast write wins silently

Why: A conditional update on the version detects the conflict without holding locks during long sessions.

1. ARely on the applicant's device clock
2. BAllow it and fix it manually
3. CRun the expiry job more often
4. DThe acceptance transaction itself checks the offer deadlineCorrect answer

Why: The authoritative check must happen at the point of acceptance and must not depend on a background job's timing.

1. ASMTP
2. BOAuth device flow
3. CLDAP referrals
4. DSCIMCorrect answer

Why: SCIM is the standard protocol for syncing user lifecycle changes, such as disabling a user, from an IdP.

1. AUpload to a public bucket and share the link
2. BBase64 in the form submission stored in the database
3. CPresigned upload to quarantine, malware scan, then move to private storageCorrect answer
4. DEmail documents to the admissions office

Why: It limits the scope of the upload, blocks malicious files, and keeps documents private behind authorised access.

1. AHash-chaining batches or storing them on WORM object storageCorrect answer
2. BLetting admins edit entries
3. CStoring it in the same table as the data
4. DGzip compression

Why: Chained hashes or write-once storage expose any alteration or deletion.

1. ASmall-cell suppression, hiding counts below a thresholdCorrect answer
2. BShow names to help follow-up
3. CRound the count up to 10
4. DExport the data to a spreadsheet

Why: Very small counts can identify individuals, so suppression prevents re-identification.

1. ARedis Streams
2. BDebeziumCorrect answer
3. CLogstash
4. DAirflow

Why: Debezium is a log-based CDC connector that reads the Postgres WAL through logical decoding.

1. ARemoving a required field
2. BRenaming a field
3. CAdding an optional field with a defaultCorrect answer
4. DChanging a field from string to integer

Why: Existing consumers can ignore the new optional field, and old messages still deserialise correctly.