Combined development, testing and production environments
Name:
Date:
Class:
A
Quick Questions
Shade in the A or B circle for each question.
1. A team builds, tests and runs their app in one combined environment. What is the main security problem?
2. Which testing practice is a risk of a combined environment?
3. A developer pushes a half-finished change in a combined environment. What is likely to happen?
4. Which statement about developer access is true in a combined environment?
5. An attacker breaks into the development part of a combined environment. What is the result?
B
Match the Pairs
Draw a line connecting each item on the left to its match on the right.
| Left column | Right column | |
|---|---|---|
| 1DB_HOST = "live-db.company.com" # used by dev and test | ACode is deployed to production even when tests have failed, because testing and production are not separated. Untested or faulty changes go live. Deploy only when tests pass, and test in a separate environment first. | |
| 2git push origin main # deploys straight to live server | Bdev_user.role = "production_admin" | |
| 3Developers have production access, so one stolen developer account or one slip can damage or expose every system and all live data. | CUsing one shared environment means a single breach or error exposes all code and live data. Fix it by using separate development, testing and production environments with their own access controls. | |
| 4Live customer records are copied into testing, so real personal data is exposed to staff and to any bugs or attacks in the test code. | DUntested changes go live immediately, so bugs or vulnerabilities reach real users with no separate testing stage. | |
| 5if (testsPassed == false) { deploy("production") } | EDevelopers and testers connect to the live production database, so live data is used for testing and could be changed or leaked. | |
| 6environment = "shared" # dev, test and live together | Ftest_data = load("live_customers.csv") |
C
Definitions
combined environment
D
Fill in the Blanks
Complete each line of code by filling in the missing parts.
1.
testDatabase ← ____________
2.
developer.saves(newCode)
__________ ← newCode
3.
_____ ALL ON liveData TO developer
4.
IF breach(sharedServer) = TRUE THEN
exposed ← dev + test + ____
5.
combinedEnvironments ← _
separatedEnvironments ← 3
E
Spot the Error
Shade in the letter of the line that contains an error.
Question 1
A
env = 'dev_only'
B
print('Dev+test+prod:', env)
C
deploy(env)
Question 2
A
env = 'shared'
B
data = load('fake_customers')
C
print('Testing on live data')
Question 3
A
def save_change(code)
B
live_site.update(code)
C
return 'Live now'
Question 4
A
change = edit('login.py')
B
live_site.update(change)
C
print('Tested before live')
Question 5
A
dev = 'sam'
B
perms = ['dev','test','prod']
C
if 'prod' == perms:
D
print(dev, 'edits live')
Answer Key
Combined development, testing and production environments
Section A: Quick Questions
Q1
B — Untested code and live data mix, so mistakes can reach real users
Q2
A — Testing new features using real customer data
Q3
B — The untested change goes live and may break the app for users
Q4
A — Developers end up with access to live production data and systems
Q5
A — One breach can expose everything, including live data
Section B: Match the Pairs
Q1
DB_HOST = "live-db.company.com" # used by dev and test → Developers and testers connect to the live production database, so live data is used for testing and could be changed or leaked.
Q2
git push origin main # deploys straight to live server → Untested changes go live immediately, so bugs or vulnerabilities reach real users with no separate testing stage.
Q3
Developers have production access, so one stolen developer account or one slip can damage or expose every system and all live data. → dev_user.role = "production_admin"
Q4
Live customer records are copied into testing, so real personal data is exposed to staff and to any bugs or attacks in the test code. → test_data = load("live_customers.csv")
Q5
if (testsPassed == false) { deploy("production") } → Code is deployed to production even when tests have failed, because testing and production are not separated. Untested or faulty changes go live. Deploy only when tests pass, and test in a separate environment first.
Q6
environment = "shared" # dev, test and live together → Using one shared environment means a single breach or error exposes all code and live data. Fix it by using separate development, testing and production environments with their own access controls.
Section C: Definitions
Q1
combined environment — One shared environment used for development, testing and production, so untested code and live data mix and mistakes or attacks can reach real users and data.Section D: Fill in the Blanks
Q1
testDatabase ← liveDatabaseQ2
developer.saves(newCode)
production ← newCodeQ3
GRANT ALL ON liveData TO developerQ4
IF breach(sharedServer) = TRUE THEN
exposed ← dev + test + liveQ5
combinedEnvironments ← 1
separatedEnvironments ← 3Section E: Spot the Error
Q1
A — In a combined environment, development, testing and production all use one shared environment. The line should be env = 'shared'. 'dev_only' contradicts the print message on line 2.
Q2
B — The program shows what happens in a combined environment: testing runs on real customer data. Loading 'fake_customers' would be safe test data, so it contradicts the print on line 3. It should load 'live_customers'.
Q3
A — A Python function definition must end with a colon. The line should be def save_change(code):. The function pushes untested code straight to the live site, as happens in a combined environment.
Q4
C — In a combined environment the change goes live without separate testing. The message should say the untested code is live, but the broken line claims it was tested first. It contradicts line 2.
Q5
C — To check whether 'prod' is one of the permissions, use the in operator. Comparing a string to the whole list with == is always False. It should be if 'prod' in perms:. The developer has production access.