A county hosts analytics for several townships on one shared platform. What multi-tenant concerns must the architecture address?
Select an answer to reveal the explanation.
Short Explanation
Shared county gear is thrifty, but townships still need fences and fair shares. Quotas and isolation keep one noisy neighbor from wrecking everyone else’s night.
Full Explanation
A county platform hosting analytics for several townships must address multi-tenant concerns head-on: quotas, isolation boundaries, and tenant-aware access controls so one township cannot starve cluster capacity or expose another’s sensitive parcels, assessments, or case data. Shared infrastructure is fiscally sound for regional government only when fences and fair shares protect each civic tenant’s confidentiality and performance. Giving every township unrestricted write access to every other township’s raw lake folders maximizes cross-contamination and accidental overwrite risk across legal jurisdictions. Forcing all townships to share one service account with no quotas eliminates accountability and allows noisy-neighbor failure during peak assessor or tax season. Removing encryption so cross-township joins run slightly faster trades measurable security for marginal performance and typically violates municipal and county policy. Exam caveat: multi-tenancy is about isolation, identity, and fairness—not merely co-locating folders on one physical Hadoop cluster. Operational check: configure per-township quotas and namespaces or databases, enforce separate principals and encryption keys where required, penetration-test that township A cannot list township B’s sensitive paths, and review capacity alerts before seasonal crunch weeks.