Debug Logs and Trace Flags are essential auditing and monitoring tools in Salesforce that help administrators troubleshoot automation, code, and user activity. A debug log records database operations, system processes, and errors that occur when a user executes a transaction or when a unit test runs. It captures details such as Apex execution, workflow rules, validation rules, Process Builder and Flow actions, callouts, and SOQL/SOSL queries, along with timing information and governor limit consumption.

To generate debug logs, an administrator must create a Trace Flag. A trace flag specifies who or what is being monitored (a specific user, an Apex class, an Apex trigger, or an Automated Process entity), the time window during which logging is active (start and expiration dates), and the Debug Level to apply. Trace flags for users expire after a maximum of 24 hours, which prevents unnecessary log accumulation and protects storage limits.

Debug Levels define the granularity of information captured for each log category, such as Apex Code, Database, Workflow, Validation, Callouts, System, and Visualforce. Each category can be set to levels like NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, or FINEST. Higher levels produce more detail but larger logs. Each debug log is limited to 20 MB, and an organization can retain up to 1,000 MB of logs; older logs are deleted when the limit is reached.

Administrators access these tools through Setup under Environments > Logs > Debug Logs, or via the Developer Console, which offers log filtering and inspection. Logs are retained for 24 hours in Setup and 7 days in the Developer Console. For the Platform Administrator II exam, remember that debug logs are not a substitute for Setup Audit Trail, Field History Tracking, or Event Monitoring; rather, they are a diagnostic tool for understanding why automation behaves unexpectedly, identifying performance bottlenecks, and verifying that processes execute in the intended order.

The Setup Audit Trail is a Salesforce auditing feature that tracks configuration and administrative changes made within the Setup menu of an org. For a Platform Administrator II candidate, it is a key tool for monitoring who changed what, when, and from where, supporting governance, compliance, and troubleshooting.

What it tracks: Setup Audit Trail logs changes to metadata and administrative settings, such as modifications to users (creation, deactivation, role or profile changes), permission sets, profiles, sharing rules, organization-wide defaults, custom objects and fields, page layouts, validation rules, workflow rules, flows, Apex classes, triggers, Visualforce pages, email templates, login hours and IP ranges, password policies, company information, and many other Setup configurations. It also records when an administrator logs in as another user, which is critical for accountability.

What it shows: Each entry includes the date and time of the change, the user who made it, the source (for example, the originating user when using Log In As, or the delegated admin), the section of Setup affected, and a description of the action. Note that the audit trail records that a change occurred and a brief description, but it does not store full before-and-after values for every setting.

Retention and access: Setup Audit Trail retains the last 180 days of changes. Administrators access it via Setup > Security > View Setup Audit Trail, where the most recent 20 entries display on screen. The complete 180-day history can be downloaded as a CSV file, which is a best practice for long-term retention since older records are purged automatically.

Exam-relevant distinctions: Unlike Field History Tracking (which tracks record data changes) or Login History (which tracks authentication events), Setup Audit Trail focuses solely on configuration changes. It requires the View Setup and Configuration permission to access. Administrators should periodically export it to meet audit and compliance requirements, as Salesforce does not provide a native way to extend the retention period.

Field History Tracking and Field Audit Trail are two related Salesforce features that let administrators monitor changes to record data over time, a core topic in the Platform Administrator II exam under Auditing and Monitoring.

Field History Tracking is available in all editions with the standard functionality. For standard objects such as Account, Contact, Lead, Opportunity, and Case, as well as custom objects, you can select up to 20 fields per object to track. When a tracked field changes, Salesforce records the old value, new value, user who made the change, and the date/time in a related list called 'Object History' (for example, Account History). This data is stored in history objects such as AccountHistory or CustomObject__History and is retained for 18 months through the user interface and up to 24 months via the API. Certain field types, like formula fields, roll-up summaries, auto-number fields, and long text areas (which only show that a change occurred, not the values), have limitations.

Field Audit Trail is a paid add-on (part of Salesforce Shield) that extends Field History Tracking. It allows you to define a retention policy using the HistoryRetentionPolicy metadata through the Metadata API, specifying how long archived data is kept, up to 10 years. It also raises the tracked field limit from 20 to 60 fields per object. Archived data is stored in the FieldHistoryArchive big object and can be queried using SOQL or Async SOQL, making it suitable for compliance requirements such as HIPAA, SOX, or GDPR.

For the exam, remember the key distinctions: Field History Tracking is free, limited to 20 fields, and retains data for 18 months; Field Audit Trail is a Shield add-on, supports 60 fields, retains data for up to 10 years, and requires defining retention policies via the Metadata API. Neither feature is a replacement for Setup Audit Trail, which tracks configuration changes rather than record data changes.

In Salesforce, Login History and Identity Verification History are two key auditing tools that help administrators monitor user access and security events, which is essential knowledge for the Platform Administrator II exam.

Login History (Setup > Login History) records every login attempt to the org, both successful and failed, for the past six months. Each entry captures the username, login time, source IP address, login type (e.g., Application, Other Apex API, Remote Access), status (Success, Failed: Invalid Password, Failed: Login Lockout, etc.), browser, platform, application, client version, API type and version, login URL, and country/city derived from geolocation. Administrators can filter, sort, and download up to 20,000 records as CSV or GZIP for the last six months, or use Login Forensics and Event Monitoring for deeper analysis. Login History is invaluable for troubleshooting access issues, detecting suspicious activity such as repeated failed logins from unfamiliar IPs, verifying IP range restrictions, and demonstrating compliance. Note that login attempts blocked by network restrictions or outside login hours are also captured with corresponding status values.

Identity Verification History (Setup > Identity Verification History) tracks identity confirmation events over the past six months, typically triggered by multi-factor authentication (MFA), device activation when logging in from an unrecognized browser or IP, or step-up authentication for sensitive actions. Each record shows the user, verification time, method (Salesforce Authenticator, SMS, email, security key, built-in authenticator, or one-time password), status (Succeeded, Failed, or Pending), activity triggered (e.g., Login, Connected App access), source IP, and location. Admins can filter and download up to 20,000 records.

Together, these tools complement Setup Audit Trail and Field History Tracking, allowing administrators to audit who accessed the org, from where, how they authenticated, and whether security policies like MFA are functioning correctly.

Event Monitoring is a Salesforce feature, part of the Salesforce Shield suite (also available as an add-on), that gives administrators detailed visibility into how users interact with the org. For a Platform Administrator II candidate, it fits squarely within the Auditing and Monitoring domain alongside Setup Audit Trail, Field History Tracking, and Login History, but it goes much deeper than those native tools.

At its core, Event Monitoring captures granular activity data in the form of Event Log Files (ELFs). These files are generated daily (or hourly, depending on your license) and are exposed through the EventLogFile object, which can be queried via SOQL or the REST API. Each file corresponds to a specific event type, and there are dozens of them, including Login, Logout, API, Report Export, URI (page views), Visualforce, Apex Execution, Lightning Interaction, Dashboard, and Document Attachment Downloads. Each record contains fields such as user ID, timestamp, client IP, browser, and operation performed.

From an auditing perspective, this allows admins to answer questions like: Who exported a sensitive report? Which users are downloading large volumes of files? Are there logins from unusual locations? Which pages or Apex classes are performing poorly? This supports security investigations, compliance requirements (such as GDPR or SOX), user adoption analysis, and performance tuning.

In addition to log files, Event Monitoring includes Real-Time Event Monitoring, which streams certain events (like LoginEvent, ReportEvent, ApiEvent) via platform events, and Transaction Security Policies, which let you define rules that block, require MFA, or notify when specific risky behavior occurs, for example, blocking a report export exceeding a record threshold.

Analyzing the data typically involves exporting logs to tools such as the Event Monitoring Analytics App (CRM Analytics), Splunk, or a custom dashboard. Key exam points: ELFs are read-only, retained for 1 day on Developer edition or 30 days with the add-on, require the View Event Log Files and API Enabled permissions, and complement rather than replace Setup Audit Trail.

In Salesforce, Data Classification Settings let administrators document and govern how sensitive each field is, which supports the Auditing and Monitoring objective in the Platform Administrator II exam. Enabled via Setup > Data Classification Settings, this feature adds metadata attributes to every standard and custom field so you can describe what kind of data it holds and how carefully it must be handled.

There are four key attributes. Data Owner identifies the user or group accountable for the field. Field Usage indicates whether the field is Active, Deprecated, or Hidden, helping you track technical debt. Data Sensitivity Level describes how confidential the data is, using picklist values such as Public, Internal, Confidential, Restricted, and MissionCritical; admins can customize these values to match corporate policy. Compliance Categorization tags the field with regulations it falls under, such as PII, HIPAA, GDPR, PCI, COPPA, or CCPA, and custom categories can be added.

Admins set these values on each field's detail page or in bulk using Data Loader, the Metadata API, or the Tooling API, since the attributes are stored on the field metadata (for example, securityClassification and complianceGroup on FieldDefinition). Reports and list views on FieldDefinition let you find every field marked Restricted or tagged PII, which is useful for audits, privacy impact assessments, and deciding where to apply Shield Platform Encryption, Field Audit Trail, Event Monitoring, or stricter field-level security.

Importantly, classification is descriptive, not enforcement. It does not restrict access or encrypt data by itself; it documents intent so that security controls, sharing rules, and monitoring policies can be aligned with it. For the exam, remember that enabling the setting is org-wide, the sensitivity picklist is customizable, classifications can be queried via API, and the feature primarily supports governance, compliance reporting, and prioritizing other security and auditing tools.

Encryption of sensitive data at rest protects stored information so that even if the underlying database, backups, or files are accessed without authorization, the content remains unreadable. In Salesforce, administrators have two primary options: Classic Encryption and Shield Platform Encryption.

Classic Encryption uses a special 'Text (Encrypted)' custom field type. It applies 128-bit AES encryption, supports masking (e.g., showing only the last four characters), and relies on the 'View Encrypted Data' permission to reveal values. However, it cannot be used in formulas, filters, reports, or search, and only applies to custom text fields of limited length.

Shield Platform Encryption, a paid add-on, uses 256-bit AES encryption and applies to standard and custom fields, files, attachments, Chatter, search indexes, and more. Encryption is applied at the storage layer, so users with field-level access see data normally in the UI, while unauthorized infrastructure access reveals only ciphertext. Key management is central: Salesforce generates tenant secrets, or organizations can use Bring Your Own Key (BYOK) or Cache-Only Keys with an external key service. Admins can rotate tenant secrets, archive or destroy keys, and track key activity.

For auditing and monitoring, encryption works alongside Field Audit Trail, Setup Audit Trail, and Event Monitoring. Setup Audit Trail records who enabled encryption or rotated keys. Event Monitoring provides logs of logins, report exports, and API calls, helping detect misuse even when data is encrypted. Field History Tracking can capture changes to encrypted fields, and encrypted values in history are themselves encrypted.

Administrators should note limitations: encrypted fields have restrictions on sorting, SOQL WHERE clauses (with deterministic encryption allowing some filtering), roll-up summaries, and external IDs. Best practice is to encrypt only truly sensitive data (PII, financial, health), document key rotation schedules, assign the 'Manage Encryption Keys' permission sparingly, and combine encryption with strong sharing, profiles, permission sets, and regular monitoring to achieve compliance with regulations like GDPR, HIPAA, and PCI DSS.

In the Salesforce Certified Platform Administrator II exam, the Auditing and Monitoring domain covers how administrators protect data and maintain compliance across environments, including sandboxes. Masking sensitive data in sandboxes addresses a common risk: when you create a Full or Partial Copy sandbox, production data—such as customer names, emails, Social Security numbers, and financial details—is copied into an environment often accessed by developers, testers, consultants, and third parties who may not need or be authorized to see real personal information. This exposure can violate regulations like GDPR, CCPA, HIPAA, or PCI DSS.

Salesforce Data Mask is a managed package (an add-on license) that helps mitigate this. It runs inside the sandbox after a refresh and permanently transforms selected field data using configurable masking styles. The main options are: Replace with random characters (random letters, numbers, or alphanumerics of similar length), Replace with library values (realistic fake data such as names, addresses, cities, or emails drawn from Salesforce-provided libraries), Delete (clears the field value entirely), and Pattern-based masking (define a custom format, e.g., a phone number pattern). Admins configure masking per object and field, save the configuration, and run it on demand or schedule it, with run logs available to confirm completion. Because masking is irreversible in that sandbox, it should be applied only to non-production copies.

Beyond the tool itself, best practices include classifying fields using Data Classification metadata (compliance categorization and data sensitivity level) so you can systematically identify what needs masking, limiting sandbox access through profiles and permission sets, using Developer or Developer Pro sandboxes (which contain only metadata) when real data isn't required, and reviewing the sandbox templates used for Partial Copy sandboxes to exclude sensitive objects. Alternatively, admins can write post-copy Apex (SandboxPostCopy interface) to scramble data, though Data Mask is the declarative, supported approach. Masking supports least-privilege principles and reduces breach impact while preserving realistic data for testing.

Security Health Check is a built-in Salesforce tool (Setup > Security > Health Check) that lets administrators quickly evaluate how well their org's security settings align with Salesforce-recommended standards. It is a key topic in the Auditing and Monitoring domain of the Platform Administrator II exam because it provides a proactive way to identify and remediate security vulnerabilities before they become problems.

How it works: Health Check compares your org's current security configuration against a baseline. By default this is the Salesforce Baseline Standard, but you can import up to five custom baselines (as XML files) to reflect your company's or industry's requirements. Settings are evaluated across groups such as Password Policies, Session Settings, Login Access Policies, Certificate and Key Management, and other security-related settings.

The tool produces an overall Health Check Score (0–100%). Scores are categorized as Excellent (90%+), Very Good (80–89%), Good (70–79%), Poor (55–69%), or Very Poor (below 55%). Each individual setting is flagged as High-Risk, Medium-Risk, Low-Risk, or Compliant based on how far it deviates from the baseline. High-risk settings affect the score more heavily.

Remediation: For many settings, admins can click Fix Risks to apply recommended values directly from the Health Check page, or click Edit to adjust a setting manually. Changes should be tested since tightening security (for example, shortening session timeouts) can affect users.

Exam-relevant points: Health Check requires the View Setup and Configuration and Modify All Data permissions (or View Health Check). It is read-only in terms of monitoring and does not replace other auditing tools such as Setup Audit Trail, Login History, Field History Tracking, or Event Monitoring; rather, it complements them. Admins should review Health Check regularly, especially after releases or configuration changes, and document deviations that are intentionally accepted. It also supports exporting results for compliance reporting.

Release Updates are changes Salesforce introduces with each seasonal release (Spring, Summer, Winter) that modify platform behavior, security, or performance. In Salesforce Certified Platform Administrator II, particularly under Auditing and Monitoring, administrators must understand how to evaluate, test, and activate these updates—especially those that change system access, since they directly affect who can see or do what in the org.

Release Updates are managed in Setup under 'Release Updates'. Each update lists a description, the reason for the change, affected features, a recommended test plan, and a due date (enforcement date). Updates may be in states such as Available (optional), Due Soon, Overdue, or Enforced. Once enforced, Salesforce activates the update automatically whether or not you have prepared.

Updates that change system access are particularly sensitive. Examples include: requiring the 'View Setup and Configuration' permission to access certain Setup pages, restricting guest user record access and sharing, enforcing Multi-Factor Authentication (MFA), requiring permission to view record names in lookup fields, restricting access to @AuraEnabled Apex methods based on user profile, and changes to email deliverability or API-only user permissions. These updates can break integrations, Experience Cloud sites, automations, or user workflows if not addressed.

As an administrator, best practice is to: (1) review each update's impact assessment, (2) enable it first in a sandbox and run the provided test plan, (3) audit affected users, profiles, permission sets, and integrations, (4) communicate changes to stakeholders, and (5) activate in production before the enforcement date. Monitoring tools such as Setup Audit Trail, Login History, and Event Monitoring help verify that access behaves as expected after activation. Administrators can also use the 'Disable' option (when available) to temporarily revert an update while remediating issues before enforcement.

Proactively managing Release Updates ensures security compliance, prevents unexpected access disruptions, and maintains a well-governed org.