Security: Quick Reference

Domain 2 (Security) is the second highest failure domain on the CTA exam. This quick reference guide distills the essentials into three quick-reference pages you can review in under 2 hours before a mock board.

Why Candidates Fail on Security

Failure Pattern	What the Board Sees
OWD set too open	Candidate does not understand the cardinal rule: access is additive only
Role hierarchy mirrors HR org chart	Hierarchy should model data access, not reporting lines
No systematic OWD walkthrough	Candidate guesses instead of walking object-by-object
Wrong OAuth flow selected	Candidate memorized names but cannot match flow to scenario
Page layouts used as security	FLS is the only true field-level security boundary
Implicit sharing ignored	Child record owners get Read on parent Account — security gap
No external OWD consideration	Partner/customer users see each other’s data

Quick Reference Guides

Guide	What It Covers	Time
Sharing Model Quick Ref	OWD decision tree, sharing rule types, role hierarchy design, implicit sharing, LDV impact	~40 min
Identity & SSO Quick Ref	SAML vs OAuth vs OIDC, all 6 OAuth flows, Connected Apps, JIT, MFA, Named Credentials	~40 min
Permissions Quick Ref	Profiles, Permission Sets, PSGs, Muting PS, FLS, CRUD, profile retirement timeline	~30 min
Portal & Experience Cloud Quick Ref	External licenses, HVCP sharing sets, guest user lockdown, portal role hierarchy, share groups	~30 min
Shield & Encryption Quick Ref	Shield components, encryption schemes, key management, what breaks, compliance mapping, Event Monitoring, FAT	~30 min

The Security Checklist (Use for Every Scenario)

Run through this for every CTA scenario before you present:

OWD per object — who is the most restrictive user? Start Private.
External OWD — are there portal/community users? Set separately.
Role hierarchy — designed for data access patterns, not org chart?
Sharing rules — what gaps remain after hierarchy? Criteria-based preferred.
Permission model — Minimum Access Profile + Permission Set Groups?
FLS — which fields does each user type need? FLS, not page layouts.
Identity/SSO — existing IdP? Salesforce as SP or IdP?
OAuth flows — which flow for which integration? Match to client type.
MFA — where is MFA enforced? IdP or Salesforce?
Encryption — regulatory requirement? Which fields? Which scheme?

Board Presentation Framework

When presenting any security decision, use this structure:

flowchart LR
    R["1. Recommend"] --> W["2. Why\n(tie to reqs)"]
    W --> T["3. Trade-off\n(what you sacrifice)"]
    T --> M["4. Mitigate\n(how you handle it)"]
    M --> A["5. Alternative\n(what you rejected)"]

    style R fill:#1565c0,color:#fff
    style T fill:#e65100,color:#fff
    style M fill:#2e7d32,color:#fff

Example script: “I recommend Private OWD for Accounts because the scenario includes partner users who should not see each other’s customer data. The trade-off is increased sharing complexity — I need three criteria-based sharing rules for internal cross-team visibility. I mitigate this by keeping the role hierarchy flat at four levels and using public groups as sharing targets. I considered Public Read Only but rejected it because partner users would see all Account names, which the scenario identifies as confidential.”

Also Know These Exist

Term	What It Is
Restriction Rules	Declaratively restrict record access beyond sharing model (further tighten, not open)
Scoping Rules	Filter which records are visible per user group (e.g., show only same-region records)
SCIM	Automated user provisioning/deprovisioning between IdP and Salesforce
External Identity Licenses	Authentication-only licenses — no community data access, just login
Login Discovery	Routes users to the correct IdP based on email domain at login

Deep Dive References

For full coverage of each topic, see the complete Domain 2 study materials:

For compliance frameworks (GDPR, HIPAA, SOX, PCI-DSS), see DevOps Quick Reference — Compliance Section.