Encryption of Sensitive Data at Rest
5 minutes
5 Questions
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.
Encryption of Sensitive Data at Rest – Salesforce Advanced Administrator Exam Guide (Auditing and Monitoring)
1. Why Encryption of Sensitive Data at Rest Matters
Organizations store enormous volumes of personally identifiable information (PII), payment data, health records, and confidential business data inside Salesforce. Regulations such as GDPR, HIPAA, PCI DSS, CCPA, and industry frameworks frequently require that sensitive data be protected not only while it moves across networks but also while it sits in the database, in files, in search indexes, and in backups. This is the concept of data at rest.
Field-Level Security, sharing rules, and profiles control who can see data through the application. They do nothing to protect the raw bytes stored on disk if a storage layer, backup, or infrastructure component were compromised. Encryption at rest adds a second, independent layer of defense: even if someone obtains the stored data outside the normal Salesforce application path, it is unreadable without the encryption keys.
For the Advanced Administrator exam, this topic sits inside the Auditing and Monitoring domain because encryption is part of an org’s overall compliance posture, and administrators are expected to know which tool to recommend, what it can and cannot do, how keys are managed, and how it interacts with other platform features.
2. Key Vocabulary You Must Know
Data at rest – data persisted in storage (database records, files, attachments, search index). This is what Classic Encryption and Shield Platform Encryption protect.
Data in transit – data moving between the user’s browser (or an integration) and Salesforce servers. This is protected by TLS/HTTPS, not by field encryption.
Data in use – data displayed on screen or processed in memory. Encryption at rest does not hide data from authorized users; FLS and masking do.
Tenant secret – an org-specific secret generated in Salesforce (or supplied via Bring Your Own Key) that is combined with a Salesforce master secret to derive the actual data encryption key.
Key rotation – generating a new tenant secret so that newly written data uses a new key while historical data remains decryptable with archived keys.
Probabilistic encryption – the same plaintext produces different ciphertext each time it is encrypted; most secure but prevents filtering and matching.
Deterministic encryption – the same plaintext always produces the same ciphertext, allowing exact-match filtering (case-sensitive or case-insensitive schemes).
Masking – replacing displayed characters with symbols (for example showing only the last four digits). Masking is a display feature of Classic Encryption, not an encryption method.
3. What It Is: The Two Salesforce Encryption Options
3a. Classic Encryption (Encrypted Custom Fields)
Classic Encryption is included with Salesforce at no extra cost. You create a custom field of type Text (Encrypted).
Key characteristics:
• Available only as a custom field; standard fields cannot be encrypted with Classic Encryption.
• Maximum length of 175 characters.
• Uses 128-bit AES encryption with Salesforce-managed keys; the admin does not manage keys.
• Supports masking options such as Mask All Characters, Last Four Characters Clear, Credit Card Number, National Insurance Number, Social Security Number, Social Insurance Number.
• Users need the View Encrypted Data permission (on profile or permission set) to see the actual value; everyone else sees the masked value even if they have FLS read access.
• Encrypted fields cannot be used in report filters, list view filters, formula fields, as unique or external ID fields, in Salesforce Classic email templates, or in search.
• Encrypted fields can be referenced in validation rules and Apex.
• Values are editable only by users with View Encrypted Data unless the field is being set for the first time (and editing a masked field requires entering the full new value).
Classic Encryption is ideal for a small number of custom fields (like a national ID or an internal verification code) where masking on screen is the main requirement and no premium license exists.
3b. Shield Platform Encryption
Shield Platform Encryption is part of the paid Salesforce Shield add-on (alongside Event Monitoring and Field Audit Trail). It encrypts data at rest across the platform while preserving far more functionality than Classic Encryption.
Key characteristics:
• Uses 256-bit AES encryption.
• Encrypts standard fields (for example Account Name, Contact Email, Phone, Mailing Address components, Opportunity Description, Case Subject and Description, Lead fields, and many more depending on release) and custom fields of types Text, Text Area, Long Text Area, Rich Text Area, Email, Phone, URL, Date, and Date/Time.
• Encrypts Files and Attachments, Chatter feed content, the Search Index, Field History and Feed Tracking values, Change Data Capture events, Einstein Analytics datasets, and more.
• The administrator (with the Manage Encryption Keys permission) generates, rotates, exports, destroys, and manages tenant secrets from Setup under Platform Encryption / Key Management.
• Supports Bring Your Own Key (BYOK), where the customer supplies its own key material, and Cache-Only Key Service, where keys are fetched from an external key store and never persisted by Salesforce.
• Supports both probabilistic (default) and deterministic encryption schemes.
• There is no masking: a user with FLS read access sees the plaintext value. Shield encrypts the data on disk, not on the screen. Access control remains the job of FLS, sharing, and permissions.
• Shield Platform Encryption is not a replacement for Classic Encryption masking and not a replacement for FLS.
4. How Shield Platform Encryption Works
Step 1 – Enable and assign permissions. Shield Platform Encryption is provisioned on the org. The admin grants Manage Encryption Keys to users who will handle tenant secrets and Customize Application to users who will select which fields to encrypt. Salesforce recommends separating these duties for security.
Step 2 – Generate a tenant secret. From Setup, Key Management, the admin generates a tenant secret. Salesforce combines this tenant secret with a per-release master secret inside a Hardware Security Module (HSM) to derive the data encryption key. The derived key is cached in memory for performance and never written to persistent storage in plaintext.
Step 3 – Define the encryption policy. Under Setup, Encryption Policy, the admin chooses:
• Encrypt Fields – pick standard and custom fields and, for each, probabilistic or deterministic (case-sensitive or case-insensitive).
• Encrypt Files and Attachments.
• Encrypt Chatter.
• Encrypt Search Index.
• Other options such as Change Data Capture, Field History and Feed Tracking.
Step 4 – Data is encrypted on write. When a record is saved, the application layer encrypts the field value before it reaches the database. Existing data is not automatically encrypted when you enable a field; it is encrypted when the record is next saved, or you can contact Salesforce Support to run a bulk encryption / synchronization job. The Encryption Statistics page (Setup) shows what percentage of data is encrypted and with the current key.
Step 5 – Data is decrypted on read. When an authorized user views the record, the application decrypts the value transparently. Because decryption happens in the application layer, FLS and sharing still govern visibility. Users who lack FLS see nothing; users who have FLS see plaintext.
Step 6 – Key rotation and lifecycle. Tenant secrets can be rotated (for example annually or per policy; Salesforce allows a new tenant secret roughly every 24 hours for data in Salesforce). After rotation, new writes use the new key; older data remains readable because archived tenant secrets are retained. Admins should export tenant secrets and store them securely. Destroying a tenant secret makes any data still encrypted with it permanently unreadable, so it must be done with extreme care, and Salesforce strongly recommends synchronizing all data to the current key before destroying old ones.
5. Functional Impacts and Limitations of Shield Platform Encryption
Encryption changes how the platform can work with data. For the exam you must recognize these trade-offs:
• Probabilistic encrypted fields cannot be used in filters (report filters, list view filters, SOQL WHERE), cannot be sorted, cannot be grouped, and cannot be used as unique or external ID fields.
• Deterministic encryption restores exact-match filtering (equals / not equals) in reports, list views, SOQL, and lookups; it still does not support partial matching, sorting, or operators like starts with or contains.
• Encrypted fields are generally not supported in formula fields, roll-up summaries, or as criteria in workflow rules and process builder filters (limited support exists in some cases, but exam questions usually expect you to say encryption restricts these).
• Encrypted fields cannot be used in lead conversion mappings in some configurations, in duplicate rules matching (except with deterministic encryption), or in Skinny Tables.
• Search works because the search index itself is encrypted; standard global search on encrypted fields still returns results.
• Custom field types like Picklist, Checkbox, Number, Currency, Percent, Formula, Auto Number, and Lookup cannot be encrypted.
• Enabling encryption on a field can affect page layouts, integrations, and AppExchange packages, so Salesforce recommends testing in a sandbox first and reviewing the Encryption Policy warnings.
• Encryption does not protect against users who legitimately have access; it protects the stored data from exposure outside the application layer.
6. Classic vs. Shield at a Glance
Cost: Classic – included; Shield – paid add-on license.
Field scope: Classic – custom Text (Encrypted) only, 175 chars; Shield – many standard and custom field types, files, attachments, search index, Chatter, history.
Encryption strength: Classic – 128-bit AES; Shield – 256-bit AES.
Key management: Classic – Salesforce managed, no admin control; Shield – admin-generated tenant secrets, rotation, BYOK, Cache-Only Keys.
Masking on screen: Classic – yes, with View Encrypted Data permission controlling visibility; Shield – no masking, FLS controls visibility.
Filtering/search: Classic – no filtering, no search; Shield – search supported, exact-match filtering with deterministic scheme.
Typical use case: Classic – hide a few sensitive custom values from most users; Shield – meet regulatory encryption-at-rest requirements across the org.
7. Relationship to Other Auditing and Monitoring Tools
Encryption is one layer of a defense-in-depth strategy. On the exam it often appears alongside:
• Field Audit Trail (retain field history up to 10 years) – Shield can also encrypt the tracked values.
• Event Monitoring – logs who viewed or exported data; complements encryption by providing visibility.
• Setup Audit Trail – records changes to encryption policy and key management actions, which auditors may request.
• Field-Level Security and Sharing – govern access; encryption governs storage protection.
• Data Classification fields (Data Sensitivity Level, Compliance Categorization) – help admins identify which fields warrant encryption.
• Security Health Check – measures security settings but does not itself encrypt data.
8. Exam Tips: Answering Questions on Encryption of Sensitive Data at Rest
Tip 1 – Identify the real requirement first. Read whether the scenario asks to protect stored data for compliance (encryption at rest), hide values from certain users (FLS, or Classic masking), or secure data over the network (TLS/HTTPS, My Domain, trusted IP ranges). Only the first is an encryption-at-rest problem.
Tip 2 – Standard field means Shield. If the question mentions encrypting a standard field such as Account Name, Contact Email, Phone, Social Security number stored in a standard field, or files and attachments, the answer is Shield Platform Encryption. Classic Encryption cannot touch standard fields or files.
Tip 3 – Masking means Classic. If the requirement is to show only the last four digits or to display a value as asterisks for most users while a few see it in full, think Text (Encrypted) custom field plus the View Encrypted Data permission. Shield does not mask.
Tip 4 – Encryption is not access control. A frequent trick answer suggests enabling Shield Platform Encryption to stop a profile from seeing a field. That is wrong: users with FLS still see plaintext. Use FLS, permission sets, or Classic masking for visibility problems.
Tip 5 – Filtering requirements point to deterministic encryption. If a question says a field must be encrypted and used in report or list view filters or exact-match lookups, choose deterministic encryption. If the scenario stresses maximum security with no filtering need, probabilistic is correct. If a question asks for contains or starts with filtering on an encrypted field, recognize that no encryption scheme supports it.
Tip 6 – Know the key-management permission and best practices. The permission is Manage Encryption Keys. Best practices include separating key management from field configuration duties, exporting and securely storing tenant secrets, rotating keys per policy, and never destroying a tenant secret before synchronizing data to the current key.
Tip 7 – Remember what breaks. Expect questions where an admin enabled encryption and a formula field, roll-up summary, workflow filter, unique field, external ID, or report sort stopped working. The correct explanation is that the field was encrypted (usually probabilistically). Recommended remediation options include deterministic encryption for exact-match filters, removing encryption from that field, or redesigning the automation.
Tip 8 – Existing data is not instantly encrypted. If a question asks why Encryption Statistics show less than 100 percent after enabling a field, the answer is that existing records are encrypted only when saved or when Salesforce Support runs a bulk encryption job. Updating records via Data Loader is a common admin workaround.
Tip 9 – Watch for cost and license clues. Phrases like no additional budget, without purchasing add-ons, or out of the box steer you toward Classic Encryption; phrases like regulatory mandate for encryption at rest across the org, customer-controlled keys, or encrypt files steer you toward Shield.
Tip 10 – Test in a sandbox and review warnings. If asked about the recommended approach before encrypting fields in production, the best answer involves validating in a sandbox, reviewing which features and packages are affected, and checking Encryption Policy warnings. Avoid answers that suggest enabling encryption directly in production without impact analysis.
Tip 11 – Eliminate distractors. Options mentioning Security Health Check, login IP ranges, two-factor authentication, session settings, or Data Loader exports are about other security controls, not encryption at rest. Options mentioning TLS or HTTPS relate to data in transit.
9. Quick Recap
• Encryption at rest protects stored data, not who can see it in the UI.
• Classic Encryption: free, custom Text (Encrypted) field, 175 characters, 128-bit, masking, View Encrypted Data permission, no filtering or search.
• Shield Platform Encryption: paid, 256-bit, standard and custom fields, files, attachments, search index, Chatter, field history, admin-managed tenant secrets, BYOK, probabilistic vs deterministic, no masking.
• Manage Encryption Keys is the permission for tenant secret operations.
• Deterministic encryption enables exact-match filtering; probabilistic does not.
• Existing data encrypts on save or via a Salesforce Support bulk job; monitor with Encryption Statistics.
• Always pair encryption with FLS, sharing, auditing (Field Audit Trail, Event Monitoring, Setup Audit Trail) for a complete compliance story.
Master these distinctions and you will be able to confidently answer any Advanced Administrator question on encrypting sensitive data at rest.
Organizations store enormous volumes of personally identifiable information (PII), payment data, health records, and confidential business data inside Salesforce. Regulations such as GDPR, HIPAA, PCI DSS, CCPA, and industry frameworks frequently require that sensitive data be protected not only while it moves across networks but also while it sits in the database, in files, in search indexes, and in backups. This is the concept of data at rest.
Field-Level Security, sharing rules, and profiles control who can see data through the application. They do nothing to protect the raw bytes stored on disk if a storage layer, backup, or infrastructure component were compromised. Encryption at rest adds a second, independent layer of defense: even if someone obtains the stored data outside the normal Salesforce application path, it is unreadable without the encryption keys.
For the Advanced Administrator exam, this topic sits inside the Auditing and Monitoring domain because encryption is part of an org’s overall compliance posture, and administrators are expected to know which tool to recommend, what it can and cannot do, how keys are managed, and how it interacts with other platform features.
2. Key Vocabulary You Must Know
Data at rest – data persisted in storage (database records, files, attachments, search index). This is what Classic Encryption and Shield Platform Encryption protect.
Data in transit – data moving between the user’s browser (or an integration) and Salesforce servers. This is protected by TLS/HTTPS, not by field encryption.
Data in use – data displayed on screen or processed in memory. Encryption at rest does not hide data from authorized users; FLS and masking do.
Tenant secret – an org-specific secret generated in Salesforce (or supplied via Bring Your Own Key) that is combined with a Salesforce master secret to derive the actual data encryption key.
Key rotation – generating a new tenant secret so that newly written data uses a new key while historical data remains decryptable with archived keys.
Probabilistic encryption – the same plaintext produces different ciphertext each time it is encrypted; most secure but prevents filtering and matching.
Deterministic encryption – the same plaintext always produces the same ciphertext, allowing exact-match filtering (case-sensitive or case-insensitive schemes).
Masking – replacing displayed characters with symbols (for example showing only the last four digits). Masking is a display feature of Classic Encryption, not an encryption method.
3. What It Is: The Two Salesforce Encryption Options
3a. Classic Encryption (Encrypted Custom Fields)
Classic Encryption is included with Salesforce at no extra cost. You create a custom field of type Text (Encrypted).
Key characteristics:
• Available only as a custom field; standard fields cannot be encrypted with Classic Encryption.
• Maximum length of 175 characters.
• Uses 128-bit AES encryption with Salesforce-managed keys; the admin does not manage keys.
• Supports masking options such as Mask All Characters, Last Four Characters Clear, Credit Card Number, National Insurance Number, Social Security Number, Social Insurance Number.
• Users need the View Encrypted Data permission (on profile or permission set) to see the actual value; everyone else sees the masked value even if they have FLS read access.
• Encrypted fields cannot be used in report filters, list view filters, formula fields, as unique or external ID fields, in Salesforce Classic email templates, or in search.
• Encrypted fields can be referenced in validation rules and Apex.
• Values are editable only by users with View Encrypted Data unless the field is being set for the first time (and editing a masked field requires entering the full new value).
Classic Encryption is ideal for a small number of custom fields (like a national ID or an internal verification code) where masking on screen is the main requirement and no premium license exists.
3b. Shield Platform Encryption
Shield Platform Encryption is part of the paid Salesforce Shield add-on (alongside Event Monitoring and Field Audit Trail). It encrypts data at rest across the platform while preserving far more functionality than Classic Encryption.
Key characteristics:
• Uses 256-bit AES encryption.
• Encrypts standard fields (for example Account Name, Contact Email, Phone, Mailing Address components, Opportunity Description, Case Subject and Description, Lead fields, and many more depending on release) and custom fields of types Text, Text Area, Long Text Area, Rich Text Area, Email, Phone, URL, Date, and Date/Time.
• Encrypts Files and Attachments, Chatter feed content, the Search Index, Field History and Feed Tracking values, Change Data Capture events, Einstein Analytics datasets, and more.
• The administrator (with the Manage Encryption Keys permission) generates, rotates, exports, destroys, and manages tenant secrets from Setup under Platform Encryption / Key Management.
• Supports Bring Your Own Key (BYOK), where the customer supplies its own key material, and Cache-Only Key Service, where keys are fetched from an external key store and never persisted by Salesforce.
• Supports both probabilistic (default) and deterministic encryption schemes.
• There is no masking: a user with FLS read access sees the plaintext value. Shield encrypts the data on disk, not on the screen. Access control remains the job of FLS, sharing, and permissions.
• Shield Platform Encryption is not a replacement for Classic Encryption masking and not a replacement for FLS.
4. How Shield Platform Encryption Works
Step 1 – Enable and assign permissions. Shield Platform Encryption is provisioned on the org. The admin grants Manage Encryption Keys to users who will handle tenant secrets and Customize Application to users who will select which fields to encrypt. Salesforce recommends separating these duties for security.
Step 2 – Generate a tenant secret. From Setup, Key Management, the admin generates a tenant secret. Salesforce combines this tenant secret with a per-release master secret inside a Hardware Security Module (HSM) to derive the data encryption key. The derived key is cached in memory for performance and never written to persistent storage in plaintext.
Step 3 – Define the encryption policy. Under Setup, Encryption Policy, the admin chooses:
• Encrypt Fields – pick standard and custom fields and, for each, probabilistic or deterministic (case-sensitive or case-insensitive).
• Encrypt Files and Attachments.
• Encrypt Chatter.
• Encrypt Search Index.
• Other options such as Change Data Capture, Field History and Feed Tracking.
Step 4 – Data is encrypted on write. When a record is saved, the application layer encrypts the field value before it reaches the database. Existing data is not automatically encrypted when you enable a field; it is encrypted when the record is next saved, or you can contact Salesforce Support to run a bulk encryption / synchronization job. The Encryption Statistics page (Setup) shows what percentage of data is encrypted and with the current key.
Step 5 – Data is decrypted on read. When an authorized user views the record, the application decrypts the value transparently. Because decryption happens in the application layer, FLS and sharing still govern visibility. Users who lack FLS see nothing; users who have FLS see plaintext.
Step 6 – Key rotation and lifecycle. Tenant secrets can be rotated (for example annually or per policy; Salesforce allows a new tenant secret roughly every 24 hours for data in Salesforce). After rotation, new writes use the new key; older data remains readable because archived tenant secrets are retained. Admins should export tenant secrets and store them securely. Destroying a tenant secret makes any data still encrypted with it permanently unreadable, so it must be done with extreme care, and Salesforce strongly recommends synchronizing all data to the current key before destroying old ones.
5. Functional Impacts and Limitations of Shield Platform Encryption
Encryption changes how the platform can work with data. For the exam you must recognize these trade-offs:
• Probabilistic encrypted fields cannot be used in filters (report filters, list view filters, SOQL WHERE), cannot be sorted, cannot be grouped, and cannot be used as unique or external ID fields.
• Deterministic encryption restores exact-match filtering (equals / not equals) in reports, list views, SOQL, and lookups; it still does not support partial matching, sorting, or operators like starts with or contains.
• Encrypted fields are generally not supported in formula fields, roll-up summaries, or as criteria in workflow rules and process builder filters (limited support exists in some cases, but exam questions usually expect you to say encryption restricts these).
• Encrypted fields cannot be used in lead conversion mappings in some configurations, in duplicate rules matching (except with deterministic encryption), or in Skinny Tables.
• Search works because the search index itself is encrypted; standard global search on encrypted fields still returns results.
• Custom field types like Picklist, Checkbox, Number, Currency, Percent, Formula, Auto Number, and Lookup cannot be encrypted.
• Enabling encryption on a field can affect page layouts, integrations, and AppExchange packages, so Salesforce recommends testing in a sandbox first and reviewing the Encryption Policy warnings.
• Encryption does not protect against users who legitimately have access; it protects the stored data from exposure outside the application layer.
6. Classic vs. Shield at a Glance
Cost: Classic – included; Shield – paid add-on license.
Field scope: Classic – custom Text (Encrypted) only, 175 chars; Shield – many standard and custom field types, files, attachments, search index, Chatter, history.
Encryption strength: Classic – 128-bit AES; Shield – 256-bit AES.
Key management: Classic – Salesforce managed, no admin control; Shield – admin-generated tenant secrets, rotation, BYOK, Cache-Only Keys.
Masking on screen: Classic – yes, with View Encrypted Data permission controlling visibility; Shield – no masking, FLS controls visibility.
Filtering/search: Classic – no filtering, no search; Shield – search supported, exact-match filtering with deterministic scheme.
Typical use case: Classic – hide a few sensitive custom values from most users; Shield – meet regulatory encryption-at-rest requirements across the org.
7. Relationship to Other Auditing and Monitoring Tools
Encryption is one layer of a defense-in-depth strategy. On the exam it often appears alongside:
• Field Audit Trail (retain field history up to 10 years) – Shield can also encrypt the tracked values.
• Event Monitoring – logs who viewed or exported data; complements encryption by providing visibility.
• Setup Audit Trail – records changes to encryption policy and key management actions, which auditors may request.
• Field-Level Security and Sharing – govern access; encryption governs storage protection.
• Data Classification fields (Data Sensitivity Level, Compliance Categorization) – help admins identify which fields warrant encryption.
• Security Health Check – measures security settings but does not itself encrypt data.
8. Exam Tips: Answering Questions on Encryption of Sensitive Data at Rest
Tip 1 – Identify the real requirement first. Read whether the scenario asks to protect stored data for compliance (encryption at rest), hide values from certain users (FLS, or Classic masking), or secure data over the network (TLS/HTTPS, My Domain, trusted IP ranges). Only the first is an encryption-at-rest problem.
Tip 2 – Standard field means Shield. If the question mentions encrypting a standard field such as Account Name, Contact Email, Phone, Social Security number stored in a standard field, or files and attachments, the answer is Shield Platform Encryption. Classic Encryption cannot touch standard fields or files.
Tip 3 – Masking means Classic. If the requirement is to show only the last four digits or to display a value as asterisks for most users while a few see it in full, think Text (Encrypted) custom field plus the View Encrypted Data permission. Shield does not mask.
Tip 4 – Encryption is not access control. A frequent trick answer suggests enabling Shield Platform Encryption to stop a profile from seeing a field. That is wrong: users with FLS still see plaintext. Use FLS, permission sets, or Classic masking for visibility problems.
Tip 5 – Filtering requirements point to deterministic encryption. If a question says a field must be encrypted and used in report or list view filters or exact-match lookups, choose deterministic encryption. If the scenario stresses maximum security with no filtering need, probabilistic is correct. If a question asks for contains or starts with filtering on an encrypted field, recognize that no encryption scheme supports it.
Tip 6 – Know the key-management permission and best practices. The permission is Manage Encryption Keys. Best practices include separating key management from field configuration duties, exporting and securely storing tenant secrets, rotating keys per policy, and never destroying a tenant secret before synchronizing data to the current key.
Tip 7 – Remember what breaks. Expect questions where an admin enabled encryption and a formula field, roll-up summary, workflow filter, unique field, external ID, or report sort stopped working. The correct explanation is that the field was encrypted (usually probabilistically). Recommended remediation options include deterministic encryption for exact-match filters, removing encryption from that field, or redesigning the automation.
Tip 8 – Existing data is not instantly encrypted. If a question asks why Encryption Statistics show less than 100 percent after enabling a field, the answer is that existing records are encrypted only when saved or when Salesforce Support runs a bulk encryption job. Updating records via Data Loader is a common admin workaround.
Tip 9 – Watch for cost and license clues. Phrases like no additional budget, without purchasing add-ons, or out of the box steer you toward Classic Encryption; phrases like regulatory mandate for encryption at rest across the org, customer-controlled keys, or encrypt files steer you toward Shield.
Tip 10 – Test in a sandbox and review warnings. If asked about the recommended approach before encrypting fields in production, the best answer involves validating in a sandbox, reviewing which features and packages are affected, and checking Encryption Policy warnings. Avoid answers that suggest enabling encryption directly in production without impact analysis.
Tip 11 – Eliminate distractors. Options mentioning Security Health Check, login IP ranges, two-factor authentication, session settings, or Data Loader exports are about other security controls, not encryption at rest. Options mentioning TLS or HTTPS relate to data in transit.
9. Quick Recap
• Encryption at rest protects stored data, not who can see it in the UI.
• Classic Encryption: free, custom Text (Encrypted) field, 175 characters, 128-bit, masking, View Encrypted Data permission, no filtering or search.
• Shield Platform Encryption: paid, 256-bit, standard and custom fields, files, attachments, search index, Chatter, field history, admin-managed tenant secrets, BYOK, probabilistic vs deterministic, no masking.
• Manage Encryption Keys is the permission for tenant secret operations.
• Deterministic encryption enables exact-match filtering; probabilistic does not.
• Existing data encrypts on save or via a Salesforce Support bulk job; monitor with Encryption Statistics.
• Always pair encryption with FLS, sharing, auditing (Field Audit Trail, Event Monitoring, Setup Audit Trail) for a complete compliance story.
Master these distinctions and you will be able to confidently answer any Advanced Administrator question on encrypting sensitive data at rest.
Test mode:
Admin II - Encryption of Sensitive Data at Rest Example Questions
Test your knowledge of Encryption of Sensitive Data at Rest
Question 1
Universal Containers uses Shield Platform Encryption on a custom National ID field on Contact, with the default probabilistic scheme. Service agents now report that list view filters on National ID return no matches when they enter an exact value. Compliance requires the field to stay encrypted at rest. After testing in a full sandbox, what should the administrator do in production?
Question 2
Northern Trail Outfitters encrypts a custom Tax ID field with Shield Platform Encryption in production. After a full sandbox refresh, contract testers who have read access to that field see complete Tax ID values on records in the sandbox. The compliance team expected the values to appear masked. What explains this behaviour?
Question 3
Which statement best describes how Shield Platform Encryption differs from Classic Encryption in the protection of data at rest?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Encryption of Sensitive Data at Rest questions
30 questions (total)