Salesforce Security Model Interview Questions and Answers

Security and data model questions open almost every Salesforce Developer and Administrator interview, usually in the first technical round, before anyone looks at your Apex. The panel wants to know whether you understand how the platform is put together and how a record reaches a user. Seventeen questions follow, grouped the way an interviewer moves through them: platform architecture first, then record access, then object and field access. Each answer gives the definition, the reason it matters on a real project, and a worked example where the question deserves one.

How the platform is built

1. Explain Salesforce multitenant architecture.

Salesforce runs one instance of its software and one physical database for many customers at the same time. Your org is not a separate installation. It is a logical partition inside shared infrastructure, identified by an Organization ID that is stamped on every row of data and every piece of metadata you create.

Three consequences matter in an interview.

The first is isolation. You never query another tenant's data because the platform's query engine adds the Org ID filter below your SOQL. You cannot switch it off.

The second is governor limits. Because CPU, heap and database time are shared, the platform caps what a single transaction can consume. Governor limits are not an annoyance invented to fail your code. They are the mechanism that stops one tenant from starving the rest.

The third is upgrades. Salesforce releases three times a year and every tenant moves at the same time. You cannot stay behind on an older version, so customisations have to survive an upgrade you do not control.

2. What is metadata-driven architecture?

On Salesforce, the things you build are stored as data about the application, not as compiled objects in a database schema. When you create a custom object with ten fields, the platform does not run a CREATE TABLE statement. It writes rows into internal metadata tables that describe the object, its fields, its types and its relationships, and the values land in a shared data store.

At runtime, the platform reads that metadata and materialises the object: it builds the page, generates the underlying query, applies validation and enforces security. This is why a field created in the Setup menu is available in the API, in reports and in SOQL within seconds, with no deployment.

It is also why upgrades are non-breaking. The platform upgrades the runtime engine. Your metadata stays as it is and the new engine interprets it.

The practical follow-up is usually about deployment. Because everything is metadata, everything is retrievable as XML through the Metadata API, which is what change sets, SFDX source format and any CI pipeline operate on.

16. Difference between Sandbox types.

A sandbox is a copy of your production org's metadata, with or without data, used for building and testing. Four types exist and interviewers expect you to pick the right one for a scenario.

The detail that separates a prepared candidate from an unprepared one is the refresh interval, because it drives release planning. A Full sandbox cannot be refreshed for 29 days, so if your release rehearsal environment goes stale mid-cycle you cannot simply rebuild it.

Two more points worth knowing. Partial Copy uses a sandbox template that you define, choosing which objects to sample. And in every sandbox, user email addresses are scrambled and outbound email is deactivated by default, so nobody receives a test notification meant for a customer.

17. What is My Domain?

My Domain gives your org its own subdomain, in the form yourcompany.my.salesforce.com, instead of a shared instance URL. It is mandatory for all orgs now, and it is a prerequisite rather than a convenience.

You need it for Lightning components, for single sign-on and any external identity provider, for social sign-on, for branding the login page, and for login policies such as blocking users who bypass the custom domain. It also makes your URLs stable, because the org is no longer identified by the instance it happens to sit on.

For a developer, the relevant part is that My Domain names appear in your callout endpoints, your Connected App callback URLs and your Named Credentials. A domain change breaks every hard-coded URL in the org, which is one more reason to use Named Credentials instead of storing endpoints in code.

18. What is Salesforce Trust?

Trust is Salesforce's public transparency service at trust.salesforce.com. It publishes live system status per instance, planned maintenance windows, incident history with root cause summaries, performance data and security advisories.

You use it in two situations. The first is triage. Before you open a support case because users report that the org is slow, you check the status of your instance, which you find in Setup under Company Information. The second is release planning, because maintenance windows and release dates are published there.

Interviewers ask this to see whether you have actually worked in a running org. A candidate who has been on a live support rotation names Trust immediately. A candidate who has only done training exercises usually has not heard of it.

19. Explain Org Limits.

Org limits are the allocations your org gets as a whole, as distinct from governor limits, which apply to a single transaction. They cover data storage, file storage, API calls in a rolling 24 hour window, daily mass email allocation, single email limits, the number of custom objects and custom fields, permission sets, and asynchronous Apex executions per day.

Interviewers usually want to see that you know the difference and that you know where to read the current consumption. Three places to name:

• Setup, under Company Information for storage and under System Overview for object, code and API usage
• The REST resource /services/data/vXX.X/limits, which returns current usage and maximum for each limit
• The OrgLimits Apex class, which exposes the same information inside Apex

// Read the org's current limit consumption from Apex
Map<String, System.OrgLimit> limits = OrgLimits.getMap();
System.OrgLimit apiCalls = limits.get('DailyApiRequests');
System.debug(apiCalls.getValue() + ' of ' + apiCalls.getLimit() + ' API calls used');

The reason this comes up is integrations. An integration that polls Salesforce every minute burns the daily API allocation, and when it runs out, every inbound call fails until the window rolls. Knowing where to check that is basic production hygiene.

20. What is Hyperforce?

Hyperforce is Salesforce's infrastructure architecture that runs the platform on public cloud providers instead of only on Salesforce's own data centres. The application you use does not change. What changes is what it runs on.

It matters for three reasons that come up on real projects.

Data residency is the first. Hyperforce lets an org be provisioned in a specific country or region, which is how customers meet local data residency requirements. For Indian customers this is the direct answer to "where does our customer data physically sit".

Elastic scale is the second. Capacity is added from the underlying cloud provider rather than from a fixed data centre footprint, so peak load is handled without an instance migration.

Security posture is the third. Hyperforce is built on a zero trust model with encryption in transit and at rest as the default rather than an add-on.

For a developer, the practical effect is that Hyperforce orgs use My Domain based URLs, so any code or integration that assumed a fixed instance URL such as na85.salesforce.com has to be corrected. That is the migration work most projects actually did.

What the interviewer is actually checking

• Whether you can explain multitenancy as the reason governor limits and three annual releases exist, rather than reciting a definition of the word
• Whether you know that metadata is why a field is live the moment you save it and why the Metadata API is what every deployment tool talks to
• Whether you pick the right sandbox for a scenario, including the refresh interval, instead of naming all four
• Whether you have used Trust, System Overview and the limits endpoint on a live org, which is the difference between support experience and training exercises

The record access model

This is the section that decides the round. The panel will keep asking until you either describe the layers correctly or contradict yourself.

4. Explain OWD and its impact on security.

Organisation-Wide Defaults set the baseline record access for each object, for users who do not own the record. OWD is the most restrictive layer, and everything after it can only open access up.

The settings are:

The design rule is the one interviewers listen for. Set OWD to the most restrictive level any user should have, then grant access outward with the layers above it. Do not start at Public Read/Write and try to take access back, because nothing in the sharing model takes access back.

You also set separate internal and external OWD, so a community or Experience Cloud user can be Private on Account while internal users are Public Read Only.

3. Difference between Role Hierarchy and Sharing Rules.

Both grant record access. They differ in shape and in what they are for.

Role hierarchy answers "my manager should see my deals". Sharing rules answer "the Mumbai support team should see all Bengaluru cases even though nobody reports to anybody".

Two details that separate levels of candidate. Grant Access Using Hierarchies can be cleared only on custom objects; on standard objects the hierarchy always grants. And criteria-based sharing rules recalculate when the record is edited, so a case moving from Industry = Retail to Industry = Banking silently changes who can see it.

5. How does record-level security work?

Record-level security is the answer to "can this specific user open this specific record". It is calculated as a stack of layers, and the rule that governs the whole stack is this: OWD is the floor, every layer above it only grants access, and the user ends up with the highest level of access any single layer gives them.

Everything except the last row only adds. If a user can see a record they should not see, the fix is never "add a rule to block them". The fix is to find the layer that granted it.

Two things sit outside this stack and override it. The View All and Modify All object permissions ignore sharing for that object, and View All Data and Modify All Data ignore sharing for the whole org. That is why an administrator sees everything and why those permissions are audited.

Worked example

Take an org with Account OWD set to Private.

• Priya is a sales rep in the role Sales Rep West and owns the Account "Kirloskar Systems", Industry = Banking
• Rahul is Sales Manager West, directly above Priya in the role hierarchy
• Sneha is a service agent in a completely separate branch of the hierarchy, and is a member of the public group Banking Desk
• A criteria-based sharing rule shares Accounts where Industry equals Banking with the public group Banking Desk, Read Only
• Vikram is a finance analyst whose permission set grants View All on Account

Now walk the record:

1. OWD Private means nobody except Priya has access yet. This is the floor.
2. Role hierarchy gives Rahul the same access Priya has, so Read/Write. Nothing was configured for him. It came from his position.
3. The sharing rule gives Sneha Read Only, because the record's Industry matches the criteria.
4. Manual sharing: Priya opens the record, clicks Sharing and grants Sneha Read/Write for a specific escalation. Sneha now has Read Only from the rule and Read/Write from the manual share. She ends up with Read/Write, because the highest grant wins.
5. Apex sharing: a trigger inserts an AccountShare row granting the Compliance queue Read access with a custom row cause. That adds Read for those users. It removes nothing from anyone.
6. Vikram sees the record regardless of every row above, because View All on Account bypasses sharing.

Now change one thing. Priya edits the Account and sets Industry to Manufacturing. The criteria-based sharing rule no longer matches, so the rule-based Read Only share is removed on recalculation. Sneha still has Read/Write, because the manual share was not created by the rule and is not removed with it. That behaviour, shares created by different mechanisms being removed independently, is the follow-up question that catches people out.

One more practical point. If Sneha's profile has Read but not Edit on the Account object, the Read/Write manual share gives her nothing extra. Object-level permission is the ceiling and sharing cannot raise it. Sharing decides which records; the profile or permission set decides what you may do to an object at all.

This is the answer where memorised definitions collapse. Our trainers see it every batch: a candidate recites the five sharing mechanisms correctly and then goes quiet on "a user can see a record they should not, how do you find out why". The answer to that is to open the record, use the Sharing button to view who has access, check the reason column against each layer above, and confirm whether the user holds View All or Modify All. If you can debug the stack, you know the stack.

What the interviewer is actually checking

• Whether you say clearly that sharing only grants and never removes, and that restriction rules are the one exception
• Whether you can name the layers in order from OWD outward and say what each one adds
• Whether you know the highest grant wins when two layers apply to the same user
• Whether you know object permission is the ceiling, so a Read/Write share is useless without Edit on the object
• Whether you can debug a real access question instead of reciting the list

Object and field access

6. Difference between Profiles and Permission Sets.

A profile is the baseline. Every user has exactly one, it is mandatory, and it defines the starting point for object permissions, field permissions, tab visibility, app access, record type defaults, page layout assignment in Classic, login hours and login IP ranges.

A permission set is additive. A user can have many, they are optional, and they grant permissions on top of the profile. They cannot take a permission away.

The design pattern interviewers want to hear is a minimal profile plus permission sets for everything else. If Sales and Sales with export rights differ by one permission, you do not clone the profile. You create one permission set with that permission and assign it to five people. Cloned profiles are how orgs end up with forty profiles that nobody can audit.

7. What are Permission Set Groups?

A permission set group bundles several permission sets and assigns them as one unit, so you can model a job role. A "Senior Sales Executive" group might contain the permission sets for Opportunity Management, Quote Approval, Report Builder and Data Export.

The feature that makes groups more than a convenience is the muting permission set. Inside a group you can add a muting permission set that switches off specific permissions granted by the sets in that group, for members of that group only. So you can reuse the Report Builder set everywhere and mute Export Reports for one job role, without creating a second variant of the set.

Two limits on muting worth stating. The mute applies only within that group; if the user gets the same permission from another group or a direct assignment, they still have it. And muting is the only subtractive construct in the permission model, which is consistent with the rest of the platform.

8. What is Field-Level Security?

Field-level security controls, per field and per profile or permission set, whether a user can read the field, edit it, or see it at all. It is enforced in the user interface, in reports and list views, in search, and in the API.

The interview point is where it is not enforced automatically. Apex runs in system context by default, so a plain SOQL query returns fields the running user cannot read, and a plain DML statement writes fields the running user cannot edit. You have to ask for enforcement.

// Enforce the running user's object and field permissions on the query
List<Account> accts = [
    SELECT Id, Name, AnnualRevenue
    FROM Account
    WHERE Industry = 'Banking'
    WITH USER_MODE
];

// Enforce them on DML as well
Database.insert(accts, AccessLevel.USER_MODE);

// Or strip fields the user cannot access before using the records
SObjectAccessDecision decision =
    Security.stripInaccessible(AccessType.READABLE, accts);
List<Account> safeAccts = (List<Account>) decision.getRecords();

Note that with sharing on a class controls record-level sharing only. It does not enforce field-level security or object permissions. Candidates conflate the two constantly, and the panel is listening for exactly that.

9. Difference between Standard and Custom Objects.

The two rows that come up as follow-ups are the master-detail row and the hierarchy row. A standard object cannot be the child in a master-detail relationship, so if the requirement is "an Account must cascade delete its related records", the related object has to be custom. And Grant Access Using Hierarchies can only be cleared on custom objects, which is how you build a flat access model for something like a Compensation Record that managers should not see.

10. What is a Lookup vs Master-Detail relationship?

Both relate a child record to a parent. Master-detail makes the child dependent on the parent; lookup leaves the child independent. This is the comparison to know precisely, because it is asked in almost every round.

Say it in that order and you have answered the question completely: no owner, sharing inherited from the parent, cascade delete, roll-up summaries, reparenting off unless you turn it on.

The conversion rules are the usual follow-up. You can convert master-detail to lookup only if no roll-up summary fields exist on the master. You can convert lookup to master-detail only if every existing child record has that field populated, because the detail field cannot be blank.

The design consequence is the part candidates miss. Choosing master-detail is a security decision, not only a data decision. You have given away the ability to share the child record separately, forever, until you convert the relationship back.

11. What are Junction Objects?

A junction object is a custom object with two master-detail relationships, used to build a many-to-many relationship between two other objects.

The standard example is Position and Candidate in a recruiting app. One position has many candidates, one candidate applies to many positions. You create a junction object, Job Application, with a master-detail to Position and a master-detail to Candidate. Each Job Application row represents one candidate applied to one position, and it can carry its own fields such as Application Date, Stage and Interview Score.

The detail that gets asked is the primary relationship. The first master-detail you create is primary, and it determines:

• The junction record's ownership and sharing, because the junction object has no owner of its own
• The look and feel of the junction record, including which parent's detail page it inherits
• The report type layout when you report on the relationship

Cascade delete works from both parents. Deleting either the Position or the Candidate deletes the Job Application rows that reference it. And because a junction object already uses both of its two permitted master-detail relationships, you cannot add a third.

12. Explain Schema Builder use cases.

Schema Builder is a drag-and-drop canvas in Setup that shows objects, their fields and the relationships between them as an entity diagram, and lets you create objects, fields and relationships directly on the canvas.

Four use cases worth naming:

• Understanding an inherited org. You join a project with sixty custom objects and no documentation. Schema Builder draws the relationships, so you can see what points at what before you change anything.
• Designing before building. You lay out the objects and relationships for a new module on the canvas and review the model with the business analyst, then create them from the same screen.
• Finding orphan and duplicate objects. Objects nobody relates to anything tend to be abandoned, and the diagram makes them obvious.
• Explaining the model in a design review. It is the artefact a functional stakeholder can actually read.

Two limits to state, because stating them is what shows you have used it. Schema Builder does not create page layouts, does not set field-level security and does not replace the field creation wizard for every field type, so validation rules, layouts and permissions still get done in Setup. And on a large org the canvas becomes unreadable unless you filter down to a few objects using the left panel.

There is a reason the panel likes this question. It is a quick test of whether you have opened an unfamiliar org and made sense of it. Our trainers see candidates who can define every relationship type and still cannot say what they would do on day one of a project they did not build.

What the interviewer is actually checking

• Whether you design with a minimal profile plus permission sets, or clone profiles for every variation
• Whether you know muting permission sets are the only way to subtract a permission, and only within a group
• Whether you know field-level security is not enforced in Apex unless you ask for it with user mode or stripInaccessible
• Whether you can list what master-detail does that lookup does not, in full, without being prompted for each item
• Whether you treat the lookup versus master-detail choice as a security decision as well as a data one

Closing

The pattern across all seventeen questions is the same. Object and field permissions say what you may do; record sharing says which records you may do it to; and sharing only ever opens access up. A candidate who states that clearly, then walks one record through the layers with names and settings, has answered the whole section in three minutes.

Practise it on an org you can actually open. Set an object's OWD to Private, create two users in different branches of the role hierarchy, add a criteria-based sharing rule, then use the Sharing button on a record to see exactly who has access and why. That exercise is worth more than reading the layers ten times.

If you want structured practice on the data model, sharing architecture and Apex, along with mock interview rounds on these exact questions, look at our Salesforce training in Pune with placement support.