SF-Admin Object Manager and Lightning App Builder Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Set field-level security for the 'Hazardous' field to Visible for the appropriate profiles.

  Why this is correct

  Field-level security determines whether a user can see and edit a field. To control which users can see the 'Hazardous' checkbox based on their profile, the administrator must configure field-level security for that field on each profile. Profiles with Visible access will see it; profiles without will not. This is the standard mechanism for per-profile field visibility, and it directly satisfies the requirement stated in the scenario.

• ✗

  Add the 'Hazardous' field to a new page layout and assign the layout only to the profiles that should see it.

  Why it's wrong here

  Page layouts control which fields appear on the record detail page, but they do not grant or restrict access to the field itself. If field-level security allows a profile to see the field, that profile could still access it through reports, list views, or the API even if it is not on the page layout. The requirement is to control visibility based on profile, so field-level security is the correct mechanism, not page layout assignment alone.

• ✗

  Create a validation rule that checks the 'Hazardous' field value and prevents saving when the user is not in the correct profile.

  Why it's wrong here

  Validation rules enforce data quality at save time; they cannot hide a field from view. A user would still see the 'Hazardous' checkbox and could attempt to change it, only to be blocked on save. The requirement is to control visibility based on profile, which is a field-level security concern. Using a validation rule would create a confusing experience and does not meet the visibility requirement.

• ✗

  Create a Master-Detail Relationship field on Shipment__c to the Account object.

  Why it's wrong here

  A Master-Detail Relationship tightly couples the child record to the parent, making the parent required and controlling ownership, sharing, and deletion behavior. While it can relate a Shipment to an Account, it forces the Account to be required and changes the sharing model, which may not be desired. The requirement says 'relate to a single Account record' but does not require the strict ownership and cascade behaviors of master-detail, so this is not the best fit.

• ✓

  Create a Lookup Relationship field on Shipment__c to the Account object.

  Why this is correct

  A Lookup Relationship field allows a user to select one related record from another object. In this scenario, the administrator needs to relate a Shipment to a single Account, so a lookup to Account is appropriate. Lookups also support optional relationships and do not cascade delete by default, which matches the requirement to relate records without enforcing a master-detail dependency. This is the correct field type for the stated relationship need.