Domain Grilling: D2 Security

Security is the second highest failure domain on the CTA exam. Judges focus 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”

The judge believes your approach is technically incorrect or impossible.

Judge: “Your sharing model shows Account OWD as Public Read Only, but you have criteria-based sharing rules restricting partner users from seeing certain accounts. That approach is fundamentally flawed. How do you respond?”

What they’re testing: Understanding that sharing is additive and cannot restrict below OWD baseline.

Model answer: “You’re right to flag that. Sharing rules can only grant access, never restrict it. If Account OWD is Public Read Only, every user including partners already has Read access to all Account records. No sharing rule can take that away. I need to change Account OWD to Private, setting the floor at zero visibility, then use criteria-based sharing rules to open access for internal teams needing cross-region visibility. For partners, the External OWD would also be Private, with the portal role hierarchy providing visibility within their own Account. The trade-off is share table overhead, but with the 2 million account volume that’s manageable. The alternative of keeping Public Read Only and hoping page layouts or FLS would hide records is a presentation-layer illusion, not real security.”

Follow-up: “What happens to sharing recalculation time when you switch from Public Read Only to Private on an object with 2 million records?”

Q1.2: Probabilistic Encryption Breaks Email Lookups

Judge: “You recommended Shield Platform Encryption with probabilistic encryption on the Email field, but your integration layer sends email-based queries to match customer records. Walk me through why this won’t work.”

What they’re testing: Understanding encryption scheme trade-offs and their impact on SOQL operations.

Model answer: “Probabilistic encryption on Email means SOQL WHERE clauses cannot perform any match, not even exact match. The integration’s email-based lookup would return zero results every time. Two paths to fix: First, switch to deterministic encryption, which allows exact-match queries. The trade-off is slightly weaker encryption (identical values produce identical ciphertext) but for email addresses in a business context that risk is acceptable. Second, if the integration needs substring or LIKE matching, deterministic still won’t work. I’d keep the full email encrypted with deterministic and redesign the integration to pass the full email for exact-match lookups. If the org is on Hyperforce and exact matching is insufficient, Database Encryption is the zero-impact alternative.”

Follow-up: “If you switch to deterministic encryption, what other functionality do you lose compared to an unencrypted field?”

Q1.3: Customer Community License Cannot Do Reports

Judge: “Your solution gives Customer Community licensed users access to reports and dashboards. That license type doesn’t support that capability. What’s your corrective action?”

What they’re testing: License-capability mismatch between Customer Community and Customer Community Plus.

Model answer: “Customer Community licenses do not include reporting and dashboard access. Two options: upgrade those users to Customer Community Plus which adds reporting, hierarchy, and dashboards — but at significantly higher per-user cost, that’s a substantial budget increase for 50,000 users. The alternative I’d recommend is building custom LWC components on the portal that surface pre-computed metrics via Apex. This keeps users on the lower-cost license while delivering analytics capability. The trade-off is development effort versus the simplicity of standard reports. If truly ad hoc reporting with custom filters and export is needed, Community Plus is the only option, and I’d scope that to account administrators who actually need it rather than upgrading all 50,000.”

Follow-up: “If you upgrade a subset of users to Community Plus, what impact does that have on the portal role hierarchy and sharing calculations?”

Judge: “You’ve set up criteria-based sharing rules on Opportunity that reference the parent Account’s Region field. Criteria-based sharing rules can only reference fields on the object itself. How do you fix this?”

What they’re testing: Understanding that criteria-based sharing rules cannot reference related object fields.

Model answer: “That’s a platform limitation I need to work around. Criteria-based sharing rules can only evaluate fields directly on the record’s own object. Three options: First, add a Region formula or workflow-populated custom field directly on Opportunity that mirrors the Account’s Region. The sharing rule references Opportunity.Region__c. Trade-off: if the Account Region changes, a flow or trigger must sync it. Second, use ownership-based sharing rules if regional alignment maps to owner roles. Third, for complex logic, Apex managed sharing can query the parent Account’s Region and programmatically create share records. Trade-off with Apex is development and maintenance cost. A formula field pulling Account.Region onto Opportunity avoids sync automation but criteria-based sharing rules do NOT recalculate when the source field on the parent changes. A flow-stamped text field triggers sharing recalculation on update but requires explicit automation to keep in sync.”

Follow-up: “If you use a formula field to pull Account Region onto Opportunity, does the sharing rule fire automatically when the Account’s Region changes?”

Judge: “You mentioned using Apex Managed Sharing with custom sharing reasons on the Account object. Apex Sharing Reasons are only available on custom objects. How do you handle Account sharing programmatically?”

What they’re testing: Knowledge that Apex Sharing Reasons exist only on custom objects, and that Apex Managed Sharing is the wrong tool for Account entirely.

Model answer: “The bigger issue is that Apex Managed Sharing shouldn’t be used on Account at all. Apex Sharing Reasons are only available on custom objects, so Account programmatic shares have to use RowCause = ‘Manual’. Manual shares on Account are wiped whenever ownership changes OR whenever sharing rule recalculation runs — which makes any trigger-to-recreate pattern brittle, noisy, and constantly out of sync with production events. The right answer for Account is native: Account Teams (pre-defined per-account access grants with configurable Account, Opportunity, Case access levels), Account Sharing Rules (criteria or ownership-based), or Enterprise Territory Management (account assignment rules, territory hierarchies, forecasting). For truly dynamic logic that none of those handle, move the sensitive relationship to a custom junction object between Account and User — that object supports Apex Sharing Reasons, deploys cleanly, and survives Account ownership changes. I’d only touch AccountShare directly as a narrow one-off during migration, never as the ongoing sharing mechanism.”

Follow-up: “If the scenario has 50 overlay specialists who need rotating visibility to different accounts each quarter, which of Account Teams, Sharing Rules, or Territory Management fits best and why?”

Q1.6: Named Credentials Misused with Custom Settings

Judge: “Your integration shows a Named Credential configured with the admin user’s credentials stored in a Custom Setting. Named Credentials are supposed to eliminate that pattern. What went wrong?”

What they’re testing: Proper use of Named Credentials versus hardcoded/stored credentials.

Model answer: “That completely defeats the purpose. Named Credentials should manage authentication declaratively, keeping secrets out of code and custom settings. The correct design: a Named Credential with an External Credential using JWT Bearer authentication with a certificate. No username, no password, no secret stored in Salesforce metadata. The integration user should be a dedicated API user with a minimum-access profile and specific permission sets. The old pattern of storing credentials in Custom Settings is visible to anyone with Customize Application permission and exports with metadata deployments. Named Credentials handle the entire OAuth token lifecycle automatically.”

Follow-up: “How do you handle Named Credential configuration across environments when endpoint URLs and credentials differ between sandbox and production?”

Q1.7: Deterministic Encryption Breaks LIKE Queries

Judge: “You recommended Shield deterministic encryption on Account Name, but your LWC uses a SOQL LIKE operator for partial string searching. This won’t work. What is the impact?”

What they’re testing: Shield encryption breaks substring search capabilities even with deterministic scheme.

Model answer: “Correct. Deterministic encryption allows exact-match filtering but LIKE, CONTAINS, and wildcards do not work. The Apex controller’s LIKE query on the encrypted Name field will fail. If partial search is an absolute business requirement, we cannot use Field-Level Encryption for this field. On Hyperforce, Database Encryption encrypts at the storage layer with zero functional impact on SOQL. Alternatively, I’d create an unencrypted masked formula field showing partial data for display, keep the full field encrypted with deterministic, and redesign the search to use exact-match lookups.”

Follow-up: “If you choose Database Encryption instead, what compliance requirements does it satisfy and what capabilities does it lack compared to FLE?”

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

The judge is pointing out a gap in your design.

Q2.1: Transaction Security for Data Exfiltration

Judge: “I don’t see anything about Transaction Security policies in your security architecture. How would you detect and respond to a data exfiltration attempt?”

What they’re testing: Awareness of Transaction Security as real-time threat detection and response.

Model answer: “That’s a gap I should address for regulated financial data. I’d implement Transaction Security policies as part of Shield Event Monitoring. Specifically: block report exports exceeding 10,000 rows and notify the security team; require MFA re-authentication when a user accesses 500+ records from a non-corporate IP; send notifications for anomalous API query patterns. Transaction Security evaluates events in real time using Condition Builder or Apex. The three response actions are block, require MFA step-up, or notify. I’d layer these with Event Monitoring’s 24-hour log files fed into CRM Analytics for forensic trend analysis. Trade-off: policies add evaluation overhead per event, so I’d scope to highest-risk event types.”

Follow-up: “What’s the difference between Condition Builder and Apex-based Transaction Security policies, and when would you choose one over the other?”

Q2.2: Event Monitoring for HIPAA Compliance

Judge: “Your security design doesn’t mention Event Monitoring. In a HIPAA scenario, how do you satisfy audit and forensic requirements?”

What they’re testing: Event Monitoring as a compliance requirement under HIPAA.

Model answer: “Significant gap for HIPAA. HIPAA requires auditing who accessed PHI and when. Event Monitoring captures login events, API events, report views, record access, and content downloads. For HIPAA: API event logs to track external system access to patient records, report export events to detect mass PHI downloads, login events for unauthorized access detection. Event log files have a 24-hour delay, suitable for compliance audits. For real-time response, pair with Real-Time Event Monitoring feeding Transaction Security policies. Event log files are retained for 30 days by default (up to 1 year with extended retention, GA since Summer ‘24); for HIPAA’s six-year requirement, export to an external SIEM via the EventLogFile API. Trade-off is Shield license cost, typically 30-50% of platform licensing.”

Follow-up: “How would you handle the six-year HIPAA audit log retention given that Event Monitoring logs are retained for only 30 days?”

Q2.3: Data Classification Before Encryption

Judge: “You haven’t addressed data classification. How do you determine which fields need encryption, FLS restrictions, or standard access?”

What they’re testing: Systematic data classification driving encryption and access control decisions.

Model answer: “Foundational step I should have started with before making encryption or FLS decisions. I’d implement a four-tier classification: Tier 1 Public (catalog data), Tier 2 Internal (standard business data), Tier 3 Confidential (PII, revenue), Tier 4 Restricted (SSN, health, payment). Each tier maps to controls: Public gets standard OWD. Internal gets FLS restrictions on external profiles. Confidential gets FLS, deterministic encryption where searchability is needed, role-based sharing. Restricted gets probabilistic encryption, cache-only keys, Field Audit Trail, and Transaction Security policies. Salesforce supports Data Classification metadata fields for auditability. Trade-off is upfront effort to classify every field, but it prevents over-encrypting (breaking functionality) or under-protecting (compliance violations).”

Follow-up: “How would you handle a field classified as Restricted that also needs to be used in a criteria-based sharing rule?”

Q2.4: Session-Based Permission Sets for Elevated Access

Judge: “Your identity design covers SSO but doesn’t address session-based permission sets. The scenario has users needing elevated access only during specific workflows. What’s your approach?”

What they’re testing: Session-based permission sets for conditional, time-limited elevated access.

Model answer: “Permanently assigning elevated permissions violates least-privilege. Session-based permission sets activate only during qualifying events and deactivate when the session ends. I’d create a session-based PS for the restricted fields/records. Activation trigger depends on the workflow: approval-based triggers via Flow creating a SessionPermissionSetActivation record, or step-up auth triggers via Auth Provider after re-authentication. Permissions are active only for that session, expiring automatically on logout or timeout. Trade-off versus permanent PSs is added activation complexity and potential user confusion if they bookmark pages requiring elevated access. But the alternative of 24/7 elevated access increases blast radius of a compromised account.”

Follow-up: “Can session-based permission sets be activated programmatically from a connected app’s OAuth flow for an integration scenario?”

Q2.5: SCIM for Deprovisioning

Judge: “You described JIT provisioning for user creation during SSO, but what happens when someone is terminated at the corporate IdP? Your design has no deprovisioning strategy.”

What they’re testing: SCIM for immediate deprovisioning versus JIT’s login-triggered-only limitation.

Model answer: “Critical gap. JIT only fires at login time. A terminated employee who never attempts to log in again has an active Salesforce account indefinitely — security risk and compliance violation. SCIM 2.0 provides the solution: when a user is deactivated in the IdP, the SCIM connector sends a PATCH/DELETE to Salesforce’s /Users endpoint, deactivating the user without a login attempt. SCIM also manages group membership and role assignments in real time. Architecture: use both SCIM and JIT as complementary layers — SCIM for lifecycle management including deprovisioning, JIT for session-time attribute refresh. Trade-off is SCIM connector configuration complexity and ongoing monitoring to ensure sync doesn’t fail silently. For the scenario’s 5,000+ users, SCIM is a compliance necessity.”

Follow-up: “What Salesforce objects does SCIM map to for group membership, and are there limitations on what SCIM can assign?”

Q2.6: Agentforce Security Boundaries

Judge: “Your solution includes Agentforce Service Agents on the portal, but you haven’t addressed AI agent security boundaries. What prevents the agent from exposing data the user shouldn’t see?”

What they’re testing: Agentforce security: agents operate within user’s sharing and permission context.

Model answer: “The security model differs by agent type. Employee Agents inherit the running user’s permissions and sharing context — they cannot access data the user cannot see. Service Agents, which are what we’d deploy on an Experience Cloud portal, run as a dedicated Agent User with its own profile and permission sets — they do NOT automatically inherit the portal user’s sharing rules. The architect must explicitly configure the Agent User’s CRUD, FLS, and sharing access to ensure it can only reach records appropriate for the portal context. Where I need to be deliberate is topic configuration and guardrails. The Einstein Trust Layer provides data masking, toxicity detection, and audit logging for LLM interactions. I should also configure topics to exclude sensitive fields from agent responses even if the Agent User has FLS access. Trade-off: tighter guardrails reduce helpfulness, so I’d scope to PII and internal-only fields.”

Follow-up: “If the Agentforce agent needs to perform an action requiring elevated permissions, like escalating to a queue the user can’t see, how would you architect that?”

Q2.7: Integration User Security Model

Judge: “You haven’t addressed the security model for the integration user connecting the ERP to Salesforce. What profile, permissions, and authentication flow are you assigning?”

What they’re testing: Integration user security model with least-privilege and correct OAuth flow.

Model answer: “I will avoid System Administrator or Modify All Data — severe anti-patterns that bypass the security model. Instead: a custom Minimum Access Profile paired with an integration-specific Permission Set granting only the exact object CRUD and FLS needed. For authentication, this is a server-to-server integration with a secure backend, so JWT Bearer OAuth flow with a pre-authorized Connected App and uploaded digital certificate. This allows secure impersonation of the integration user without transmitting client secrets. The execution context respects that user’s CRUD, FLS, and sharing rules.”

Follow-up: “What happens if the certificate expires during a critical data sync window?”

Q2.8: MFA and Breakglass Strategy

Judge: “You haven’t addressed how MFA will be enforced for internal users logging in via SSO, and what happens during an IdP outage.”

What they’re testing: MFA enforcement in SSO environments and breakglass strategy.

Model answer: “For internal users via SSO, MFA is handled by the corporate IdP before the SAML assertion is sent, fully satisfying Salesforce’s MFA requirement. No additional MFA config needed within Salesforce for SSO users. The architect must verify the IdP’s conditional access policies actually enforce MFA for all Salesforce-bound sessions. Salesforce trusts the assertion; it cannot independently verify MFA was performed at the IdP. For IdP outages, I’ll configure breakglass System Administrator accounts that bypass SSO and log in directly. For those direct logins, Salesforce natively enforces MFA using Salesforce Authenticator or security keys.”

Follow-up: “How do you ensure breakglass accounts aren’t misused during normal operations?”

Q2.9: Guest User Hardening

Judge: “You haven’t addressed the security implications of the public-facing knowledge base. How are you securing the guest user profile?”

What they’re testing: Guest user hardening in Experience Cloud.

Model answer: “Guest users are unauthenticated internet visitors, so the default posture is deny everything. I’ll remove all unnecessary object permissions from the guest profile and disable API access to prevent data scraping. To expose knowledge articles, I’ll implement a criteria-based guest user sharing rule for Knowledge where IsPublished = true. The ‘Secure guest user record access’ setting will be verified as active (enforced by default since Winter ‘21; cannot be disabled on newer orgs). On legacy orgs, enable it manually. This ensures any records created by guests are assigned to the site’s default internal owner. No View All, Modify All, or unnecessary object access.”

Follow-up: “How do you test that the guest user profile truly cannot access objects beyond what you’ve explicitly shared?”

Q2.10: Restriction Rules for Narrowing Below OWD

Judge: “Your design has Contract OWD as Public Read Only because operations users need to see all active contracts, but a subset of ‘confidential’ contracts must only be visible to the legal team. Sharing rules can’t take access away. You haven’t addressed how you’ll narrow visibility below OWD for just that subset. What’s your approach?”

What they’re testing: Knowledge of Restriction Rules as the mechanism for narrowing access below OWD on supported objects, and the exact scope of supported objects.

Model answer: “This is the textbook Restriction Rule use case. Restriction Rules let me filter the set of records a targeted user population can see, evaluated after sharing rules but scoped to specific objects. I’d create a Restriction Rule on Contract, target everyone except the Legal public group, and set the criteria to Confidentiality_Level__c != 'Confidential' — non-legal users then see only non-confidential contracts, even though OWD is still Public Read Only. Critical scoping I’d call out up front so the judge knows I know the trap: Restriction Rules are only supported on custom objects, external objects, Contracts, Events, Quotes, Tasks, Time Sheets, and Time Sheet Entries. They are NOT supported on Account, Contact, Case, Opportunity, Lead, or any other standard CRM object. If this scenario were about confidential Accounts or confidential Cases, Restriction Rules would be off the table and I’d have to move the sensitive attribute to a related custom object with its own Private OWD, or restructure via record types plus FLS-based Permission Set Groups. Trade-off: Restriction Rules require Enterprise Edition or above, and each user can see the object through at most one Restriction Rule at a time, so I can’t layer multiple rules on the same user.”

Follow-up: “What happens to a user’s Contract visibility if they belong to two different public groups targeted by two different Restriction Rules with conflicting criteria?”

Q2.11: Restriction Rules vs Scoping Rules

Judge: “You’ve proposed Scoping Rules for partner community users to only see accounts in their region. Scoping Rules don’t enforce security — they’re a UX filter. Walk me through the difference and what you’d actually use for security enforcement.”

What they’re testing: Whether the candidate understands Scoping Rules are user-experience filtering while Restriction Rules are enforced record-level security — and that mixing them up is a common trap.

Model answer: “Important distinction. Scoping Rules narrow the default set of records a user sees in list views, reports, SOQL queries, and lookups — but they do not restrict the underlying record access granted by the sharing model. A user can still access a record outside their scope through a direct URL or API call if the sharing model grants them access, because Scoping Rules filter visibility without revoking permissions. Restriction Rules, by contrast, actually remove the record from the user’s result set wherever it’s queried — UI, API, Apex with sharing, reports. For a partner community scenario involving security, Restriction Rules are the correct tool — but only if the object is in the supported list (custom, external, Contracts, Events, Quotes, Tasks, Time Sheets, Time Sheet Entries). Partner visibility on Account itself can’t be done via Restriction Rules because Account isn’t supported. For Accounts, the right answer is Private OWD plus Sharing Sets keyed to the Account lookup on the portal Contact, or criteria-based sharing rules keyed to region. Scoping Rules still have a valid role here — as a usability layer on top of the enforced security, to clean up list views for internal users who technically have broad access but only care about their own region day-to-day. So the design is: Sharing Sets for security, Scoping Rules for UX, never the other way around.”

Follow-up: “If you apply both a Scoping Rule and a Restriction Rule to the same user on the same custom object, which one wins and in what order are they applied?”

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

The judge is suggesting a potentially better approach.

Q3.1: Territory Management vs Deep Role Hierarchy

Judge: “You’ve built a 12-level role hierarchy for territory-based visibility. Have you considered Sales Territories instead?”

What they’re testing: Territory Management as a parallel access model versus overloading role hierarchy.

Model answer: “A 12-level hierarchy is well beyond the 5-7 level recommendation. If most levels represent geographic or segment access rather than management reporting, I’m misusing the hierarchy. Sales Territories are designed specifically for this: accounts can belong to multiple territories simultaneously (role hierarchy can’t represent this), territory assignment rules handle geographic/industry criteria automatically, and territory-based forecasting is built in. I’d keep the role hierarchy shallow at 4-5 levels focused on management visibility while territories handle geographic complexity. Trade-off: territory assignments create additional share table entries, so I’d test recalculation at the scenario’s account volumes.”

Follow-up: “If you implement Territory Management alongside a role hierarchy, how do the two interact for record access?”

Judge: “You’ve written extensive Apex managed sharing. Have you considered whether a redesigned hierarchy with criteria-based sharing rules could achieve the same result declaratively?”

What they’re testing: Declarative sharing preferred over Apex sharing when possible.

Model answer: “Apex managed sharing should be the last resort. If the sharing logic is ‘share cases where product line matches user’s certification,’ that’s genuinely dynamic and can’t be expressed declaratively. But if it’s ‘share opportunities where Region equals West with the West Sales Group,’ that’s a criteria-based sharing rule. I’d separate requirements into two buckets: pattern-based sharing handled by criteria-based rules with public groups (roughly 70% of scenarios), and truly dynamic sharing that legitimately needs Apex. The trade-off of keeping everything in Apex: development cost, testing complexity (requires System.runAs), deployment dependencies on sharing reason custom fields, and long-term maintenance burden.”

Follow-up: “How would you deploy Apex managed sharing classes given the dependency on Apex Sharing Reasons? What’s the deployment sequence?”

Q3.3: Minimum Access Profile Over Profile Sprawl

Judge: “You’re managing permissions through 15 cloned profiles. Have you considered the Minimum Access Profile pattern with Permission Set Groups?”

What they’re testing: Modern permission model replacing legacy profile-centric approach.

Model answer: “Fifteen cloned profiles create compounding maintenance: updating FLS across 15 profiles, risk of unintended side effects from monolithic profile edits. The modern approach: one Minimum Access profile granting almost nothing, atomic permission sets each serving one business function, bundled into PSGs representing business roles. Muting PSs handle exceptions without creating profile clones. Trade-off: significant upfront redesign to decompose profiles into atomic PSs, test every combination, and migrate users. But ongoing: changes to one capability affect one PS, audit is clearer, scaling is straightforward.”

Follow-up: “How would you migrate from 15 profiles to the PSG model in production without disrupting 2,000 active users?”

Q3.4: Named Credentials Over Custom Token Management

Judge: “Your integration stores OAuth tokens in a Protected Custom Setting. Have you considered Named Credentials?”

What they’re testing: Named Credentials as the standard for callout authentication.

Model answer: “Named Credentials would eliminate the entire custom layer. My current approach has problems: custom Apex token management that every developer must understand, tokens in Protected Custom Settings visible to anyone with Customize Application permission, and token refresh logic as a maintenance burden. With Named Credentials + External Credentials, the platform manages the entire lifecycle. The Apex callout becomes a single line referencing ‘callout:My_Integration/endpoint’. No token management code, no stored secrets, no manual refresh. Trade-off: more upfront Setup configuration and the External Credential model has a learning curve. But for standard OAuth flows (90%+ of scenarios), Named Credentials are strictly better.”

Follow-up: “How do you handle Named Credential configuration differences across sandbox and production environments?”

Q3.5: Identity Broker for Multi-IdP Environments

Judge: “You’re recommending direct SAML SSO from each app to three different IdPs in the M&A scenario. Have you considered an identity broker?”

What they’re testing: Identity broker for centralized SSO in multi-IdP environments.

Model answer: “An identity broker is significantly cleaner. Point-to-point with three IdPs creates a combinatorial explosion: every SP needs three SSO configurations with separate certificate management. The broker acts as the single IdP all SPs trust, normalizing assertions from each acquired company’s IdP. Benefits: centralized MFA enforcement, single deprovisioning point, protocol translation (LDAP from company A, OIDC from B, SAML from C), simplified certificate management. Trade-off: the broker becomes a single point of failure and compromise. Mitigation: HA/DR configuration and breakglass admin accounts bypassing the broker. At three IdPs and growing, the broker pays for itself in reduced operational complexity within the first year.”

Follow-up: “If the identity broker goes down, what’s your breakglass strategy for Salesforce admin access?”

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

The judge wants to hear the reasoning behind a correct decision.

Q4.1: OWD Selection Reasoning

Judge: “WHY did you choose Private as the OWD for the Account object? Walk me through your specific reasoning.”

What they’re testing: Systematic OWD selection based on the most restrictive user.

Model answer: “I started by identifying the most restrictive user. Three populations: internal sales reps (territory-only visibility), support agents (all accounts), partner users (own company only). Partners are most restrictive — must not see other companies’ data. Since sharing is additive and can never restrict below OWD, the floor must be Private. From there: support agents get access via a hierarchy position above regional roles. Sales reps get cross-territory visibility through two criteria-based rules with public groups. Partners get access through sharing sets matching Contact.AccountId. I considered Public Read Only (eliminates two internal rules) but it exposes Account names to partners — the scenario specifically calls out Account names as confidential between partners.”

Follow-up: “If the business later adds a requirement for all internal users to see all accounts, how do you adjust without affecting partner visibility?”

Q4.2: JWT Bearer Over Client Credentials

Judge: “WHY did you select JWT Bearer for the middleware instead of Client Credentials? Both are server-to-server flows.”

What they’re testing: JWT Bearer (user context) vs Client Credentials (app context) critical difference.

Model answer: “The deciding factor is user context. JWT Bearer authenticates as a specific Salesforce user via the ‘sub’ claim, applying that user’s CRUD, FLS, and sharing rules. Client Credentials authenticates as the Connected App’s designated execution user — a fixed service account. In this scenario, the middleware needs different sharing contexts depending on which department triggers the sync. JWT Bearer lets me set the ‘sub’ claim per request. Client Credentials would run everything as one fixed user regardless of business context. Trade-off: JWT Bearer requires certificate management (key pair generation, Connected App upload, rotation). Client Credentials is simpler but the security model is fundamentally different. If the integration only needed a single system-level view without per-user sharing, Client Credentials would be correct. The Connected App must be pre-authorized for each user the integration will impersonate. Pre-approve via admin policy on the Connected App to avoid requiring individual user consent.”

Follow-up: “JWT Bearer doesn’t issue a refresh token. How does your middleware handle token expiration during a long-running batch?”

Q4.3: Deterministic vs Probabilistic Encryption

Judge: “WHY did you choose deterministic encryption for Phone and Email over probabilistic? Walk me through the decision.”

What they’re testing: Encryption scheme selection driven by functional requirements, not maximum security default.

Model answer: “The choice comes down to how these fields are used. Phone and Email are used in duplicate detection rules, SOQL WHERE clauses for record matching, and report filters. Probabilistic would break all of those — different ciphertext for identical plaintext every time. Deterministic preserves exact-match because identical plaintext always produces identical ciphertext. Trade-off: deterministic is theoretically less secure (frequency analysis possible), but for Email and Phone in a B2B context the frequency distribution is relatively flat. For fields not needing searchability (Description, Notes), I used probabilistic for maximum security. The rejected alternative was leaving fields unencrypted, which PCI-DSS (Phone) and GDPR (Email) rule out.”

Follow-up: “What about auto-complete and typeahead on the Email field? Does deterministic support those?”

Q4.4: Role Hierarchy Depth Rationale

Judge: “WHY did you limit the role hierarchy to 5 levels when the client’s org chart has 9 management levels?”

What they’re testing: Role hierarchy designed for data access, not org chart, with performance awareness.

Model answer: “The role hierarchy controls data visibility, not reporting relationships. Analysis found 5 truly distinct data access tiers: executive leadership (all records), regional directors (region data), department managers, team leads, and individual contributors. The remaining 4 org chart levels share identical data access needs with an adjacent level, so they share a role. Every role must justify its existence with a unique data access requirement. Performance: each additional level increases sharing calculation complexity. The group membership table grows with every role. With 50,000 users, the difference between 5 and 9 levels affects recalculation measurably. Management visibility needs are handled through custom reports and dashboards, not hierarchy levels.”

Follow-up: “If the client insists the hierarchy must match their org chart, how do you handle the performance implications?”

Q4.5: BYOK Over Cache-Only Keys

Judge: “WHY did you choose BYOK over cache-only keys? The scenario has strict regulatory requirements for key control.”

What they’re testing: BYOK vs cache-only keys: key control versus availability risk.

Model answer: “Cache-only keys provide maximum control — the key is never persisted in Salesforce, only in RAM. But that creates a hard availability dependency: if the customer’s key service goes down, Salesforce cannot decrypt any data. This scenario has a 24/7 customer-facing portal; a key service outage means portal users can’t view their own case details or encrypted contact information. BYOK gives the customer key control (generated in their HSM, uploaded via API) but the key is persisted as an encrypted tenant secret. The customer controls rotation and revocation. Trade-off: a copy exists in Salesforce’s infrastructure. I’d mitigate by documenting Salesforce’s SOC 2 / ISO 27001 certifications. If the legal team absolutely requires no copy ever leaves their infrastructure, cache-only is the only option and I’d architect the key service for five-nines availability.”

Follow-up: “If the customer later wants to switch from BYOK to cache-only, what’s the migration process and risk?”

Judge: “WHY did you use ‘inherited sharing’ on utility classes instead of explicitly marking them ‘with sharing’?”

What they’re testing: Correct use of inherited sharing for context-flexible utility classes.

Model answer: “The utility classes are called from multiple contexts: user-facing controllers (‘with sharing’) and system batch processes (‘without sharing’). If I mark the utility ‘with sharing,’ it would enforce sharing even from the batch process. If ‘without sharing,’ it bypasses sharing from the controller. ‘inherited sharing’ adopts the caller’s context. When invoked as a transaction entry point, it defaults to ‘with sharing’ — the safe default. The alternative of two versions violates DRY. Trade-off: security behavior is implicit, making code review harder because you must trace the full call chain. In a code review, I’d trace all call paths to verify no unsafe context invokes the utility.”

Follow-up: “In a code review, how would you verify that an inherited sharing utility class is never called from an unsafe context?”

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

The judge is testing whether you can trace impacts across domains.

Q5.1: OWD Change Impact on Integration

Judge: “You’ve proposed changing Account OWD from Public Read Only to Private. Walk me through the cascading impact on your integration architecture.”

What they’re testing: OWD changes cascading through integrations, sharing tables, and API behavior.

Model answer: “First, the sharing engine creates share table rows for every Account record. At 3 million accounts, that’s millions of new AccountShare rows. Sharing recalculation takes hours — schedule during maintenance. Second, integration users who previously had universal Read access under Public Read Only now see only records they own or have explicit sharing access to. The sharing model was always enforced; the baseline changed. If the integration user previously relied on Public Read Only, it now needs explicit sharing or ‘View All’ on Account via a Permission Set. Third, any Apex code running ‘with sharing’ returns fewer records. Integration tests that passed before may fail. Fourth, report-based integrations return incomplete results if the running user lacks full visibility. Mitigation: run OWD change in sandbox first, execute full integration regression, verify record counts, update integration user sharing before production, and schedule the change during maintenance.”

Follow-up: “What if sharing recalculation isn’t complete when users start working the next morning?”

Q5.2: IdP Migration Cascading Impact

Judge: “The client wants to switch from Okta to Azure AD as their IdP. What cascading changes does this require?”

What they’re testing: IdP change impact across SSO, middleware auth, Connected Apps, MFA, and provisioning.

Model answer: “IdP switch is one of the highest-impact changes. Cascade: 1) SAML SSO config: new IdP metadata, signing certificate, claim mappings, My Domain login page update. 2) Connected Apps using SAML Bearer flow break because the assertion issuer changes; every middleware integration needs the new IdP’s assertions. 3) JIT handler: may need updates for different attribute names/formats from Azure AD. 4) SCIM: connector configuration moves from Okta to Azure AD with new group and attribute mappings. 5) MFA: Azure AD Conditional Access policies must replicate Okta’s MFA enforcement. 6) Login Discovery: if other apps still use Okta during transition, routing must coexist with both IdPs. 7) Breakglass accounts: verify they still work. Plan as phased migration with parallel-running period, migrating users in waves, decommissioning Okta only after full validation.”

Follow-up: “During the parallel period with both IdPs active, how do you prevent a terminated user from authenticating via the old IdP?”

Q5.3: Encryption Impact on Data Migration

Judge: “You’ve decided to enable Shield Platform Encryption on several standard fields. What’s the cascading impact on your data migration plan?”

What they’re testing: Encryption impact on migration tooling, query behavior, validation, and integrations.

Model answer: “Encryption cascades into migration: 1) Enable encryption before data load so all data is encrypted from the start (loading first creates a mixed encryption state that breaks consistent querying). 2) Validation rules, triggers, and processes referencing encrypted fields with LIKE/ORDER BY will fail during the load. 3) Migration validation scripts comparing source and target using LIKE queries won’t work on encrypted fields — switch to exact-match. 4) Skinny tables can still contain encrypted data, but probabilistic-encrypted fields lose custom index support (deterministic retains index support), so query optimization plans may need alternatives depending on the encryption scheme. 5) Integration feeds referencing encrypted fields need testing for changed query behavior. 6) The Encrypted field attribute persists in metadata deployments, but encryption keys must be managed separately per environment (keys are not transferable via metadata). Enable Shield in each target org before deploying. Mitigation: enable in sandbox, run full migration dry run, document every failure, fix code and scripts, then proceed to production.”

Follow-up: “If you need to encrypt existing production data after go-live, how does the background encryption job work?”

Q5.4: LDV + Private OWD Performance Cascade

Judge: “Account and Opportunity OWD are Private. Sharing recalculation takes 6 hours after adding a sharing rule. 15 million Account records. What’s the cascade and fix?”

What they’re testing: LDV + Private OWD performance cascade and architectural mitigation.

Model answer: “At 15M with Private OWD, every record has share table rows. Six hours means the sharing model is at its ceiling. Cascade: during recalculation, users see inconsistent access. Concurrent DML experiences locking contention. Reports and list views return variable results. Integration queries return inconsistent counts. Fix: 1) Data archival to Big Objects (reduce 15M to active 3M working set). 2) Flatten role hierarchy to reduce group membership calculation. 3) Consolidate sharing rules using public groups instead of individual roles. 4) Defer sharing calculation during bulk operations (requires a case with Salesforce Support to enable; typically granted for orgs meeting specific volume criteria). 5) Evaluate whether some objects can move to Public Read Only if security genuinely allows it.”

Follow-up: “If you defer sharing calculation and a user queries before recalculation completes, what happens?”

Q5.5: Permission Model Cascading to Deployment

Judge: “Your permission model uses 15 custom profiles. Deploying security changes takes 3 days because of metadata dependencies. What’s the cascade and restructuring path?”

What they’re testing: Permission model impact on deployment pipeline and metadata dependencies.

Model answer: “15 profiles are monolithic metadata touching every other type: objects, fields, FLS, layouts, record types, tabs, Apex, VF, system perms. Changing FLS across 15 profiles = 15 metadata file changes. Each conflicts with concurrent development. Restructuring: Phase 1 audit and decompose profiles into atomic PSs. Phase 2 create PSGs mirroring current assignments. Phase 3 assign Minimum Access profile + PSGs in sandbox. Phase 4 validate. Phase 5 production. Deployment improvement: PSs deploy independently of profiles. FLS changes affect one PS, not 15. New objects require updating only the relevant PS. The migration effort is significant but the ongoing benefit is dramatic.”

Follow-up: “What’s the deployment sequence for Permission Sets, PSGs, and Muting PSs when deploying to a new sandbox?”

Q5.6: Board Presentation Gap Recovery

Judge: “You need to present your security architecture to the CTA board. The judges find a gap in your sharing model. Walk me through how you handle that.”

What they’re testing: Board presentation communication strategy when a security gap is identified.

Model answer: “The worst response is defensive or dismissive. The best follows a pattern: 1) Acknowledge directly: ‘You’re right, that’s a gap.’ 2) Assess impact on the spot. 3) Propose the fix immediately with trade-offs. 4) Connect it to the broader architecture. 5) Close: ‘Does that address your concern?’ The board is testing whether you can think on your feet, acknowledge gaps honestly, and produce architecturally sound solutions under pressure. They’re not looking for a perfect initial presentation — they’re looking for architectural reasoning ability.”

Follow-up: “If the judge pushes back and says your proposed fix introduces too much sharing complexity, how do you pivot?”

Q5.7: Org Consolidation Security Cascade

Judge: “The business consolidates from three orgs to one post-M&A. What cascading security decisions does this drive?”

What they’re testing: Org strategy change driving security model redesign across all domains.

Model answer: “Sharing model: find the most restrictive OWD per object across all three populations. If Org A is Public Read Only and Org B is Private (due to partners), the consolidated org uses Private — Org A’s users now need sharing rules. Role hierarchy: three hierarchies must merge into one coherent structure designed for combined access patterns, not stitched together. Identity: three SSO configurations potentially with different IdPs; use Login Discovery for routing during transition, long-term consolidate to identity broker. Profiles/permissions: consolidate into unified PSG model. Encryption: Shield licenses are per-org; keys don’t transfer. The migration user must have ‘View Encrypted Data’ permission to export cleartext values. Without it, exported data contains masked/gibberish values. Plan for a window when data is in cleartext during transit and use encrypted transfer channels.”

Follow-up: “During consolidation, how do you maintain compliance for data being moved between orgs when encrypted data is decrypted for export?”

Q5.8: Regulation-Driven Encryption Cascade

Judge: “A new regulation requires encrypting all PII fields across the org within 90 days. What cascading impacts and how do you scope the project?”

What they’re testing: Regulation-driven encryption scope expansion and cross-domain impact.

Model answer: “Cascades through every domain: 1) Scope via data classification — inventory every PII field, categorize into deterministic (needs searchability) and probabilistic (doesn’t). 2) Functionality impact: identify every SOQL query, report, formula, workflow, validation rule, flow, and integration referencing each field. 3) Code remediation: refactor LIKE/ORDER BY on newly encrypted fields. 4) Integration impact: external systems receiving PII via API may need to handle changed query behavior. 5) Key management: architect BYOK/cache-only/managed with rotation and DR before go-live. 6) Deployment: the Encrypted field attribute persists in metadata deployments, but encryption keys must be managed separately per environment. Enable Shield in each target org before deploying. Timeline: data classification weeks 1-2, impact assessment 2-4, remediation 4-10, testing 8-12, production 11-13.”

Follow-up: “If the impact assessment reveals 200 reports filtering on PII fields, how do you prioritize which to fix versus retire?”

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.