SF-Data-Arch Salesforce Data Management Practice Question
Which security feature should an architect use to restrict access to sensitive fields based on a user's role?
⚠ Common exam trap
Candidates often confuse Field-Level Security with Page Layouts. While layouts hide fields from the UI, they do not restrict access at the API or report level, leading to potential data exposure.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Field-Level Security (FLS).
Field-Level Security (FLS) is the correct mechanism for controlling field access by profile or permission set. It ensures that users only see and interact with data relevant to their role. By applying FLS, architects can enforce strict data access policies, which is essential for compliance and maintaining the 'need-to-know' principle in complex, multi-departmental Salesforce environments where data privacy is paramount.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Organization-Wide Defaults (OWD).
Why it's wrong here
OWDs control record-level access (which records a user can see), not field-level access (which fields on a record a user can see). Using OWDs for field restrictions is architecturally incorrect and ineffective, as users would still have access to the fields if they have access to the record itself.
- ✓
Field-Level Security (FLS).
Why this is correct
Field-Level Security provides the precise control needed to restrict visibility to specific fields on an object based on a user's profile or permission set. It is the standard platform feature for ensuring that sensitive data is only accessed by users authorized to view it, maintaining robust security posture.
- ✗
Sharing Rules.
Why it's wrong here
Sharing Rules are designed to expand record-level access to users who otherwise would not see the record. They do not have any capability to hide specific fields on a record. Therefore, they cannot be used to restrict access to sensitive fields, making them unsuitable for this specific security requirement.
- ✗
Role Hierarchy.
Why it's wrong here
Role Hierarchy manages record-level access, allowing users higher in the hierarchy to see records owned by those below them. It does not provide any mechanism for restricting or granting access to individual fields. Relying on the role hierarchy to handle field visibility is a fundamental misunderstanding of Salesforce data security.
About these practice questions
One of 222 original SF-Data-Arch practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-Data-Arch practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-Data-Arch exam.