Salesforce DevOps Course Module 2: Environments & Sandboxes Complete Guide 2026

🚀 Free Salesforce DevOps Course 2026 Module 2 of 15

Salesforce Environments & Sandboxes
Complete Guide

Master all 4 sandbox types, refresh strategies, sandbox templates, seeding, email deliverability, and how to design a professional environment strategy for your team — with real XYZ Company examples throughout.

Sandbox Types

Beginner

Free

Forever

2026

Updated

← Module 1 All Topics →

📍 Course Progress — Module 2 of 15

M1 ✅
Intro

M2 👈
Sandboxes

M3
Change Sets

M4
Metadata API

M5
Git Basics

M6
SFDX & CLI

M7
Scratch Orgs

M8
Packages

M9
DevOps Center

M10
Deploy Strategy

M11
GitHub Actions

M12
Advanced CI/CD

M13
Unlocked Pkg

M14
Enterprise

M15
Capstone

✅ Completed: Module 1 — What is Salesforce DevOps? ← Review M1

📋 What You Will Learn in This Module

🌍 What are Salesforce Environments? 🏖️ The 4 Sandbox Types 🤔 Which Sandbox to Use When? 🔄 Sandbox Refresh — Everything 📋 Sandbox Templates 🌱 Sandbox Seeding 📧 Email Deliverability 🗺️ Environment Strategy 🔬 Sandbox vs Scratch Org 🏢 XYZ Company Setup ⚠️ Common Mistakes 📝 Module Quiz

📚 Full Course Navigation

✅ M1 — What is Salesforce DevOps? M2 — Environments & Sandboxes 👈 M3 — Change Sets Mastery M4 — Metadata API Basics M5 — Version Control with Git M6 — SFDX & SF CLI Setup M7 — Scratch Orgs M8 — Salesforce Packages M9 — DevOps Center M10 — Deployment Strategies M11 — GitHub Actions CI/CD M12 — Advanced CI/CD Patterns M13 — Unlocked Packages M14 — Enterprise DevOps M15 — Capstone Project

🌍 Section 1 — What are Salesforce Environments?

Understanding the different org types in your Salesforce ecosystem

📖 Definition

A Salesforce environment is any Salesforce org used in your development and release process. Most teams have multiple environments serving different purposes — from writing code to testing features to getting business approval to serving real customers.

Think of environments like the stages a new product goes through before it reaches customers: prototype lab → quality control → safety testing → store shelf. Each stage has a specific job.

✅ The Salesforce Environment Family

Environment	Type	Who Uses It	Purpose
Production	Live org	Real customers, end users	The live business system — never test here
Full Sandbox	Sandbox	Business users, QA leads	UAT — complete production clone
Partial Copy Sandbox	Sandbox	QA team	Integration and regression testing with sample data
Developer Pro Sandbox	Sandbox	Developers, admins	Development with larger datasets
Developer Sandbox	Sandbox	Individual developers	Daily development, no data needed
Scratch Org	Temporary org	Developers	Isolated feature development (covered in M7)

🎯 The Golden Rule of Environments

Never build, test, or experiment directly in production.

Production is where real customers do real business. A mistake there costs real money and damages real relationships. Everything happens in environments first — only proven, tested, approved changes reach production.

🔑 Key Points

Salesforce production and all its sandboxes are separate orgs — changes in one do not automatically appear in another
Sandboxes are always connected to their parent production org
Every Salesforce edition includes at least one Developer sandbox
Full and Partial Copy sandboxes require higher Salesforce editions (Enterprise+)

🏖️ Section 2 — The 4 Salesforce Sandbox Types

Deep dive into every sandbox type — storage, data, refresh, and use cases

📖 Overview

Salesforce provides 4 sandbox types — each designed for a different stage of development. Choosing the right sandbox for the right job is one of the most important decisions in your environment strategy.

🟢 1. Developer Sandbox

200MBData Storage

200MBFile Storage

No DataCopied from Prod

1 DayMin Refresh Interval

FreeIncluded with License

Best for: Individual developer's daily work — writing Apex classes, building LWC components, creating Flows, configuring objects. No production data needed because developers create their own test data.

How many: You can create multiple Developer sandboxes — one per developer is the best practice.

Limitation: Only 200MB — not suitable for testing with large data volumes or realistic data scenarios.

🔵 2. Developer Pro Sandbox

1GBData Storage

1GBFile Storage

No DataCopied from Prod

1 DayMin Refresh Interval

PaidAdditional License

Best for: Development tasks that need larger data volumes — performance testing with realistic record counts, building data-intensive reports, or testing batch Apex jobs that need 10,000+ records to behave realistically.

Difference from Developer: 5x more storage. Same behavior otherwise — no production data copied.

When to use: When a Developer sandbox is running out of storage or when testing requires more than a few hundred records.

🟡 3. Partial Copy Sandbox

5GBData Storage

5GBFile Storage

Sample DataVia Template

5 DaysMin Refresh Interval

PaidEnterprise+ Edition

Best for: QA and integration testing. The Partial Copy sandbox copies a sample of production data (defined by a Sandbox Template) — giving testers realistic data without copying the full production database.

Key feature: Sandbox Template controls WHICH records are copied. You define: "Give me 500 Accounts with their related Contacts, 1,000 Opportunities, and all Product records."

Limitation: 5-day refresh interval means you cannot refresh it daily. Max 10,000 records per object without a template.

🔴 4. Full Sandbox

Same as ProdData Storage

Same as ProdFile Storage

ALL DataComplete Clone

29 DaysMin Refresh Interval

Most ExpensiveEnterprise+ Edition

Best for: User Acceptance Testing (UAT), performance testing, training, and final pre-production validation. It is a complete, exact clone of production — same metadata, same data, same file attachments.

Critical difference: Emails are suppressed by default (so you don't accidentally email real customers). Login URL is test.salesforce.com. Usernames are suffixed with the sandbox name.

Limitation: 29-day refresh interval and most expensive. Takes hours to create (copying all production data). Most teams have only one Full sandbox.

📊 Side-by-Side Comparison

Feature	🟢 Developer	🔵 Dev Pro	🟡 Partial	🔴 Full
Data Storage	200MB	1GB	5GB	= Production
File Storage	200MB	1GB	5GB	= Production
Production Data?	❌ No	❌ No	✅ Sample	✅ All
Sandbox Template?	❌ No	❌ No	✅ Required	❌ Not needed
Refresh Interval	1 day	1 day	5 days	29 days
Creation Speed	Minutes	Minutes	Hours	Hours–Days
Cost	Included	Add-on	Add-on	Most expensive
Best For	Daily dev	Larger dev	QA testing	UAT/Training

🤔 Section 3 — Which Sandbox to Use When?

The decision guide every Salesforce professional needs

📖 Decision Framework

Choosing the wrong sandbox wastes time and creates problems. Use this framework to always pick the right environment for the task.

✅ Use Developer Sandbox When...

✅ Writing or modifying Apex classes, triggers, or test classes
✅ Building LWC components
✅ Creating or modifying Flows, Process Builder, validation rules
✅ Adding custom fields, objects, or page layouts
✅ Configuring approval processes or email templates
✅ You need a quick isolated environment to test something fast
✅ You are learning — every developer needs their own space to experiment

🟡 Use Partial Copy Sandbox When...

✅ The QA team is testing a feature and needs realistic data
✅ Testing reports, dashboards, or analytics with real-looking data
✅ Integration testing where data relationships matter (Account → Contact → Opportunity)
✅ Performance testing with a sample of real volume
✅ QA regression testing before production releases

🔴 Use Full Sandbox When...

✅ Business users are doing User Acceptance Testing (UAT) — they need real data
✅ Full performance testing with production-level data volumes
✅ Training new employees on real data without risking production
✅ Testing integrations with external systems using complete production datasets
✅ Final sign-off before a major release

🎯 Quick Decision Table

Task	Best Sandbox	Why
Write an Apex class	🟢 Developer	No data needed, fast refresh
Build a complex Flow	🟢 Developer	Declarative work, seed your own data
Test batch job on 50K records	🔵 Developer Pro	More storage for larger test data
QA test a new feature	🟡 Partial Copy	Realistic sample data for testing
Business UAT sign-off	🔴 Full	Real data, real environment for approval
Train new sales reps	🔴 Full	Real data without affecting production
Isolated feature dev (SFDX)	🔬 Scratch Org	Temporary, consistent, no conflicts

🔄 Section 4 — Sandbox Refresh — Everything You Need to Know

What happens, what you lose, what is kept, and how to prepare

📖 What is a Sandbox Refresh?

A sandbox refresh is the process of recreating a sandbox by copying the current state of your production org. Think of it like taking a fresh photograph of production — the old sandbox is completely deleted and a brand new one is built from production at that moment in time.

✅ What Gets Copied During Refresh

Item	Developer	Partial Copy	Full
All Apex code	✅ Yes	✅ Yes	✅ Yes
All LWC/Aura components	✅ Yes	✅ Yes	✅ Yes
Custom objects & fields	✅ Yes	✅ Yes	✅ Yes
Flows, validation rules	✅ Yes	✅ Yes	✅ Yes
Profiles & permission sets	✅ Yes	✅ Yes	✅ Yes
Users	✅ Yes	✅ Yes	✅ Yes
Data records	❌ No	✅ Sample	✅ All
File attachments	❌ No	❌ No	✅ Yes

❌ What is LOST During Refresh — Critical!

All sandbox-specific customizations NOT in production are permanently deleted
Any Apex class, LWC, Flow, or field you built in the sandbox but never deployed to production
All test data you manually created in the sandbox
All user passwords — everyone must reset passwords after refresh
All Named Credential configurations pointing to test endpoints
All custom settings configured specifically for the sandbox
All scheduled jobs running in the sandbox

⚠️ There is NO way to recover anything lost in a sandbox refresh. Backup what matters before refreshing!

🎯 Pre-Refresh Checklist — Always Do This!

Step	Action	Why
1	Deploy all completed features to production first	Anything in sandbox but not production will be lost
2	Export important test data you want to keep	All sandbox data is wiped during refresh
3	Document all sandbox-specific configurations	Named credentials, custom settings, email relay settings
4	Notify all sandbox users	Their passwords will reset, work in progress may be lost
5	Save any test scripts or setup scripts	You will need to re-run them after refresh

💡 How to Refresh a Sandbox

1. Log into Production org 2. Setup → Sandboxes 3. Find your sandbox → click Refresh 4. Select sandbox type (can change type on refresh) 5. Select template (Partial Copy only) 6. Click Start Refresh 7. Wait — Developer takes minutes, Full takes hours to days

✅ Post-Refresh Steps — Always Do This!

✅ Log in to sandbox at test.salesforce.com (not login.salesforce.com)
✅ Username format: youremail@company.com.sandboxname
✅ Reset your password via "Forgot Password"
✅ Reconfigure Named Credentials to point to test endpoints
✅ Reconfigure email deliverability settings
✅ Re-run your Test Data Factory to seed test data
✅ Notify all team members sandbox is ready

🏢 XYZ Company Example

XYZ Company refreshes their Partial Copy QA sandbox every month after the production release cycle. Before refreshing, they run a checklist: deploy all pending features, export QA-specific test accounts, and notify the QA team 24 hours in advance. After refresh, the admin runs the TestDataFactory Apex script and reconfigures the Business Central API Named Credential to point to the BC test environment — the QA sandbox is ready within 2 hours of refresh completing.

📋 Section 5 — Sandbox Templates

Control exactly what data goes into your Partial Copy sandbox

📖 What is a Sandbox Template?

A Sandbox Template is a configuration that defines exactly which Salesforce objects and how many records are copied into a Partial Copy sandbox during creation or refresh.

Without a template, Salesforce randomly selects up to 10,000 records per object — you have no control over which records are copied or whether related records come together. With a template, you get exactly the data you need for meaningful testing.

✅ Why Templates Matter — The Problem Without Them

Without a template: Salesforce copies 10,000 random Accounts. But none of those Accounts might have related Contacts or Opportunities — because those 10,000 Contacts were picked randomly from different Accounts. Your testers have orphaned records with no relationships — useless for testing.

With a template: You say "give me 500 Accounts AND their related Contacts AND their related Opportunities." Salesforce maintains the data relationships — testers have realistic, connected data.

📊 How to Create a Sandbox Template

Step	Action	Location
1	Go to Sandbox Templates	Production Setup → Sandboxes → Sandbox Templates → New
2	Name your template	"QA Testing Template" or "Performance Template"
3	Select objects to include	Check the objects you need (Account, Contact, Opportunity, etc.)
4	Set record limits per object	Max records to include (e.g., 500 Accounts, 2000 Contacts)
5	Use template on refresh	When creating/refreshing Partial Copy, select this template

🏢 XYZ Company Sandbox Template Example

Object	Records	Why
Account	500	Enough for realistic testing across all territories
Contact	2,000	Multiple contacts per account
Opportunity	1,000	Test pipeline reports and dashboards
Product2	All	Need all products for quoting tests
Pricebook2	All	All pricelists for multi-currency testing
Order	500	Test order management flows
Case	300	Test service cloud workflows

Total: ~4,800 records — well within the 5GB Partial Copy limit. All records maintain their relationships — testers have realistic data that mirrors production behavior.

🔑 Key Points

Templates are only for Partial Copy sandboxes — Full sandboxes copy everything
You can create multiple templates for different testing needs
Template configuration does not copy to the sandbox — only the data it selects
Salesforce respects object relationships when copying — related records are included
Custom objects can also be included in templates

🌱 Section 6 — Sandbox Seeding

How to populate Developer sandboxes with test data

📖 What is Sandbox Seeding?

Sandbox seeding is the process of populating a Developer or Developer Pro sandbox with test data after creation or refresh. Since these sandboxes contain NO production data, developers must create their own test data before they can meaningfully test their work.

✅ Seeding Method 1 — Data Loader

Best for: Importing data from CSV files — accounts, contacts, products.

Steps:

Export data from production using Data Loader (as CSV)
Clean up the CSV (remove IDs, fix relationships)
Login to sandbox using Data Loader with test.salesforce.com endpoint
Import CSV files in dependency order (Account → Contact → Opportunity)

Limitation: Manual process, must maintain correct import order for relationships.

🌟 Seeding Method 2 — Test Data Factory (Best Practice)

The most professional approach — a dedicated Apex class that creates all test data programmatically. Run it with Anonymous Apex after every sandbox refresh and your environment is ready in minutes.

// TestDataFactory.cls — XYZ Company example public class TestDataFactory { public static void seedFullEnvironment() { // Step 1: Create Accounts List<Account> accounts = new List<Account>(); for (Integer i = 1; i <= 50; i++) { accounts.add(new Account( Name = 'Test Company ' + i, Industry = 'Manufacturing', BillingCountry = 'India', Phone = '+91 99999' + String.valueOf(i).leftPad(5, '0') )); } insert accounts; // Step 2: Create Contacts linked to Accounts List<Contact> contacts = new List<Contact>(); for (Account acc : accounts) { contacts.add(new Contact( FirstName = 'Test', LastName = 'Contact ' + acc.Name, AccountId = acc.Id, Email = 'test.' + acc.Name.toLowerCase().replace(' ', '.') + '@testxyz.com' )); } insert contacts; // Step 3: Create Opportunities List<Opportunity> opps = new List<Opportunity>(); for (Account acc : accounts) { opps.add(new Opportunity( Name = acc.Name + ' — Q2 Deal', AccountId = acc.Id, StageName = 'Prospecting', CloseDate = Date.today().addDays(30), Amount = 50000 + (Math.random() * 100000).intValue() )); } insert opps; System.debug('✅ Seeding complete! 50 Accounts, Contacts & Opportunities created.'); } } // Run in Anonymous Apex: // TestDataFactory.seedFullEnvironment();

💡 Seeding Method 3 — Dataloader.io

Best for: Quick seeding without writing code. Dataloader.io (by Mulesoft) is a free web-based tool that lets you import CSV data into any Salesforce org through a clean UI — no Data Loader installation needed.

Steps: Login with Salesforce OAuth → Choose object → Upload CSV → Map columns → Import. Done in 5 minutes.

✅ Seeding Best Practices

Practice	Why
Use a Test Data Factory class	Reusable, consistent, version-controlled
Seed in dependency order	Account first, then Contact, then Opportunity
Use realistic but fake data	Real email addresses risk sending test emails to real people
Include edge cases	Empty fields, max length values, special characters
Document your seed script	New team members can set up in minutes

📧 Section 7 — Email Deliverability in Sandboxes

Prevent accidentally emailing real customers from your sandbox

📖 Why Email Deliverability Matters

Sandboxes contain copies of production data — including real customer email addresses. If email deliverability is set incorrectly, your test workflows, approval processes, or email alerts will send real emails to real customers from your sandbox.

Imagine a Flow that sends "Your order has been confirmed" — if running in a sandbox during testing, it will email actual customers with wrong order information. This is a serious issue that needs to be configured correctly immediately after every sandbox refresh.

✅ The 3 Deliverability Settings

Setting	What Gets Sent	Use Case
No Access	Nothing at all	Fully isolated — no emails of any kind
System Email Only	System emails (password resets, admin notifications)	Default sandbox setting — safest for development
All Email	All emails including workflow and template emails	Use only with test data AND an email relay

📍 Where to Configure

Setup → Email → Deliverability → Access Level ↓ Select: System Email Only (recommended default) or All Email (only if you have an Email Relay configured)

✅ Best Practice — Email Relay

If you need to test email templates or workflows that send emails, configure an Email Relay — this redirects ALL outbound sandbox emails to a single internal inbox instead of the real recipient.

Setup: Setup → Email Relay Activation → Add your internal test email address (e.g., sandbox-emails@xyzcompany.com). Now when a workflow sends "Your Quote is Ready" to customer@realcompany.com, it actually goes to sandbox-emails@xyzcompany.com — where your team can verify it without the customer ever seeing it.

❌ Common Mistake

Setting deliverability to "All Email" without an Email Relay after a Full sandbox refresh
Running a test that triggers an email workflow — 500 customers receive a test email
This has happened to real companies and caused serious trust issues with customers
Always check email deliverability settings immediately after every sandbox refresh

🗺️ Section 8 — Building Your Environment Strategy

How to design the right environment pipeline for your team

📖 What is an Environment Strategy?

An environment strategy defines how many environments you have, what each is used for, and how changes flow through them from development to production. A well-designed strategy prevents conflicts, ensures quality, and makes deployments predictable.

✅ The Standard 4-Tier Environment Strategy

Most professional Salesforce teams use a 4-tier environment pipeline:

👨‍💻 Dev Sandbox
Build & Unit Test

→

🧪 QA Sandbox
QA Testing

→

✅ UAT Sandbox
Business Approval

→

🚀 Production
Live Customers

📊 Each Tier — Purpose & Rules

Tier	Sandbox Type	Owner	Purpose	Gate to Next
🟢 Development	Developer (1 per dev)	Developer	Write code, unit test	All Apex tests pass, code review done
🧪 QA	Partial Copy	QA team	Regression, integration tests	QA sign-off, all test cases pass
✅ UAT	Full Sandbox	Business users	User acceptance, final validation	Business sign-off from stakeholder
🚀 Production	Production org	Admin/Release manager	Live customers	Scheduled release window

💡 For Smaller Teams — The 2-Tier Strategy

Not every team needs 4 tiers. Small teams (1-3 people) can use a simpler 2-tier strategy:

👨‍💻 Developer Sandbox
Build & Test

→

🚀 Production
Deploy after validation

This is perfectly fine for small teams. Start simple and add tiers as your team and deployment complexity grows.

🔑 Environment Strategy Rules

Changes always flow forward — Dev → QA → UAT → Production. Never backward except through the pipeline
Never skip a tier — if something goes straight from Dev to Production, the QA and UAT catches are missed
Each environment should be refreshed on a regular schedule to stay in sync with production
Document who owns each environment and who can approve promotions

🔬 Section 9 — Sandbox vs Scratch Org

Understanding when to use each type of development environment

📖 Introduction

As you progress through this DevOps course, you will work with both Sandboxes and Scratch Orgs. They serve different purposes and understanding the difference is fundamental to modern Salesforce DevOps.

Scratch Orgs are covered in depth in Module 7 — this section gives you the conceptual foundation.

✅ Full Comparison

Feature	🏖️ Sandbox	🔬 Scratch Org
Lifespan	Permanent (until refreshed)	Maximum 30 days
Created from	Production org (copy)	Definition file (JSON)
Production data	Partial or Full copy	No production data
Version control	Limited integration	Fully source-driven
Creation time	Minutes to hours	5 minutes
Environment consistency	Can drift from production	Always identical (same definition)
Cost	Included with license	Requires Dev Hub org
Multiple at once	Limited (purchased)	40 active simultaneously
Best for	QA, UAT, training	Feature development, CI/CD
Required knowledge	Basic Salesforce	SFDX CLI, Git

🎯 Simple Decision Rule

Situation	Use
QA team needs to test a feature with real data	🏖️ Partial Copy Sandbox
Business users doing UAT sign-off	🏖️ Full Sandbox
Training new employees	🏖️ Full Sandbox
Developer building a new feature (SFDX)	🔬 Scratch Org
CI/CD pipeline needs a clean environment	🔬 Scratch Org
Quick fix, no SFDX set up yet	🏖️ Developer Sandbox

💡 Where You Are in the Course

Right now (Modules 1-5), you are learning the traditional sandbox-based approach. Starting from Module 6 (SFDX & CLI) and Module 7 (Scratch Orgs), you will add the modern Scratch Org approach to your toolkit. By Module 15, you will use both strategically — Scratch Orgs for development, Sandboxes for QA and UAT.

🏢 Section 10 — XYZ Company Environment Setup

See exactly how a real team structures their Salesforce environments

📖 XYZ Company — Full Environment Map

XYZ Company has 3 developers (Anant, Raj, Priya), 1 Salesforce admin (Meera), and 1 QA lead (Kavya). Here is their complete environment setup after adopting a proper DevOps strategy.

✅ XYZ Company Environment Inventory

Environment	Type	Owner	Purpose	Refresh Schedule
Production	Live org	IT Manager	Real customers, live operations	Never refreshed
UAT Sandbox	Full	Meera (Admin)	Business sign-off before releases	Before major releases
QA Sandbox	Partial Copy	Kavya (QA Lead)	QA regression and integration testing	Monthly
Anant-Dev	Developer	Anant (Dev)	Apex, LWC, Agentforce development	When needed
Raj-Dev	Developer	Raj (Dev)	Integration and API development	When needed
Priya-Dev	Developer	Priya (Dev)	Flow and declarative development	When needed

🔄 XYZ Company Release Flow

👨‍💻 Anant-Dev
Builds Feature

→

🧪 QA Sandbox
Kavya Tests

→

✅ UAT Sandbox
Business Approves

→

🚀 Production
Every Tuesday

Every Tuesday is XYZ Company's release day. Changes that have passed QA and UAT by Monday are deployed every Tuesday morning at 9 AM IST — a regular, predictable release cadence.

💡 XYZ Company Sandbox Rules

🔴 Never make changes directly in production — everything goes through Dev → QA → UAT → Prod
🟡 QA sandbox is refreshed every 1st of the month — everyone knows when the refresh is coming
🟢 Developer sandboxes are each developer's responsibility — refresh when you need a clean slate
📧 Email deliverability on all sandboxes is "System Email Only" — email relay configured on QA and UAT
📋 Pre-refresh checklist is mandatory — no sandbox is refreshed without sign-off from the owner

⚠️ Section 11 — Common Sandbox Mistakes to Avoid

Learn from others' mistakes before making your own

❌ Mistake 1 — Refreshing a Sandbox Without Checking What's In It

What happens: Developer refreshes their sandbox, unknowingly wiping 3 weeks of work that was never deployed to production
The fix: Always run the pre-refresh checklist. Check what is in the sandbox that is not in production. Deploy completed work first.

❌ Mistake 2 — All Team Members Sharing One Developer Sandbox

What happens: Developer A deploys a change. Developer B refreshes the page and sees the change — now they are accidentally building on top of each other. One person saves a component and overwrites the other's work.
The fix: One sandbox per developer. They are cheap (included with licenses) and prevent all conflicts.

❌ Mistake 3 — Forgetting to Reconfigure Integrations After Refresh

What happens: QA sandbox is refreshed. The Named Credential for Business Central is now pointing to production BC endpoint. QA tests create real orders in the production ERP system.
The fix: Post-refresh checklist must include reconfiguring all Named Credentials and Remote Site Settings to point to test/sandbox endpoints.

❌ Mistake 4 — Testing Email-Heavy Workflows Without an Email Relay

What happens: QA team runs a test that triggers a "Quote Approved" email workflow. 200 customers receive a fake "your quote is approved" email from the company's real email address.
The fix: Always configure email relay on QA and UAT sandboxes before enabling "All Email" deliverability. Never use "All Email" without a relay when real customer data is present.

❌ Mistake 5 — Treating Sandbox as Production Backup

What happens: Team thinks "if production breaks, we can restore from the Full sandbox." Not true — Full sandbox does not automatically stay in sync with production. After its 29-day refresh, it may be weeks out of date.
The fix: Use Salesforce Backup & Restore or a third-party backup tool for production backups. Sandboxes are development environments, not backup systems.

📝 Section 12 — Module 2 Quiz

Test everything you learned before moving to Module 3

🧠 Module 2 Knowledge Check — 10 Questions

Q1. Which sandbox type is a complete clone of production including ALL data?

A) Developer Pro

B) Partial Copy

C) Full Sandbox ✅

D) Developer

Q2. What is the minimum refresh interval for a Partial Copy sandbox?

A) 1 day

B) 5 days ✅

C) 29 days

D) 7 days

Q3. What happens to sandbox-specific changes that were NOT deployed to production when you refresh a sandbox?

A) They are automatically deployed to production first

B) They are permanently lost ✅

C) They are saved in a backup

D) They are moved to another sandbox

Q4. What is the purpose of a Sandbox Template?

A) To design the sandbox UI layout

B) To define which objects and records are copied into a Partial Copy sandbox ✅

C) To automate sandbox creation

D) To set sandbox user permissions

Q5. What URL do you use to log into a Salesforce sandbox?

A) login.salesforce.com

B) test.salesforce.com ✅

C) sandbox.salesforce.com

D) dev.salesforce.com

Q6. What is the default email deliverability setting on a sandbox?

A) All Email

B) No Access

C) System Email Only ✅

D) Relay Only

Q7. Which environment type is BEST for User Acceptance Testing with real business users?

A) Developer Sandbox

B) Partial Copy Sandbox

C) Full Sandbox ✅

D) Scratch Org

Q8. What is Sandbox Seeding?

A) Refreshing a sandbox from production

B) Populating a Developer sandbox with test data after creation ✅

C) Setting up sandbox user accounts

D) Copying sandbox data to production

Q9. In the standard 4-tier environment strategy, what comes after QA?

A) Development

B) Production

C) UAT ✅

D) Staging

Q10. What is the maximum lifespan of a Scratch Org?

A) 7 days

B) 14 days

C) 30 days ✅

D) 90 days

✅ Answer Key

C, B, B, B, B, C, C, B, C, C — Score 9-10: Excellent! Ready for Module 3. Score 7-8: Review Sections 2 and 4. Score below 7: Re-read the full module before continuing.

📋 Module 2 Summary — Key Takeaways

Everything you mastered in this module

✅ What You Learned in Module 2

✅ Salesforce has 6 environment types — each with a specific purpose in the development pipeline
✅ 4 sandbox types: Developer (200MB), Developer Pro (1GB), Partial Copy (5GB, sample data), Full (complete clone)
✅ Sandbox refresh completely wipes and recreates from production — sandbox-only changes are permanently lost
✅ Always run pre-refresh and post-refresh checklists to avoid losing work or misconfiguring the environment
✅ Sandbox Templates control which records are copied into a Partial Copy sandbox — maintain data relationships
✅ Sandbox seeding populates Developer sandboxes using Data Loader, Dataloader.io, or a Test Data Factory class
✅ Email deliverability defaults to System Email Only — always configure an Email Relay before enabling All Email
✅ Standard 4-tier strategy: Dev → QA (Partial Copy) → UAT (Full) → Production
✅ Sandboxes = persistent, production copies for QA/UAT. Scratch Orgs = temporary, source-driven for development

🎤 Module 2 One-Line Summary

"Salesforce provides 4 sandbox types for different purposes — use Developer for coding, Partial Copy for QA testing, Full for UAT — always run pre-refresh checklists, use Sandbox Templates for data control, configure Email Relay before enabling email delivery."

➡️ Next: Module 3 — Change Sets Mastery

Deep dive into Change Sets — the full deployment workflow, validate vs deploy, Quick Deploy, troubleshooting failures, and when to graduate beyond Change Sets

Module 3 →

🚀 Enjoying This Free DevOps Course?

Share it with your Salesforce community — every share helps one more professional learn DevOps for free. 21,000+ learners this month!

All Free Resources → 75 DevOps Interview Q&As →