Salesforce Certified Advanced Administrator 1-10

This question requires both long-term (10-year) retention of audit data and access control at the same time.
Salesforce’s standard log features (login history and the setup audit trail) have short retention periods (roughly a few days to six months), so they cannot satisfy this requirement on their own.
Therefore, a mechanism to store audit information independently is required.
By using the account login access feature to let administrators review the actions of the audited users, and combining it with recording into the custom object “Audit”, both long-term retention and access control can be achieved.
For this requirement, a design that stores data in a custom object for long-term retention is important.
The other options are standard log-viewing features and cannot satisfy the retention period or flexible access-control requirements, so they are inappropriate.
Audit and Monitor Your Organization’s Security

This question requires both automating lead routing and ensuring the completeness of the entered data.
Assignment rules automatically assign leads to specific users or queues based on conditions (for example, the planet), which satisfies the automatic lead-routing requirement.
Validation rules, on the other hand, guarantee data quality by blocking a save when required fields or conditions are not met.
This prevents missing entries for the information each team needs, fulfilling the role of preventing incomplete input.
Matching rules are for duplicate detection, and workflow rules are primarily for automating notifications and updates, so neither is central to this requirement.
When Do Rules Run?

This question asks how to grant the operations team access to all records in a specific region (East) while the organization-wide sharing setting is Private.
Enterprise Territory Management is a feature that can control access to accounts and opportunities by region or market. It enables bulk access control on a regional basis, making it the best fit for this requirement.
By adding the operations team to the East territory, they can access all accounts and opportunities belonging to that territory, without depending on the record owner or the role hierarchy.
The key point is that sharing can be flexibly achieved even when the org-wide default is Private.
The other options rely on individual sharing or the role hierarchy, so they cannot satisfy the comprehensive regional access requirement.
Manage Users and Roles Within a Territory

This question asks how to control which fields are displayed based on users or conditions.
The Field component in the Lightning App Builder can control visibility (show/hide) based on specific conditions (such as field values or profiles).
Component visibility filters (the Dynamic Forms feature) enable flexible display control.
This allows only the necessary fields to be shown to specific users, optimizing the page and improving usability.
The key point is to leverage Lightning’s Dynamic Forms feature rather than the traditional page layout.
The other options are for simple display (Record Detail) or progress tracking (Path) and do not support conditional visibility.
Use Dynamic Forms on LWC-Enabled Standard Objects

This question asks how to properly display different Lightning record pages for each department.
Lightning record pages can be assigned at the app, profile, or record type level.
By switching record pages at the app level, the same user can be shown a screen suited to the work they are performing.
By creating an app for each department and activating the corresponding record page for each, users can use the optimal screen depending on the app they are working in.
For users whose assignments change, like the backup team, control by app switching is the most suitable.
The other options only manage access rights and are not directly related to switching screen display.
Activate Lightning Experience Record Pages

This question asks how to view and report on data from a legacy system within Salesforce.
External objects integrate with a data source outside Salesforce and let you treat it as if it were a standard object.
A major advantage is that the data can be referenced in real time without storing it in Salesforce.
This allows the legacy inventory data to be used as-is without migration, and always references the latest data for viewing and reporting. A design that uses Salesforce Connect (external objects) is the optimal solution.
The other options involve copying data or manual management and are inappropriate from the standpoint of real-time access and operational efficiency.
Define External Objects

Platform events run as the “Automated Process” user rather than as the actual user.
For this reason, even when you check a regular user’s debug logs, the details of the event processing are not recorded.
The key point is that platform event execution logs are recorded under the Automated Process user.
Therefore, to debug, you need to set up a debug log for the “Automated Process” entity.
This lets you review the details and error contents of event processing by flows or Apex.
Setting the correct logging target is the key to successful debugging.The other options are either non-existent features or not a fundamental solution.
Add a Trace Flag Entry for the Default Automated Process User

Code changes to Lightning web components (LWC) are recommended to be done in a local development environment.
Visual Studio Code is the development tool officially recommended by Salesforce, and it can create, edit, and deploy LWC in conjunction with the Salesforce CLI and extensions.
The key point is that it is the standard development environment where you can directly edit the HTML and JavaScript of an LWC.
To fix a spelling error, you need to edit the HTML file of the relevant component and reflect the change.
The correct procedure is to fix the code in a local IDE rather than a browser-based tool.
The other options are for debugging or org administration and are not suitable for editing LWC code.
Get Started with Lightning Web Components

This question asks which features enforce required input and improve data quality.
Validation rules check conditions on save and guarantee data quality by preventing invalid values or blank entries.
The key point is that they can enforce the validity of the entered content.
Page layouts, on the other hand, let you set fields as required, prompting users to enter them.
The point is that required input can be controlled at the UI level.
Dashboards are for visualization and workflow rules are for automated processing, so neither is directly involved in input control.
Validation Rules

The key to this question is identifying the reason the user cannot delete the record.
In Salesforce, whether a record can be deleted depends on object permissions, and you specifically need to check whether the Delete permission is granted.
The key point is that without delete permission, a record cannot be deleted.
Therefore, the appropriate first step is to check the delete permission for the Opportunity object in the user’s profile or permission set.
To identify the cause, checking the permission settings is the top priority.
The other options do not resolve the root cause; they amount to workarounds or granting excessive permissions, so they are inappropriate.
Profiles