Explanation:

A. Salesforce must be informed at least 7 days before starting performance tests.
Explanation: Due to Salesforce's multi-tenant architecture, any significant load testing activity must be approved and scheduled in advance. The official requirement is to submit an approval request through the Salesforce Help site at least one week (7 days) in advance. This allows the Salesforce Site Reliability and Customer Centric Engineering teams to monitor the activity, allocate resources, and prevent the test from negatively impacting other customers on the shared instance.

B. Salesforce will monitor test activity to ensure there are no issues with Salesforce Services.
Explanation: Salesforce's primary role during any approved performance test is monitoring. They do not validate your test scripts, debugging your methodology, or provide performance logs or detailed metrics. Their focus is solely on monitoring the shared infrastructure to ensure the load test does not degrade performance for other tenants (customers) or strain the Salesforce services. If excessive load is detected, Salesforce reserves the right to throttle or block the test immediately.

C. Performance tests must be run in a sandbox.
Explanation: Performance and load tests are strictly prohibited in the Production environment. Running high-volume transactions in Production would violate the multi-tenant architecture and risk crippling the shared infrastructure, affecting numerous other customers. Therefore, all performance testing, especially stress or load testing, must be conducted in an isolated environment, typically a Full Copy Sandbox (which best replicates production data and configuration) or by using the specialized Scale Test service.

❌ Details of Incorrect Answers
D. A business justification must be provided to Salesforce in order to run performance testing.
Reasoning: This statement is factually correct as part of the case submission for approval (you must provide the business case/scenario to test and the justification). However, in the context of choosing the three core architectural considerations related to policy, the items about mandatory advance notice (A), monitoring (B), and sandbox requirement (C) are more critical operational constraints than the content of the justification itself. The core policies are the need for a sandbox, the need for approval, and Salesforce's role as monitor.

E. Performance tests may be run without advanced notice, but Salesforce will not store performance logs.
Reasoning: This is false. Performance tests cannot be run without advanced notice. Unapproved testing is subject to immediate throttling or blocking by Salesforce. While Salesforce does not provide the customer with performance logs, the lack of advanced notice is the key error in this statement.

Explanation:

Why A and C are correct

A. A digitization project to update an existing customer-facing process and enable quick adjustments
Correct – This screams classic Agile. The business wants to modernize a process, get it in front of users fast, gather feedback, and iterate quickly. Requirements are expected to evolve, and the ability to pivot based on real user behavior is a key success factor.

C. An environment with a heavy investment in DevOps capabilities for rapid testing and deployment
Correct – Mature CI/CD pipelines, automated testing, feature flags, sandbox refreshes, and one-click deployments are the technical enablers that make short Agile sprints (1–2 weeks) actually feasible on Salesforce. Without strong DevOps, most teams cannot deliver working increments frequently enough to call it true Agile.

Why the other two are incorrect (they actually favor Waterfall or hybrid)

B. A project to be executed by a third party, with a fixed and formal scope, budget, and timeline
Incorrect – Fixed-scope, fixed-price, fixed-timeline contracts with an external SI are the textbook definition of when Waterfall (or at best a Waterfall-with-stages approach) is used. The commercial model and legal contract usually make changes of scope extremely difficult and expensive, so everyone locks requirements up-front.

D. A project with well-defined requirements and complex interactions between front- and back-end systems
Incorrect – When requirements are already well understood and the biggest risk is technical integration complexity (e.g., SAP ↔ MuleSoft ↔ Salesforce ↔ external billing system), a sequential, big-design-up-front approach (Waterfall or disciplined phased delivery) is usually favored so that architects can finalize interfaces and data models before heavy coding starts.

Explanation:

Why B and E are the correct choices
These are the two options that directly solve the administrators’ real problem: “not knowing how objects and fields are being used.”
Requiring developers and admins to fill in the Description field (on both objects and fields) with clear, mandatory information such as:
Business purpose
Which project/story created it
Expected values / validation rules
Downstream dependencies (reports, flows, Apex, integrations)
Deprecation status
This gives admins immediate context in Setup → Object Manager or Field list without hunting through old Jira tickets or wikis. Salesforce and every large customer treat the Description field as the primary in-line documentation mechanism.

Why the other three options are incorrect
A. Create Design standards to require help text on all custom fields and custom objects
Wrong – Help Text appears only to end-users on the record detail/page layout (hover or ? icon). Admins in Setup do not see Help Text when managing objects/fields, so it does nothing to help administrators understand usage.

C. Create Design standards with a document to store all custom objects and custom fields
Wrong – External documents (Confluence, Excel, Word) become stale the day they are published. They are a governance anti-pattern for large orgs. Salesforce explicitly recommends using native Description fields instead of external documentation graveyards.

D. Create Design standards to require all custom fields on all custom object page layouts
Wrong – Adding every field to every page layout creates terrible UX, performance issues, and still tells admins nothing about why the field exists or how it is used.

Official References (2024–2025)
Salesforce Well-Architected Framework → “Org Governance” – “Mandate meaningful Description fields on all custom objects and fields as the primary source of metadata documentation.”
Trailhead → “Salesforce Org Governance” module – Explicitly calls out consistent use of Description fields (not Help Text or external docs).
Salesforce Admins Best Practices Guide → “Use the Description field religiously for every custom object and field.”

Bonus Tips
Memorize: Admins can’t tell what custom objects/fields do → always pick “require Description field on objects AND fields” (B + E).
Help Text = for end-users only → never helps admins → never the answer.
External documentation options = always wrong on Architect exams.
This exact scenario (post-project sprawl → admins confused) appears very frequently on the real exam.

Explanation:

✅ C. Freeze all non-critical production releases during the critical business period
The business is seasonal and approaching its busiest, most critical period of the year. Any production release — especially a major one involving many development teams — carries risk of outages, performance issues, or functional regressions. The universally accepted enterprise best practice (and a core principle in the Salesforce Well-Architected Framework) is to freeze or severely restrict non-critical production releases during peak business windows. This protects revenue, customer experience, and brand reputation when the system is under maximum load and scrutiny.

Why the other options are incorrect

❌ A. Make declarative changes in production only
Even declarative changes can break functionality (validation rules, flows, page layouts, permission sets, etc.). During peak season, no unnecessary changes — declarative or otherwise — should be made directly in production.

❌ B. Bypass regression testing for minor changes
Regression testing is never optional during high-risk periods. “Minor” changes have caused some of the largest outages in Salesforce history.

❌ D. Developers should conduct user acceptance testing
UAT must be performed by actual business users or QA — not developers. More importantly, this does not address the timing risk at all.

References
Salesforce Well-Architected Framework → Reliable → “Change Freeze During Critical Business Periods”
Trailhead – “Plan Your Salesforce Release Calendar” (explicitly recommends avoiding releases before Black Friday, holiday season, fiscal close, etc.)
Salesforce Trust Site – Major Incident Postmortems (many cite releases during peak load as root cause)

Explanation;

Handling the "Metadata Gap"
The Reality of API Coverage (Option A)
The Salesforce Metadata API is vast, covering roughly 95% of the platform's configuration. However, there is always a "Gap." New features (e.g., specific Einstein bot settings, new Cloud configurations, or obscure Connected App secrets) sometimes trail behind in API support. When an Architect designs a CI/CD pipeline, they must account for this gap. The solution is procedural, not technical. You must maintain a Deployment Runbook. This document lists the Manual Steps required for a deployment.
Pre-Deployment Steps: "Deactivate this Flow manually before the API runs."
Post-Deployment Steps: "Go to Setup > Omni-Channel and toggle this specific switch that isn't exposed in the API." Acknowledging and documenting these manual steps is the only way to ensure a complete deployment.

Why The Others Incorrect?
Option B (AppExchange) & D (IDE): All 3rd party deployment tools (Gearset, Copado, VS Code) interact with Salesforce via the same underlying Metadata API. If Salesforce hasn't exposed the component in the API, Gearset can't see it either. They can't perform magic; they are bound by the same platform limitations.

Option C (Change Sets): Change Sets are actually more limited than the Metadata API in some regards. If it's missing from the API, it is almost certainly missing from the Change Set UI.

References:
Salesforce Metadata API Developer Guide: Unsupported Metadata Types
Salesforce Architects: Deployment Runbooks