SAA Development & Deployment 3 β Questions and Answers
Question 1: A managed package installed in a subscriber org throws an exception. The ISV wants to log errors without exposing internal logic. Which feature supports this?
- Custom Exception classes exposed as global
- Salesforce Shield Event Monitoring
- The Apex Logger utility in Developer Console
- Platform Events published from within the managed package (Correct answer)
Correct answer: Platform Events published from within the managed package
Platform Events can be published from within managed package Apex to surface error information to subscribers without exposing internal implementation details.
Question 2: Which Salesforce feature allows an architect to deploy metadata changes to production without executing tests, provided the components are not Apex classes or triggers?
- Quick Deploy after a successful validation
- Metadata API deploy with checkOnly=true
- Change Set with test level NoTestRun (Correct answer)
- SFDX force:source:deploy with --ignorewarnings flag
Correct answer: Change Set with test level NoTestRun
Change Sets and Metadata API deployments with test level NoTestRun skip test execution when no Apex components are included in the deployment.
Question 3: An architect wants to separate configuration data (like feature flags) from code so non-developers can modify it without a deployment. What is the BEST approach?
- Hardcode values in Apex constants
- Use Custom Metadata Types to store configuration records (Correct answer)
- Store values in Custom Labels
- Use Static Resources for configuration JSON
Correct answer: Use Custom Metadata Types to store configuration records
Custom Metadata Types are deployable, versionable configuration records that can be modified by admins without requiring a code deployment.
Question 4: A release manager notices that a destructive change (deleting a custom field) was included in a change set. What must accompany this change set for the deletion to succeed?
- A separate destructiveChanges.xml file deployed before the main package (Correct answer)
- A pre-deploy Apex script to null out field references
- The field must first be deprecated using the @deprecated annotation
- No additional steps are needed; change sets handle deletions automatically
Correct answer: A separate destructiveChanges.xml file deployed before the main package
Deleting metadata components requires a destructiveChanges.xml file, which must be deployed separately before the main deployment package.
Question 5: Which sandbox type refreshes the fastest and is MOST appropriate for rapid iterative development with small teams?
- Full Sandbox
- Partial Copy Sandbox
- Developer Sandbox (Correct answer)
- Developer Pro Sandbox
Correct answer: Developer Sandbox
Developer Sandboxes refresh the fastest (within minutes) because they copy only metadata with no production data, making them ideal for rapid development iterations.
Question 6: An architect needs Apex code to execute asynchronously after a callout completes, even if the initial transaction fails. Which pattern achieves this?
- Using @future(callout=true) with a try-catch block
- Chaining a Queueable Apex job from within the callout method
- Publishing a Platform Event from the callout and subscribing with an Apex trigger (Correct answer)
- Using a Scheduled Apex job to poll for callout results
Correct answer: Publishing a Platform Event from the callout and subscribing with an Apex trigger
Publishing a Platform Event from a callout and subscribing with an Apex trigger decouples the processing from the original transaction, ensuring execution even if the initial transaction rolls back.
Question 7: A developer wants to test a class that makes HTTP callouts in an Apex unit test. What is the REQUIRED approach?
- Use Test.setMock() with an HttpCalloutMock implementation (Correct answer)
- Use @future(callout=true) inside the test method
- Enable actual HTTP callouts by setting Test.allowCallouts(true)
- Mock the response using a Static Resource JSON file
Correct answer: Use Test.setMock() with an HttpCalloutMock implementation
Salesforce requires using Test.setMock() with an HttpCalloutMock implementation to simulate HTTP responses in Apex unit tests, as real callouts are not allowed.
A managed package installed in a subscriber org throws an exception.
The ISV wants to log errors without exposing internal logic.
Which feature supports this?