Domain Grilling: D2 Security

AI-Generated Content — Use for Reference Only

This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.

Security is the second highest failure domain on the CTA exam. Judges focus heavily on sharing model design, identity architecture, and the trade-offs between security and usability. Expect deep probing on OWD reasoning, sharing rule mechanics, and OAuth flow selection.

Type 1: Invalid — “Your Solution Won’t Work”

These questions challenge a flaw in your design. The judge believes your approach is technically incorrect or impossible.

Judge: “You set OWD to Private on the custom Project object and said you’d use criteria-based sharing rules to share projects by region. But the Project object doesn’t have a Region field — it’s on the related Account. Criteria-based sharing rules can only evaluate fields on the object itself. How does your sharing work?”

What they’re testing: Whether you understand that criteria-based sharing rules only evaluate fields on the owning object, not related objects.

Model answer: “You’re right — criteria-based sharing rules can only reference fields on the object itself, not parent or related objects. My sharing design has a flaw. I have two options: I could add a Region formula field or a populated-via-Flow field on the Project object that mirrors the Account’s region, and then base the sharing rule on that local field. Alternatively, if the sharing logic is more complex than field criteria can express, I would use Apex Managed Sharing to programmatically evaluate the parent Account’s region and create sharing rows. I would prefer the formula field approach for maintainability — Apex Managed Sharing requires custom code, a custom Reason, and ongoing developer support. The trade-off is that a formula field adds a dependency on the Account relationship being populated.”

Q1.2: Restricting Access Below OWD

Judge: “You set OWD to Public Read/Write on Cases, but then you said certain case types should be hidden from certain teams. You can’t restrict access below OWD. How do you handle this?”

What they’re testing: Whether you understand the cardinal rule that sharing is always additive — you cannot take away access above the OWD baseline.

Model answer: “You’re absolutely right — that’s a fundamental flaw in my sharing model. Sharing is always additive; I cannot restrict access below what OWD grants. I need to change the OWD on Cases to Private, which is more restrictive than I originally designed, and then use sharing rules to open access selectively. Ownership-based sharing rules can share cases owned by one role group with another. For the general case visibility that most teams need, a sharing rule grants broad access. For the sensitive case types that should be hidden, those teams are simply excluded from the sharing rules. The trade-off is that Private OWD means Salesforce must evaluate the sharing table for every case query, which adds a small performance cost compared to Public Read/Write. I would also evaluate whether restriction rules — which can hide specific records even when OWD is more permissive — could achieve this with less disruption, though restriction rules have their own limitations around maximum active rules and performance.”

Q1.3: Shield Platform Encryption with LIKE Queries

Judge: “You encrypted the Account Name field using Platform Encryption and your solution includes a search feature that uses LIKE queries to find accounts by partial name. Deterministic encryption only supports exact-match searches. Your search won’t work.”

What they’re testing: Whether you understand the functional trade-offs of Shield Platform Encryption.

Model answer: “That’s correct — deterministic encryption supports exact-match filters but not LIKE, CONTAINS, or wildcard searches. I need to revise my approach. I have three options. First, I could use Salesforce’s encrypted search index, which allows SOSL-based search on encrypted fields but not SOQL LIKE queries. If the search feature can be redesigned to use global search rather than a custom SOQL-based search, the encrypted search index solves this. Second, I could create an unencrypted masked formula field that shows the first three and last three characters for display purposes, while keeping the full Name encrypted. Third, if partial-match search on Account Name is genuinely critical and encryption is required, I may need to maintain a separate search index outside the encrypted field. I would recommend option one — redesigning the search to use SOSL via global search — because it maintains full encryption while providing the search capability.”

Q1.4: Customer Community License with Role Hierarchy

Judge: “You designed a three-level role hierarchy for your Experience Cloud portal users, but you assigned them Customer Community licenses. Customer Community licenses don’t support role hierarchy. Your sharing model breaks.”

What they’re testing: Whether you know the critical distinction between Customer Community and Customer Community Plus license capabilities.

Model answer: “You’re right — that’s a license-capability mismatch. Customer Community licenses share a single role and do not support role hierarchy or sharing rules. The portal sharing model I designed requires Customer Community Plus licenses, which support up to three levels of external role hierarchy and sharing rules. The cost increases but the architecture requires it — without role hierarchy, I cannot provide the multi-level franchise visibility where regional managers see their franchisees’ records but not other regions’. There is no workaround that preserves Customer Community licenses while meeting this sharing requirement. I would update the licensing recommendation and document the specific sharing requirement that necessitates the upgrade.”

Type 2: Missed — “You Haven’t Addressed…”

These questions point out a requirement you didn’t cover.

Q2.1: Integration User Security

Judge: “Your architecture has five integrations running through MuleSoft, but you haven’t described the integration user strategy. What credentials do these integrations use, and what’s their permission model?”

What they’re testing: Whether you considered API user security, Named Credentials, and the principle of least privilege for integrations.

Model answer: “I should have addressed this explicitly. For the five MuleSoft integrations, I would use Named Credentials with OAuth 2.0 Client Credentials flow — this eliminates stored passwords and provides token-based authentication with automatic refresh. Each integration would use a dedicated Connected App with scoped permissions rather than a single shared integration user. The permission model follows least privilege: each Connected App is associated with a permission set that grants access only to the objects and fields that specific integration needs. I would not use a System Administrator profile for any integration user. For audit trail clarity, separate integration users per system allow us to trace which integration modified which records. The Connected Apps would be configured with IP restrictions limiting access to MuleSoft’s known IP ranges and certificate-based authentication for the most sensitive integrations.”

Q2.2: MFA Strategy

Judge: “Multi-factor authentication is a Salesforce requirement. You haven’t mentioned MFA anywhere in your identity architecture. How are you handling it?”

What they’re testing: Whether you understand MFA is mandatory and how it interacts with SSO.

Model answer: “MFA is required for all direct Salesforce UI logins. In my architecture, the primary login path is SSO via Okta, where MFA is enforced at the IdP level — users authenticate with Okta MFA before the SAML assertion reaches Salesforce. For this path, Salesforce trusts the IdP’s MFA enforcement and does not require a second MFA challenge. However, I need to address three additional scenarios: API-only users who use OAuth flows bypass MFA by design since they’re not interactive logins. Admin users who can bypass SSO for break-glass access need Salesforce-native MFA configured — I would use Salesforce Authenticator or a TOTP app. And Experience Cloud external users who don’t go through the corporate IdP need their own MFA configuration. I would enable MFA for all profiles and configure the SSO handler to satisfy the MFA requirement when authentication comes through the IdP.”

Q2.3: Guest User Security

Judge: “Your Experience Cloud site has public-facing pages. You haven’t addressed guest user security. What data can unauthenticated users access?”

What they’re testing: Whether you understand the security implications of guest user profiles, which have been a major attack vector.

Model answer: “Guest user security is critical and I should have addressed it explicitly. The guest user profile should follow strict least-privilege: only objects and fields needed for the public pages should be accessible, and I would use SOQL/SOSL query filters in the Apex or Flow backing the public pages to ensure guest users only see records explicitly intended for public display. Specifically, I would set OWD to Private for any objects the guest user can access, use a sharing rule to share only records marked with a ‘Public’ flag to the guest user, and configure the guest user profile with Read-only access to those specific objects. I would also disable API access for the guest user, limit CRUD to the absolute minimum, implement rate limiting via the portal settings, and enable the ‘Secure guest user record access’ org setting that requires explicit sharing for guest access. This is an area where Salesforce has tightened security significantly — all access must be granted through sharing, not profile-level public access.”

Type 3: Suboptimal — “Have You Considered…?”

These questions suggest a potentially better approach.

Judge: “You created 15 criteria-based sharing rules on the Opportunity object to handle regional visibility. Have you considered that Apex Managed Sharing could achieve the same with less maintenance overhead and better performance?”

What they’re testing: Whether you evaluated programmatic sharing as an alternative to a complex declarative sharing model.

Model answer: “I considered Apex Managed Sharing but chose criteria-based sharing rules because the sharing logic maps cleanly to field values — Region, Business Unit, and Deal Size. With 15 rules, the admin team can understand and maintain them without developer involvement. Apex Managed Sharing would consolidate the logic into code, which could be more efficient at scale, but it introduces developer dependency for any sharing logic changes and requires maintaining a custom Reason field. The trade-off is administrative overhead of 15 rules versus code maintenance overhead. If the sharing logic were more dynamic — for example, based on time-of-day, external system data, or complex calculations across related objects — Apex Managed Sharing would be the better choice. I would monitor sharing table size and recalculation time, and if performance degrades, I would consolidate into Apex Managed Sharing.”

Q3.2: Role Hierarchy vs Territory Management

Judge: “You built a complex role hierarchy with 8 levels to model the sales territories. Have you considered Territory Management instead? It’s designed specifically for this.”

What they’re testing: Whether you evaluated the purpose-built feature before bending the role hierarchy to fit.

Model answer: “I considered Territory Management and chose role hierarchy because the territory structure exactly mirrors the management reporting structure — each territory has one manager, and managers only see their direct reports’ opportunities. In this case, role hierarchy naturally models both management visibility and territory assignment. Territory Management would be the better choice if territories overlap — where one account belongs to multiple territories with different sales reps — or if territory assignment rules need to be dynamic based on account attributes like postal code, industry, or revenue tier. The scenario does not mention overlapping territories, so I avoided the added complexity. However, if the client plans to reorganize territories frequently, Territory Management’s rule-based assignment would reduce the manual effort of reassigning accounts compared to changing role hierarchy positions.”

Q3.3: Separate IdP vs Salesforce as IdP

Judge: “You’re using Salesforce as the Identity Provider for three external applications. Have you considered that a dedicated IdP like Okta or Azure AD would be more maintainable and scalable?”

What they’re testing: Whether you understand when Salesforce as IdP is appropriate versus when a dedicated IdP is better.

Model answer: “I chose Salesforce as IdP because the three external applications are tightly integrated with Salesforce — they are a custom Heroku app, a customer portal, and an internal tool that all authenticate Salesforce users. The identity source is already in Salesforce, so using Salesforce as IdP eliminates a third-party dependency. However, you raise a valid point about scalability. If the organization plans to add more non-Salesforce applications or needs advanced IdP features like adaptive MFA, device trust policies, or SCIM-based lifecycle management across 20+ applications, a dedicated IdP like Okta provides better centralized governance. The decision threshold for me is: fewer than 5 SP applications with Salesforce-centric users, Salesforce as IdP is simpler. More than 5 SPs, or non-Salesforce user populations, a dedicated IdP is more appropriate.”

Q3.4: Restriction Rules vs Private OWD

Judge: “You changed OWD from Public Read Only to Private on Account to hide sensitive accounts from certain teams. Have you considered Restriction Rules instead? They let you keep Public Read Only and hide specific records.”

What they’re testing: Whether you know about restriction rules and when they are a better fit than changing OWD.

Model answer: “I considered restriction rules and they could be a better fit here. Changing OWD to Private requires building sharing rules to restore the broad access that most users need, which adds complexity and sharing table overhead. Restriction rules allow me to keep OWD at Public Read Only — preserving the simpler sharing model for 95% of records — and selectively hide the sensitive accounts using criteria-based conditions. The trade-off with restriction rules is the limit on the number of active rules per object and the fact that they only hide records from users who match the rule criteria — they don’t provide fine-grained write protection. If the requirement is to hide a small set of sensitive accounts from specific teams while keeping broad access for everything else, restriction rules are the cleaner approach. I would revise my recommendation to use restriction rules for this use case.”

Type 4: Rationale Missing — “WHY Did You Choose…?”

These questions probe the reasoning behind a correct decision.

Q4.1: OWD Selection Reasoning

Judge: “Walk me through exactly why you set OWD to Private on the Opportunity object. What drove that decision?”

What they’re testing: Whether you have a systematic approach to OWD selection, not just a default.

Model answer: “I set OWD to Private because the scenario has three business units with separate sales teams who should not see each other’s pipeline. The test I apply is: what is the most restrictive access level needed for any user-to-record combination? If any sales rep should be unable to see another business unit’s opportunities, Private is the starting point. I then open access selectively: the role hierarchy provides upward visibility so managers see their team’s opportunities. Cross-BU sharing rules grant Read access to operations and finance teams who need consolidated views for reporting. The alternative — Public Read Only — would expose all opportunities to all sales reps, which violates the business unit isolation requirement. Public Read/Write was never considered because it would allow any user to edit any opportunity. The cascading impact is that Private OWD means Salesforce maintains the OpportunityShare table, which adds some performance overhead for large orgs, but the security requirement outweighs the performance cost.”

Q4.2: SAML SSO Flow

Judge: “Draw the SAML SSO flow for your solution on the whiteboard.”

:artist_palette: Draw on the spot

What they’re testing: Whether you truly understand the SAML protocol mechanics, not just the concept.

Model answer: Draw the SP-initiated SAML flow: (1) User navigates to Salesforce My Domain URL. (2) Salesforce identifies the user is not authenticated, generates a SAML AuthnRequest. (3) Browser is redirected (HTTP 302) to the corporate IdP (Okta) with the AuthnRequest. (4) IdP authenticates the user (credentials + MFA). (5) IdP generates a signed SAML Response containing the assertion with user attributes (Federation ID, email, profile). (6) Browser POSTs the SAML Response back to Salesforce’s Assertion Consumer Service (ACS) URL. (7) Salesforce validates the XML signature against the stored IdP certificate, extracts the Federation ID, matches it to a Salesforce user. (8) If JIT provisioning is enabled and no user exists, Salesforce creates the user from assertion attributes. (9) Salesforce establishes a session and redirects the user to the home page. Key configuration points: Federation ID as the user matching attribute (decoupled from username), certificate rotation process, and Single Logout configuration for session termination.

Q4.3: OAuth Flow Selection

Judge: “You’re using OAuth 2.0 for the mobile app integration. Which specific OAuth flow did you choose and why?”

What they’re testing: Whether you understand the different OAuth 2.0 flows and can select the right one for the use case.

Model answer: “For the mobile app, I chose the OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange). The Authorization Code flow is appropriate because it is an interactive flow where a user is present to authenticate. PKCE is essential for mobile apps because they are public clients — they cannot securely store a client secret. PKCE replaces the client secret with a dynamically generated code verifier and code challenge, preventing authorization code interception attacks. I did not use the User-Agent (Implicit) flow because it exposes the access token in the URL fragment, which is a security risk and this flow is deprecated in OAuth 2.1. I did not use Client Credentials because there is no user context — it is for server-to-server integrations. I did not use the JWT Bearer flow because it requires a pre-shared certificate and is designed for server-to-server trust, not interactive mobile users. The refresh token allows the mobile app to maintain a session without re-prompting for credentials.”

Q4.4: Encryption Strategy Reasoning

Judge: “Why did you choose deterministic encryption for the email field but probabilistic for the description field?”

What they’re testing: Whether you understand the functional trade-offs of each encryption scheme.

Model answer: “The decision is driven by how each field is used. Email fields are commonly used in search, duplicate matching, and as filter criteria in list views and reports — all of which require the field to be filterable. Deterministic encryption supports exact-match filtering, so users can search for a specific email address and duplicate rules can match on it. Probabilistic encryption would make the email field unsearchable and unfilterable, breaking core workflows. For the description field, no one searches for an exact description match or filters reports by it. Probabilistic encryption provides stronger security because the same plaintext encrypted twice produces different ciphertext, making frequency analysis attacks impossible. Deterministic encryption has a theoretical vulnerability to frequency analysis because the same plaintext always produces the same ciphertext. I chose maximum security where functionality allows it and accepted the minimum security trade-off only where functionality requires it.”

Type 5: Cascading — “If You Change X, What Happens to Y?”

These questions test cross-domain dependency awareness.

Q5.1: OWD Change Impact

Judge: “You just changed the Account OWD from Public Read Only to Private. What else in your architecture is affected?”

What they’re testing: Whether you can trace the full cascade of an OWD change.

Model answer: “Changing Account OWD to Private cascades through multiple layers. First, sharing rules: I need to create sharing rules to restore access for teams that previously had implicit read access — finance, operations, and executive reporting users. Second, implicit sharing: child objects like Contacts, Opportunities, and Cases that use lookup relationships to Account will lose their implicit parent access. Users who could previously see Contacts because they could see the parent Account may now lose access, so I need to verify child object OWDs and sharing independently. Third, reporting: dashboards that ran as ‘Running User’ with broad visibility may now show fewer records depending on the running user’s new access level — dynamic dashboards or running as a user with View All Data might be needed. Fourth, integration users: any integration user that queries Accounts now needs explicit sharing or View All permission on Account. Fifth, Experience Cloud: external users’ access through portal sharing sets is based on their Account relationship, so if Account access changes, portal visibility cascades. Sixth, performance: the sharing engine now needs to compute AccountShare rows, increasing group membership recalculation time.”

Q5.2: Identity Architecture Change Impact

Judge: “The client decides to switch their IdP from ADFS to Okta. What changes in your architecture?”

What they’re testing: Whether you understand the IdP is a foundational dependency that affects multiple integration points.

Model answer: “The IdP migration impacts every authentication touchpoint. In Salesforce, the SAML SSO configuration needs to be updated: the new IdP certificate, Entity ID, Login URL, and Logout URL all change. The Federation ID mapping must be preserved — as long as the same user identifier is used in Okta’s SAML assertions, user matching continues to work. Connected Apps that use OAuth with ADFS as the authorization server need to be reconfigured for Okta’s OAuth endpoints. Named Credentials that authenticate via ADFS need new endpoint URLs and potentially new authentication protocols if Okta supports different flow options. The MuleSoft integration layer, if it authenticates through ADFS for any API calls, needs its authentication configuration updated. The Experience Cloud portal SSO also needs reconfiguration. The migration plan should include a parallel-running period where both IdPs are configured in Salesforce — My Domain supports multiple SSO configurations. Users can be migrated in waves, testing each authentication path before decommissioning ADFS.”

Judge: “You added Apex Managed Sharing to the Opportunity object to handle a complex sharing requirement. How does that affect your integration architecture?”

What they’re testing: Whether you understand that programmatic sharing has integration and deployment implications.

Model answer: “Apex Managed Sharing impacts the integration and deployment layers in several ways. First, the integration user’s permission model: any integration that creates or updates Opportunities must be aware that the sharing logic runs in the Apex sharing handler. If the integration creates records with specific owners, the sharing handler must correctly calculate sharing based on the new owner. Second, deployment: the Apex sharing class must be deployed alongside the sharing reason and any triggers that invoke it. The deployment order matters — the sharing reason custom field must exist before the Apex class that references it. Third, testing: the sharing Apex class needs test coverage, and integration test scenarios must verify that records created via API are correctly shared. Fourth, data migration: if we bulk-load historical opportunities, we need to run the sharing recalculation after load to ensure all records have correct sharing rows. Fifth, if I ever need to modify the sharing logic, all existing share rows with that Reason are deleted and must be recalculated, which for a large org can take hours and temporarily affect visibility.”

Q5.4: Enabling Shield Encryption Impact

Judge: “You just added Shield Platform Encryption to the solution. What downstream impacts should you warn the client about?”

What they’re testing: Whether you understand the broad architectural impact of encryption beyond just the security benefit.

Model answer: “Shield Platform Encryption has cascading impacts across the solution. Data model: encrypted fields cannot be used in certain formula fields, and cannot be referenced in SOQL WHERE clauses with LIKE operators. Unique and External ID fields can only be encrypted with deterministic encryption — probabilistic encryption is not supported for these field types. Search: the encrypted search index must be rebuilt, and search behavior changes for encrypted fields. Reports: you cannot use encrypted fields in report filters with LIKE, CONTAINS, or range operators — only exact match with deterministic. Integration: any integration that relies on querying by encrypted fields must be redesigned to use exact-match or alternative query strategies. Validation rules: validation rules that reference encrypted fields with text manipulation functions may break. Workflow and Flow: criteria evaluating encrypted fields are limited to exact-match comparisons. Performance: there is a small runtime overhead for encrypting and decrypting field values. The client should plan for a testing cycle where every page, report, integration, and automation that touches encrypted fields is validated.”

This is a personal study site for Salesforce CTA exam preparation. Built with AI assistance. Not affiliated with Salesforce.