dev ops quiz

0.0(0)
Studied by 0 people
call kaiCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/30

encourage image

There's no tags or description

Looks like no tags are added yet.

Last updated 4:16 AM on 4/24/26
Name
Mastery
Learn
Test
Matching
Spaced
Call with Kai

No analytics yet

Send a link to your students to track their progress

31 Terms

1
New cards

CI/CD Definition

A tool that orchestrates your build and test-automation tools, running automatically on every commit or merge.

2
New cards

Blast radius

The impact zone of a change. Small change = small blast radius = lower risk.

3
New cards

Why fail fast and often?

Early failure (in dev/CI) is cheap and impacts only the engineer. Late failure (production) is expensive and damages reputation.

4
New cards

KISS approach for test automation

Keep It Simple, Stupid – start with one automated test for a primary use case, then grow. Even one test is better than none.

5
New cards

What should be stored in source control?

"If it can be changed, it should be in source‑control and versioned." (code, tests, config, docs, environment configs, scripts).

6
New cards

Configuration as code

Representing an environment (servers, firewalls, etc.) via configuration files stored and versioned in source control.

7
New cards

Binary repository

A place to store binary objects/artifacts – the runnable software created when source code is compiled.

8
New cards

Build once, deploy many times

The binary is built only once for a given release, and the same unchanged binary is used in all environments.

9
New cards

Why not bake secrets into the binary?

You'd need different binaries per environment or same credentials everywhere (insecure). Use runtime config files instead.

10
New cards

Defect lead time: 12‑week vs 2‑week releases

12 weeks → ~11 weeks 6 days; 2 weeks → ~9 days.

11
New cards

Even if customers can't accept frequent releases, you should still…

Adopt the practice of small, shippable chunks to build the habit of continuous delivery.

12
New cards

Three types of tests (simplified)

Unit (code logic), Integration (interactions), End‑to‑end (real user scenarios).

13
New cards

Inverted testing triangle

Many unit tests (largest layer), fewer integration tests, even fewer end‑to‑end tests – opposite of traditional manual-heavy testing.

14
New cards

Test data tripwire

Stale data causes random failures. Fix: create test data as part of the process and remove it as the final step.

15
New cards

Legacy strangulation

Systematically replacing parts of a legacy platform with modern components – not a big‑bang rewrite.

16
New cards

Component‑based architecture benefit for CD

Each component can be developed, built, tested, and shipped independently.

17
New cards

Never break your consumer

If you change a provider (library, API, OS), you must validate that no consumer is broken.

18
New cards

How to break a hard dependency between software and database?

Add a data‑access layer proxy or simply use SQL views.

19
New cards

Author's recommended "less‑is‑more" environment setup

Start with dev + CI environment + production. Add pre‑production / like‑live only if necessary.

20
New cards

Like‑live environment

Contains the same software and infrastructure versions as production (not necessarily same data).

21
New cards

Taking production offline to upgrade is…

unforgivable and wholly avoidable.

22
New cards

Three questions to ask when evaluating a CD tool

(Any three) Can it deploy same binary to multiple environments? Audit trail? Secure? No‑downtime? Integrate with CI? Support/SLA?

23
New cards

Automated provisioning

Programmatically creating virtual servers/environments via a recipe. Gives predictability and repeatability.

24
New cards

How automated provisioning enables blue/green deployments

Provision new environment (green) alongside live (blue), deploy new version, switch traffic via network change – zero downtime, instant rollback.

25
New cards

Who should be included in code reviews?

Not just developers – operations team should also be included (and vice versa).

26
New cards

Build Badger at ACME systems

A plush toy token – the holder is the only one allowed to change production at one time, enforcing "one change at a time" to avoid dependency hell.

27
New cards

When should you use a simple manual process instead of automation?

When automation would be overkill or create barriers (e.g., dependency management via whiteboard queue).

28
New cards

Rule of thumb for monitoring

"If it moves, monitor it. If it doesn't, monitor it just in case."

29
New cards

How to prove CD is not harming production with monitoring

Add a deployment marker/spike to time‑series graphs and visually compare performance before/after each deployment.

30
New cards

Who should be able to see monitoring dashboards?

Everyone in the business – not just the operations team.

31
New cards

hat is the purpose of a “pre‑baked vanilla server image” in automated provisioning?

A fresh virtual server that can be added quickly as part of the CD pipeline