← VCE Software Development U4O2

Separating development, testing and production environments

Keeping development, testing and production apart so untested code and live data never mix, and access to each is controlled separately. It also helps contain a breach.

Understanding Separating development, testing and production environments in VCE Software Development U4O2

What it does: The condition is a gate that makes promotion of code controlled, so untested code cannot reach the live environment. Different credentials per environment contain a breach, because a stolen development key does not unlock production. Keeping live data out of development means a breach of a developer's machine or account cannot expose real customer information. Production access is restricted and controlled separately from development, following the principle of least privilege. If a single login opened every environment, then separation would offer little protection. Each environment needs its own controls.

Common mistakes: The development environment must never use live data. It should load fake or dummy data, such as 'fake_students.db', not the live student records. Access to production must be restricted to specific authorised roles. Setting allow to TRUE gives everyone access. It should check for a role such as 'ops_admin'.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

This module's key terms are also in a printable crossword (Modules 49–72) and word search (Modules 49–130).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Which approach follows environment separation?
Developers build and test using dummy data in the development environmentDevelopers copy the live customer database into development to test with real data
Matches
dev_db.copy_from("production_customers")
↓
Copies live customer data into the development environment, so real personal data is exposed to developers and mixes with untested code. Use sample or anonymised data instead.
Applying
Meanings
Term
Environment separation
Meaning
Keeping development, testing and production apart so untested code and live data never mix, and access to each is controlled separately. It also helps contain a breach.
Practice
environment ← "development"
Testing
Gaps
IF environment = "" THEN
Check Answer
Spots
1env ← 'dev'
2db ← 'live_students.db'

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Zebra' badge — Pattern Matcher, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Quick Questions

1. Which approach follows environment separation?
A. Developers build and test using dummy data in the development environment ✓
B. Developers copy the live customer database into development to test with real data
Keeping live data out of development means a breach of a developer's machine or account cannot expose real customer information.
2. Who should normally have access to the production environment?
A. Every developer on the team, so they can fix problems quickly
B. Only a few authorised staff who need it for their role ✓
Production access is restricted and controlled separately from development, following the principle of least privilege.
3. How should new code reach production?
A. It is tested in the testing environment, approved, then promoted to production ✓
B. The developer uploads it straight from their laptop to production when it seems to work
Controlled promotion means untested code never goes live. It passes through testing and approval first.
4. A hacker steals a developer's login for the development environment. With separate environments, what is the likely result?
A. The breach is contained, because the hacker cannot reach production or live data ✓
B. The hacker can reach production and live data just as easily as development
Separate access controls for each environment limit how far an attacker can move, which helps contain a breach.
5. Which statement about separated environments is true?
A. One shared login gives access to all three environments
B. Each environment has its own access controls ✓
If a single login opened every environment, then separation would offer little protection. Each environment needs its own controls.

Match the Pairs

DEV_DB = "dev_sample_data" → The development environment uses fake or sample data, so no live customer data is exposed while developers work
PROD_ACCESS = ["ops_lead", "sys_admin"] → Only a small, named group can access production, so access to the live environment is restricted and controlled separately
Code is promoted from development to testing to production only after it passes checks and is approved → if tests_passed and approved: deploy("production")
Each environment has its own separate credentials, so a breach in one cannot be used to get into another → DEV_KEY != TEST_KEY != PROD_KEY
dev_db.copy_from("production_customers") → Copies live customer data into the development environment, so real personal data is exposed to developers and mixes with untested code. Use sample or anonymised data instead.
git push origin dev --deploy-to=production → Deploys untested development code straight to production, skipping testing and approval. Code should be promoted step by step through a controlled process.

Key Term

Environment separation
Keeping development, testing and production apart so untested code and live data never mix, and access to each is controlled separately. It also helps contain a breach.

Fill in the Blanks

1. IF environment = "development" THEN data ← sampleData
Hint: Type the name of the environment where only fake sample data should be used instead of live customer records.
2. IF userRole = "developer" THEN productionAccess ← FALSE
Hint: Type the role whose access to the live production system should be blocked.
3. IF testsPassed AND approvedByLead THEN deploy(build, "production")
Hint: Type the logical operator that requires both conditions to be true before code is promoted.
4. IF breachIn = "development" THEN productionExposed ← FALSE
Hint: Type the Boolean value showing that a breach in development is contained and live data stays safe.
5. ASSERT NOT (devDbHost = prodDbHost)
Hint: Type the logical operator that makes sure the development and production databases are not the same.

Spot the Error

Question 1
A env ← 'dev'
B db ← 'live_students.db'
C load(db)
Line B — The development environment must never use live data. It should load fake or dummy data, such as 'fake_students.db', not the live student records.
Question 2
A role ← user.role
B IF env = 'production' THEN
C allow ← TRUE
D END IF
Line C — Access to production must be restricted to specific authorised roles. Setting allow to TRUE gives everyone access. It should check for a role such as 'ops_admin'.
Question 3
A runUnitTests(build)
B IF allTestsPassed = FALSE THEN
C promote(build, 'testing')
Line B — Code should only be promoted to the next environment once its tests pass. The condition is inverted, so failing code would be promoted. It should be IF allTestsPassed THEN.
Question 4
A dev.key ← 'KEY_DEV_91'
B test.key ← 'KEY_TEST_47'
C prod.key ← dev.key
Line C — Each environment needs its own separate credentials. If production reuses the dev key, a breach of development also exposes production. Production should have its own key.
Question 5
A IF env = 'production' THEN
B data ← loadSampleData()
C ELSE
D data ← loadLiveData()
Line A — Sample data belongs in development, and live data only in production. With this condition, production would get sample data and development would get live data. It should check for 'development'.

Student with a class code? Join your class →