Security

Key Takeaways

Security is the second highest failure domain on the CTA exam. Focus on sharing model design (OWD, role hierarchy, sharing rules), identity architecture (SAML, OAuth flows, MFA), and the trade-offs between security and usability. Judges probe deeply on record-level access, portal security, and encryption decisions.

This domain covers architecting secure solutions using platform security mechanisms, identity management, and data access controls. Security is the second highest failure domain on the CTA exam. Candidates most commonly fail on sharing model design, identity architecture, and the tension between security and usability.

Objectives

#	Objective	Key Topics
2.1	Architect solutions using appropriate platform security mechanisms	Sharing Model, Encryption
2.2	Security considerations for portal architecture (internal and external users)	Portal Security
2.3	Declarative platform security features for record-level security	Sharing Model, Field & Object Security
2.4	Programmatic platform security features	Programmatic Security
2.5	Object and field access permissions	Field & Object Security
2.6	Design and justify end-to-end identity management solutions	Identity & SSO

Key Topics

• Sharing Model: OWD, Role Hierarchy & Sharing Rules: the foundation of record-level security: OWD settings, role hierarchy design, sharing rules, implicit sharing, Apex managed sharing, teams, and territory management
• Identity & SSO: SAML, OAuth, and Access Management: SAML 2.0, all OAuth 2.0 flows, OpenID Connect, Connected Apps, My Domain, JIT provisioning, MFA, Named Credentials
• Field & Object Security: Profiles, Permission Sets & FLS: profiles, permission sets, permission set groups, muting permission sets, CRUD, View All/Modify All, FLS, the minimum access profile pattern
• Portal & Community Security: Experience Cloud Access: external user licenses, guest user security, HVCP sharing, external OWD, portal role hierarchy, sharing sets
• Experience Cloud Architecture: LWR vs Aura runtime, site templates, CMS architecture, SEO, CDN, multi-site strategy, Agentforce integration
• Programmatic Security: Apex Enforcement & Secure Coding: with/without/inherited sharing, CRUD/FLS enforcement, Named Credentials, secure coding, session-based permission sets
• Shield Platform Encryption, Event Monitoring & Field Audit Trail: deterministic vs probabilistic encryption, BYOK, cache-only keys, event monitoring, transaction security, field audit trail
• Territory Management Architecture: Sales Territories object model, hierarchy design, sharing interaction with role hierarchy, scaling limits, forecasting integration
• Security Decision Guides: visual decision flowcharts for OWD selection, sharing strategy, identity architecture, OAuth flow selection, encryption, and permission model
• Security Best Practices & Anti-Patterns: organized by sharing, identity, permissions, encryption, portal, and programmatic security
• Security Trade-offs: restrictive vs open OWD, security vs usability, encryption impact, sharing complexity vs performance

Practice

• Domain Grilling: D2 Security Q&A

Key Exam Focus Areas

• OWD design from the most restrictive user outward. The CTA board will ask “who is the most restrictive user for this object?” Any scenario with a user who cannot see all records of an object forces Private OWD. Starting with Public Read/Write and trying to restrict is architecturally impossible — access is additive only and cannot be removed below the OWD floor.
• Role hierarchy is a data access model, not an org chart. This distinction catches candidates repeatedly. The board will ask you to walk through your role hierarchy and then probe whether each level corresponds to a distinct data access pattern or a reporting relationship. If the hierarchy mirrors the org chart instead of the access model, expect a direct challenge.
• Sharing rule layering and implicit sharing. Candidates commonly forget that child record owners get implicit Read access to the parent Account even when Account OWD is Private. The board uses this to reveal gaps in the candidate’s mental model of the sharing stack. Know all seven layers and the order in which they are evaluated.
• Restriction Rules have a narrow object scope. Restriction Rules restrict which records a user can see within their existing sharing access, but they are only supported on a limited set of standard objects. Proposing Restriction Rules for objects they do not support is an instant red flag.
• OAuth flow selection and the PKCE requirement for public clients. The board probes whether candidates know that Authorization Code without PKCE is insecure for mobile and SPA clients because the client secret cannot be stored safely. Using SAML Bearer as the go-to for all API access is another common mistake — know when each of the six flows applies.
• Shield encryption’s functional trade-offs are as important as the decision to encrypt. Candidates who recommend Shield without articulating that deterministic encryption breaks LIKE queries, ORDER BY, and aggregates, or that probabilistic encryption breaks all filtering, fail on this topic. The board wants to hear the cost alongside the benefit.
• Portal security requires separate OWD configuration and the right license type. Changing the internal OWD does not automatically update the external OWD. Using Customer Community Plus when Community suffices adds unnecessary cost and complexity. Guest user profiles must be explicitly locked down — no default security applies.
• Apex sharing keywords are not optional. Every Apex class runs in a sharing context. Omitting the keyword defaults to inheriting context (or without sharing at entry point), which is a latent security vulnerability. The board will ask whether programmatic code enforces CRUD and FLS, and “Apex enforces sharing automatically” is a wrong answer.

Related Topics

Security touches every layer of a solution. These domains have the strongest security interdependencies:

• System Architecture: Org structure decisions (single org vs multi-org, licensing tiers, user populations) directly constrain the security architecture. The number and type of user personas determine the OWD settings, role hierarchy depth, and sharing rule complexity. Compliance requirements captured at the org design layer cascade into specific Shield and identity requirements.
• Data Architecture: Private OWD on high-volume objects creates large share tables and sharing recalculation overhead that becomes a bottleneck at LDV scale (10M+ records). Shield Platform Encryption on fields breaks SOQL filtering, ORDER BY, and aggregation functions, which directly impacts query design, report architecture, and data model decisions. Field Audit Trail retention policy must be coordinated with the broader data archival strategy.
• Solution Architecture: secure design patterns determine which declarative vs programmatic approaches are viable
• Integration: Every external system integration requires an OAuth flow selection, a Connected App configuration, and a Named Credentials implementation for outbound callout credentials. Integration users must have the minimum permissions required for the integration scope, not Modify All. The security architecture of the integration layer (which flows, which scopes, which execution users) is a direct output of Domain 2 decisions.
• Development Lifecycle: Permission Sets and Permission Set Groups deployed via CI/CD pipelines must maintain correct assignment state across environments. Data Masking in sandboxes prevents PII exposure during development and testing. Apex code reviews must validate sharing keywords, CRUD/FLS enforcement, and the absence of hardcoded credentials. Security scanning in the pipeline catches without sharing usage that lacks documented justification.

Frequently Asked Questions

What security topics does the CTA exam focus on most heavily?

The CTA exam probes deepest on sharing model design (OWD settings, role hierarchy, sharing rules, implicit sharing), identity architecture (SAML 2.0, OAuth 2.0 flows, MFA, JIT provisioning), and the interplay between field-level security, profiles, and permission sets. Portal security for Experience Cloud external users is also tested heavily.

How is Security scored in the CTA review board?

Judges evaluate whether the sharing model is appropriately restrictive without being overly complex, whether identity flows are correctly selected for each user type, and whether you can defend the trade-offs between security and usability. They expect you to articulate why you chose a specific OWD setting and how the role hierarchy interacts with sharing rules.

What are the most common mistakes in Security during the CTA exam?

Candidates commonly fail by setting OWD to Public Read/Write without justification, confusing OAuth flow types (using the wrong flow for server-to-server vs user-facing scenarios), ignoring guest user security implications in Experience Cloud, not addressing encryption’s impact on search and filtering, and failing to account for implicit sharing through master-detail relationships.

When should I recommend Shield Platform Encryption in a CTA scenario?

Recommend Shield when the scenario mentions regulatory compliance requiring encryption at rest (HIPAA, PCI, GDPR), sensitive data fields that must be protected even from admins, or audit trail requirements beyond standard field history tracking. Always address the trade-offs: deterministic encryption limits filter and search capabilities, and probabilistic encryption restricts them further.

How do I choose between sharing rules, Apex sharing, and teams for record access?

Use sharing rules for predictable, criteria-based or ownership-based access patterns. Use teams (Account Teams, Opportunity Teams) when access follows relationship-based patterns tied to specific records. Use Apex managed sharing when access logic is too complex for declarative rules or requires runtime calculation. Always prefer the simplest mechanism that meets the requirement.