An open-data portal must publish sanitized dataset metadata through Data API builder without exposing base tables that still hold PII. What should they expose?
Select an answer to reveal the explanation.
Short Explanation
You can think of read-only views as the public gallery and PII base tables as the locked records room. Expose the views through DAB, and keep the sensitive tables out of the API.
Full Explanation
An open-data portal needs to publish sanitized dataset metadata without exposing base tables that contain PII. Expose read-only views through Data API builder (DAB) while keeping the PII base tables hidden from the API. Views let portal users query the intended metadata shape while sensitive resident identifiers remain outside the API surface, applying least privilege at the entity boundary—a security principle emphasized in DP-800 for Azure SQL API exposure. Publishing every base PII table as a writable DAB entity exposes identifiers and allows changes through the portal API, failing both confidentiality and integrity. Granting anonymous db_owner lets portal users query any table and gives them excessive privileges; db_owner is not an appropriate open-data access pattern. Sending weekly CSV exports containing residents’ full identifiers to approved portal users does not provide a sanitized open-data interface and exposes sensitive identifiers in the extracts. Exam caveat: when a question contrasts public metadata with PII-bearing base tables, choose read-only views through DAB and omit the base tables from the API; writable PII entities and anonymous elevated rights are unsafe. Practical check: create a view without PII columns, register only that view as a read-only DAB entity, verify that API requests cannot access the PII base tables, and review role mappings to ensure portal identities cannot escalate to those tables.