Last updated: May 2026
App-Arch-301 — Salesforce Certified Application Architect
Test your knowledge with official exam-style questions
Questions and options are shuffled each attempt
▶Salesforce Certified Application Architect — Practice Exam Set 1: All Questions & Explanations
Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.
1. An org has 50 million Account records. Reports and list views are timing out. What is the first recommendation to address this?
- A. Archive old Account records to an external database
- B. Enable skinny tables for frequently queried fields on the Account object
- C. Create custom indexes on fields used in WHERE clauses and ORDER BY in reports(correct)
- D. Move to a higher Salesforce edition with more processing capacity
Explanation: For Large Data Volume (LDV) orgs, indexing is the primary performance lever. Custom indexes on fields used in filter conditions (WHERE clauses) and sort fields dramatically reduce query time by allowing the database to avoid full-table scans. Skinny tables replicate a subset of columns for specific use cases — useful but a secondary optimization. Archiving is a data governance decision, not a first-line performance fix.
2. What is a 'Skinny Table' in Salesforce and when should it be considered?
- A. A lightweight Salesforce object with fewer than 10 fields for performance
- B. A Salesforce-managed database table containing a customer-defined subset of frequently queried fields, used to accelerate SOQL queries on large objects without JOIN overhead(correct)
- C. A compressed data archive table for records older than 2 years
- D. A virtual table created by a SOQL query in Apex
Explanation: Skinny Tables are an advanced Salesforce LDV performance feature. Salesforce support creates a read-only database table containing only the specified fields from an object. Queries against those fields read from the skinny table (no JOIN with the main table), reducing query time dramatically for large objects. They must be requested from Salesforce support and are appropriate only after standard indexing has been optimized.
3. Which SOQL query pattern should be avoided to maintain performance on large objects?
- A. Using a WHERE clause with an indexed field
- B. Using LIKE '%keyword%' with a wildcard at the beginning of a string(correct)
- C. Using ORDER BY on an indexed field
- D. Limiting results with LIMIT 200
Explanation: Leading wildcards in LIKE clauses (e.g., WHERE Name LIKE '%Corp%') prevent index usage — the database must scan all rows. Trailing wildcards (WHERE Name LIKE 'Corp%') can use indexes. For full-text search patterns, Salesforce recommends using SOSL (Salesforce Object Search Language) or Einstein Search instead of SOQL with leading wildcards on large objects.
4. An architect is designing a master data management (MDM) strategy for a company with Salesforce, an ERP, and a data warehouse. What role should Salesforce play?
- A. Salesforce should always be the system of record for all enterprise data
- B. The role depends on data domain — Salesforce is typically the system of record for customer and opportunity data; the ERP for financial and inventory data(correct)
- C. The data warehouse should always be the system of record since it stores historical data
- D. All three systems should store identical master data to ensure availability
Explanation: MDM strategy assigns system of record (SoR) designation by data domain based on where data originates and is most authoritative. Salesforce is typically SoR for customer relationships, contacts, opportunities, and service interactions. ERP systems own inventory, financials, and orders. The data warehouse aggregates for analytics but is rarely a SoR. This avoids conflicts where each system tries to own all data.
5. Which of the following are characteristics of Salesforce's multi-tenant architecture that architects must design around? (Select TWO)
- A. Governor limits enforce resource quotas per transaction to ensure fair use across all tenants(correct)
- B. Each org has its own dedicated database server with full physical isolation
- C. Platform Events and Apex async processing can offload heavy operations outside synchronous governor limits(correct)
- D. Salesforce allows unlimited SOQL queries per transaction to support complex applications
Explanation: Salesforce's multi-tenant model: governor limits enforce per-transaction resource quotas (SOQL queries: 100 per sync transaction, DML rows: 10,000, heap size: 6MB, etc.) to protect shared infrastructure from any single tenant consuming excessive resources. Async processing (future methods, queueable, batch Apex) and Platform Events allow offloading work outside synchronous limits. All tenants share infrastructure — there are no dedicated servers per org.
6. What is the purpose of the 'Sharing Recalculation' process in Salesforce?
- A. A scheduled job that recalculates roll-up summary field values after bulk updates
- B. The process that runs when OWD settings or sharing rules are changed to rebuild the sharing access table for all affected records(correct)
- C. An API call that refreshes the field-level security cache
- D. A report that identifies records with conflicting sharing rules
Explanation: When OWD settings change or sharing rules are created/modified/deleted, Salesforce must recalculate record access for all records in the affected objects. This 'sharing recalculation' rebuilds the internal sharing access table (AccountShare, OpportunityShare, etc.) — a resource-intensive async process that can take minutes to hours for LDV orgs. Architects must account for this latency when planning OWD/sharing changes in production.
7. An architect needs to design a solution where a large number of records are created nightly via an API integration. What pattern minimizes lock contention on parent records?
- A. Use synchronous Apex triggers that process each record immediately on insert
- B. Use Bulk API 2.0 in parallel mode, grouping records by parent to minimize lock scope(correct)
- C. Insert all records sequentially in a single large batch
- D. Disable all triggers and validation rules during the nightly load
Explanation: Record lock contention occurs when concurrent DML operations compete for the same parent record's lock (via Master-Detail or lookup relationships). Using Bulk API 2.0 in parallel mode groups records that share parents into separate batches, reducing cross-batch contention. Grouping by parent record in the same batch avoids inter-batch conflicts. Serial processing avoids parallelism entirely but is slow. Disabling triggers is a risky approach that breaks business logic.
8. What is the difference between Authentication and Authorization in the context of Salesforce Identity?
- A. Authentication verifies who you are; Authorization determines what you are allowed to do(correct)
- B. Authorization is the first step; Authentication grants permissions after authorization
- C. Both terms mean the same thing in Salesforce Identity context
- D. Authentication grants app access; Authorization grants record access
Explanation: Authentication answers 'Who are you?' — verifying identity via credentials (username/password, SSO, MFA). Authorization answers 'What are you allowed to do?' — determining access rights via profiles, permission sets, sharing rules, and FLS. In Salesforce, OAuth 2.0 handles authorization (granting app access to data). SAML/OIDC handle authentication (verifying identity via SSO). Both are distinct security layers.
9. A company wants external users to authenticate to Salesforce using their corporate Active Directory credentials. Which Salesforce feature enables this?
- A. Salesforce Identity: SAML-based SSO with Salesforce as the Service Provider (SP)(correct)
- B. OAuth 2.0 JWT Bearer Flow
- C. Multi-Factor Authentication (MFA) via Salesforce Authenticator
- D. Connected App with IP Allowlisting
Explanation: SAML-based Single Sign-On (SSO) with Salesforce as the Service Provider allows the corporate Active Directory (via ADFS or Azure AD as Identity Provider) to authenticate users. Users log in with their corporate credentials; the Identity Provider sends a SAML assertion to Salesforce, which grants access. OAuth 2.0 JWT Bearer is for app-to-app authorization, not user authentication via AD.
10. What is the purpose of a 'Connected App' in Salesforce?
- A. A pre-built integration template connecting Salesforce to common SaaS platforms
- B. A framework that allows external applications to authenticate and access Salesforce APIs using OAuth 2.0 flows(correct)
- C. A Salesforce AppExchange listing for third-party applications
- D. A tool for monitoring which external apps are currently connected to Salesforce
Explanation: A Connected App defines the OAuth 2.0 configuration for an external application accessing Salesforce. It provides the Client ID and Client Secret for OAuth flows, defines allowed OAuth scopes (read, write, api, etc.), sets IP ranges, and controls admin and user approval requirements. Every external app integrating with Salesforce APIs must have a Connected App registered.
11. An external application needs to make server-to-server API calls to Salesforce without a user logging in. Which OAuth 2.0 flow is most appropriate?
- A. Web Server Flow (Authorization Code)
- B. User-Agent Flow (Implicit)
- C. JWT Bearer Flow (server-to-server, no user interaction)(correct)
- D. Username-Password Flow
Explanation: The OAuth 2.0 JWT Bearer Flow is designed for server-to-server integration where no user is present. The client application signs a JWT with its private key and sends it to Salesforce's token endpoint. Salesforce validates the signature using the pre-registered certificate and issues an access token. The Username-Password Flow transmits credentials in plaintext (not recommended). The Web Server and User-Agent flows require user browser interaction.
12. Which of the following are OAuth 2.0 flows supported by Salesforce? (Select THREE)
- A. Web Server Flow (Authorization Code Grant)(correct)
- B. JWT Bearer Flow (server-to-server)(correct)
- C. Device Flow (for input-constrained devices like smart TVs)(correct)
- D. SCIM Flow (for user provisioning)
- E. RADIUS Flow (for network access control)
Explanation: Salesforce supports multiple OAuth 2.0 flows: Web Server (Authorization Code — for web apps with server-side secret), JWT Bearer (server-to-server), Device Flow (for devices that can't display a browser), User-Agent (Implicit — deprecated), and Refresh Token flow. SCIM is a protocol for user provisioning, not an OAuth flow. RADIUS is a network access protocol unrelated to Salesforce OAuth.
13. Salesforce is configured as an Identity Provider (IdP) for an external application. A user logs into Salesforce and then accesses the external app without re-entering credentials. What protocol is being used?
- A. OAuth 2.0 Web Server Flow
- B. SAML SSO with Salesforce as Identity Provider(correct)
- C. OpenID Connect with Salesforce as Authorization Server
- D. LDAP Federation
Explanation: When Salesforce acts as an Identity Provider (IdP), it can issue SAML assertions to external applications (Service Providers). After a user logs into Salesforce, they can access other SAML-enabled apps without re-authentication. Salesforce can also act as an OIDC IdP using OpenID Connect. SAML is the traditional SSO standard for enterprise applications. OAuth 2.0 is an authorization protocol, not an authentication/SSO protocol by itself.
14. What is the Salesforce REST API best suited for?
- A. High-volume bulk data processing of millions of records
- B. Real-time, lightweight CRUD operations on Salesforce objects using standard HTTP methods and JSON/XML(correct)
- C. Complex ad-hoc searches across multiple object types
- D. Streaming real-time event data to external consumers
Explanation: The Salesforce REST API is optimized for lightweight, real-time CRUD operations (Create, Read, Update, Delete) on individual or small sets of records using HTTP methods (GET, POST, PATCH, DELETE) with JSON/XML payloads. For bulk operations (millions of records), the Bulk API is preferred. For cross-object searches, SOSL via the Search API is used. For streaming events, the Streaming API (CometD/SSE) or Platform Events are appropriate.
15. A real-time integration requires an external system to be notified immediately when an Account's status field changes in Salesforce. Which Salesforce feature is best suited?
- A. Scheduled Apex that polls for Account changes every 5 minutes
- B. Platform Events published by a Record-Triggered Flow when the Account status changes(correct)
- C. Outbound Messages from a Workflow Rule
- D. The external system polls the REST API for Account changes
Explanation: Platform Events are Salesforce's publish-subscribe event bus. A Record-Triggered Flow publishes a Platform Event when the Account status changes. The external system subscribes to the event channel via CometD, the Streaming API, or Apex trigger — receiving notifications in near real-time. Outbound Messages (Workflow-based) are being retired. Polling (scheduled Apex or external REST polling) introduces latency and unnecessary overhead.
16. What is Salesforce Connect (External Objects) used for?
- A. Connecting two Salesforce orgs for data sharing
- B. Accessing real-time data from external systems as if it were native Salesforce data, without copying it into Salesforce(correct)
- C. Syncing Salesforce data with an external data lake nightly
- D. A REST API adapter that converts external system responses to Salesforce record format
Explanation: Salesforce Connect uses OData (Open Data Protocol) adapters or custom adapters to make external system data appear as 'External Objects' in Salesforce. Users can view, relate, and search this data in Salesforce UI as if it were native — but it's fetched in real time from the external system on demand, without ETL replication. This avoids data duplication while enabling Salesforce-native access patterns.
17. When should an architect choose asynchronous integration over synchronous integration? (Select TWO)
- A. When the Salesforce user needs an immediate response from the external system before proceeding
- B. When the external system's response time can vary and delaying the Salesforce transaction is unacceptable(correct)
- C. When data loss prevention is critical and message queuing can guarantee delivery even if the external system is temporarily unavailable(correct)
- D. When the external system needs to validate data before Salesforce allows the user to save the record
Explanation: Asynchronous integration is preferred when: (1) the external system response time is variable or slow — blocking the Salesforce transaction is unacceptable; (2) reliability/guaranteed delivery is needed — message queues (JMS, Anypoint MQ, AWS SQS) ensure delivery even if the external system is down. Synchronous integration (callouts) is needed when the user requires an immediate response or when validation from the external system is required before save.
18. What is an Apex Callout and what governor limit applies to synchronous callouts from a single transaction?
- A. An HTTP request from Apex to an external service; maximum 10 callouts per transaction
- B. A SOQL query that calls external data; maximum 100 queries per transaction
- C. An HTTP request from Apex to an external service; maximum 100 callouts per transaction(correct)
- D. A Platform Event published to an external subscriber; maximum 5 per transaction
Explanation: Apex Callouts use HttpRequest/HttpResponse classes to make HTTP calls to external REST APIs or the Http class. The governor limit is 100 callouts per synchronous transaction (and 100 per async Apex execution). The total cumulative callout time limit is 120 seconds per synchronous transaction. Apex DML cannot precede a synchronous callout in the same transaction (to prevent mixed-context failures).
19. A company uses an ESB (Enterprise Service Bus) as the integration middleware. When Salesforce is a data consumer (receiving data FROM the ESB), which integration pattern is typically implemented?
- A. Salesforce polls the ESB periodically via REST API calls
- B. The ESB pushes data into Salesforce via REST API (using Salesforce's published REST endpoints)(correct)
- C. Salesforce subscribes to the ESB's message queue using a Streaming API connection
- D. Platform Events are published by the ESB to Salesforce's event bus
Explanation: When Salesforce is the data consumer and an ESB is the publisher, the typical pattern is the ESB pushes data into Salesforce via the Salesforce REST, SOAP, or Bulk API. The ESB transforms source system data to the Salesforce format and makes API calls to create/update records. Platform Events are published from Salesforce outward, not from external systems inbound (though external systems can publish Platform Events via the REST API too).
20. A Salesforce org stores healthcare data subject to HIPAA. Which combination of Salesforce features supports HIPAA compliance?
- A. Field-Level Security + Profile-based access only
- B. Shield Platform Encryption + Event Monitoring + Field Audit Trail + MFA(correct)
- C. Classic Encryption + Role Hierarchy + Login History
- D. OWD set to Private + Sharing Rules restricted to healthcare roles
Explanation: HIPAA-compliant Salesforce implementations leverage: Shield Platform Encryption (AES-256 at rest for PHI fields), Event Monitoring (audit trail of user access and data export), Field Audit Trail (long-term history of PHI field changes — up to 10 years), and MFA (enhanced authentication). The Business Associate Agreement (BAA) with Salesforce is also required. Classic Encryption (AES-128) is generally insufficient for HIPAA.
21. What is Salesforce Shield's 'Field Audit Trail' feature and how does it differ from standard Field History Tracking?
- A. Field Audit Trail is identical to Field History Tracking but for custom objects only
- B. Field Audit Trail stores field change history for up to 10 years with up to 60 fields per object; standard Field History Tracking is limited to 18 months and 20 fields per object(correct)
- C. Field Audit Trail captures object creation/deletion; Field History Tracking captures field-level changes
- D. Field Audit Trail requires Apex; Field History Tracking is declarative
Explanation: Standard Field History Tracking: up to 20 fields per object, 18-month retention, stored in FieldHistory objects. Salesforce Shield Field Audit Trail: up to 60 fields per object, up to 10-year retention (configurable), separate big object storage (FieldHistoryArchive). Field Audit Trail is critical for compliance requirements (SOX, HIPAA, GDPR) that mandate long-term data lineage. It requires a Shield or Compliance add-on license.
22. An architect needs to restrict Salesforce access so that users can only log in from the company's corporate IP range (10.0.0.0/8). What is the most appropriate configuration?
- A. Set a Login IP Range on each user's profile(correct)
- B. Create a Network Access restriction in Setup > Security Controls > Network Access
- C. Configure a Connected App IP restriction policy
- D. Enable the 'Restrict Login from Untrusted IPs' setting in Session Settings
Explanation: Profile-level Login IP Ranges are the most granular and enforceable IP restriction mechanism. When set, users on that profile can ONLY log in from those IP ranges. Network Access (Trusted IPs) defines trusted networks where MFA/email verification is bypassed but doesn't block login from other IPs. Profile Login IP Ranges actually block login attempts from outside the specified range.
23. Which Salesforce features contribute to a defense-in-depth security architecture? (Select THREE)
- A. Multi-Factor Authentication (MFA) for all users(correct)
- B. Shield Platform Encryption for sensitive fields at rest(correct)
- C. Event Monitoring for auditing user behavior and detecting anomalies(correct)
- D. Setting all OWD to Public Read/Write for productivity
Explanation: Defense-in-depth uses multiple security layers: MFA (authentication strength — prevents credential theft attacks), Shield Platform Encryption (data protection at rest — prevents data exposure from backup or direct DB access), and Event Monitoring (detect anomalies, unauthorized exports, suspicious login patterns — enables threat detection and forensics). Public Read/Write OWD reduces security controls and is the opposite of defense-in-depth.
24. What is CSRF (Cross-Site Request Forgery) and how does Salesforce protect against it in custom Apex/Visualforce development?
- A. CSRF is an injection attack; Salesforce prevents it by escaping HTML output in Visualforce
- B. CSRF is an attack where a malicious site tricks an authenticated user's browser into making unauthorized Salesforce requests; Salesforce provides a CSRF token (View State or anti-CSRF token) included in form submissions(correct)
- C. CSRF is a phishing attack; Salesforce prevents it by requiring MFA for all API access
- D. CSRF only applies to Apex REST endpoints and is automatically prevented by OAuth validation
Explanation: CSRF attacks trick an authenticated user's browser into making forged requests to Salesforce (e.g., deleting records, changing data). Salesforce's Visualforce View State and anti-CSRF tokens validate that form submissions originate from legitimate Salesforce pages. Developers must ensure custom endpoints and LWC wire adapters properly handle CSRF tokens. HTML escaping prevents XSS, not CSRF.
25. An architect needs to ensure that a critical custom Apex REST endpoint is only accessible to an authorized external application. What is the recommended security design?
- A. Add a hardcoded API key check in the Apex code that the external app sends as a header
- B. Require OAuth 2.0 token authentication via a Connected App with appropriate OAuth scopes; validate the token in the Apex endpoint or rely on Salesforce platform validation(correct)
- C. Restrict the endpoint to a specific Profile using Permission Sets
- D. Use IP Allowlisting at the network level to prevent non-authorized IP addresses from reaching Salesforce
Explanation: The recommended approach for securing custom Apex REST APIs is OAuth 2.0 via a Connected App. The external app obtains an access token (JWT Bearer or Web Server flow), includes it as a Bearer token in API requests. Salesforce validates the token on every request. Combined with appropriate OAuth scopes and permission sets on the connected app, this provides industry-standard API security. Hardcoded API keys are a security anti-pattern.