Quiz Bank

70 Knowledge Check Questions

Filter by week or run through the full bank. Answers are checked instantly in the browser.

Week 1

What is software design mainly concerned with?

Choosing the most popular languageOrganizing software so it can be understood and changedWriting the fewest possible linesAvoiding all documentation

Week 1

A program with all logic in one function may be okay for a tiny exercise, but becomes risky because:

It cannot run on WindowsEvery change can affect unrelated behaviorIt uses too many commentsIt has no colors

Week 1

Architecture usually refers to:

Only variable namesHigh-level system structure and boundariesOnly CSS stylingThe keyboard shortcuts used by developers

Week 1

A good early design question is:

Can I use the newest framework?What can change later?Can I avoid testing forever?How do I hide all code in one file?

Week 1

Good design should make software:

Impossible to modifyEasier to understand, test, and changeLonger no matter whatDependent on one developer

Week 2

A functional requirement describes:

What the system doesThe color of all diagramsOnly the programming languageThe developer schedule only

Week 2

An acceptance criterion is useful because it:

Makes a requirement testableReplaces all codeAvoids user feedbackGuarantees no bugs

Week 2

“The page loads in under two seconds” is a:

Functional requirementNon-functional requirementClass nameLoop condition

Week 2

An assumption should be:

Hidden inside codeWritten down and checked when possibleIgnored until deploymentTreated as always true

Week 2

A constraint is:

A required design limitA random commentA design patternA bug report only

Week 3

High cohesion means:

A module has a clear focused purposeA module imports many librariesA module is very longA module has no tests

Week 3

Low coupling means:

Parts depend on unnecessary detailsParts are less unnecessarily dependent on each otherAll code is in one fileNo module can talk to another

Week 3

A god class is usually a class that:

Has too many responsibilitiesHas a useful nameUses an interfaceHas one private method

Week 3

A good decomposition should be based mostly on:

Meaningful responsibilitiesRandom file sizeAlphabetical orderColor themes

Week 3

Separation of concerns helps because:

Changes stay more localizedIt removes all bugsIt avoids all requirementsIt guarantees performance

Week 4

Encapsulation helps by:

Letting any code change any fieldProtecting internal state and rulesRemoving all methodsForcing inheritance

Week 4

Composition means:

Building objects from collaborating partsOnly using parent classesDeleting all interfacesPutting all code in main

Week 4

Inheritance is risky when:

It is used only to share code without true substitutabilityIt has clear parent-child meaningIt supports polymorphismIt is tested

Week 4

An invariant is:

A rule that should always remain trueA random UI colorA package managerA temporary variable

Week 4

A data-only class plus one giant manager can lead to:

Scattered behavior and weak domain designPerfect encapsulationNo couplingAutomatic testing

Week 5

SRP says a class should have:

One main reason to changeExactly one lineNo dependencies everOnly static methods

Week 5

OCP encourages:

Constantly editing old code for every new behaviorAdding new behavior through extension pointsAvoiding all interfacesUsing one giant switch forever

Week 5

LSP is mainly about:

Subtypes honoring parent expectationsCSS inheritanceDatabase indexesFile names

Week 5

A growing switch statement over behavior may suggest:

A possible strategy or polymorphism opportunityPerfect OCP complianceNo design issue everA need for global variables

Week 5

SOLID should be used:

With judgment based on change and complexityBy creating interfaces for every single lineOnly in gamesOnly in databases

Week 6

ISP says clients should not depend on:

Methods they do not useAny code at allVariable namesComments

Week 6

DIP says high-level policy should depend on:

Low-level details directlyAbstractionsConsole logs onlyCSS files

Week 6

Dependency injection means:

Dependencies are passed in from outsideAll code goes into one objectThe database writes codeTests are deleted

Week 6

A good dependency to abstract is often:

A payment provider or email serviceA simple addition operatorA local variableA string literal always

Week 6

A fake object in tests can:

Replace an expensive external serviceEliminate the need for designGuarantee no bugsDeploy the app

Week 7

DRY is mostly about avoiding duplicated:

Knowledge and rulesAll similar-looking charactersEvery blank lineAll functions

Week 7

YAGNI warns against:

Building unneeded future features too earlyWriting readable codeTesting important behaviorUsing simple designs

Week 7

KISS means:

Prefer clear simple solutionsAlways write one-line codeNever use classesAvoid requirements

Week 7

A name like processData is weak because:

It hides intentIt is too short onlyIt uses lettersIt compiles

Week 7

Premature abstraction can:

Create complexity before there is a real needAlways improve codeRemove every bugMake requirements unnecessary

Week 8

A sequence diagram is best for showing:

Interactions over timeOnly database table colorsPackage install commandsCSS breakpoints

Week 8

A class diagram is useful for showing:

Classes and relationshipsOnly server logsRuntime memory usage onlyMarketing copy

Week 8

A component diagram usually shows:

High-level system parts and boundariesEvery local variableOnly test resultsKeyboard shortcuts

Week 8

A useful diagram should:

Answer a clear design questionInclude every possible detailAvoid labelsReplace code completely

Week 8

For this course, diagram value is measured mostly by:

Clarity of communicationPerfect decorative complexityNumber of arrows onlyWhether it uses colors

Week 9

Strategy is useful when:

Behavior varies and should be interchangeableEvery object must be globalYou need CSS stylesYou want no classes

Week 9

Factory helps manage:

Object creation decisionsKeyboard input onlyCommentsScreen resolution

Week 9

Observer is useful for:

Notifying subscribers about eventsCreating one global instance onlySorting arrays onlyReplacing all tests

Week 9

Singleton should be used carefully because:

It can hide dependencies and hurt testsIt is always impossibleIt never worksIt only applies to HTML

Week 9

A design pattern should be used when:

It solves a real design problemIt makes the code sound advancedEvery assignment requires one lineThe code is already simple enough

Week 10

Adapter is used to:

Translate between incompatible interfacesMake all classes globalRemove all dependenciesWrite CSS

Week 10

Decorator is useful when:

Adding behavior around an object without changing itDeleting all objectsAvoiding compositionReplacing requirements

Week 10

Command represents:

An action as an objectA database table onlyA font sizeA server address

Week 10

Repository separates:

Persistence from business logicComments from variablesColors from fontsStudents from quizzes only

Week 10

MVC/MVVM mainly help separate:

UI, state, and behaviorOnly imagesOnly deployment scriptsAll code into one file

Week 11

A unit test usually checks:

A small piece of behaviorThe entire internetOnly deployment settingsA logo file

Week 11

A fake repository is useful because:

It can replace real storage in testsIt makes tests impossibleIt sends real paymentsIt removes all code

Week 11

Hard-to-test code often has:

Tight coupling or mixed responsibilitiesToo many good namesToo much clarityNo behavior

Week 11

A test seam is:

A place to replace real behavior with controlled behaviorA CSS borderA production outageA database password

Week 11

Tests should usually focus on:

Important observable behaviorOnly private implementation detailsMaking code longerAvoiding requirements

Week 12

Architecture is mostly concerned with:

High-level structure and boundariesOnly line formattingOnly variable namesOnly keyboard shortcuts

Week 12

A layered architecture usually separates:

UI, services/domain, and data concernsAll code by colorStudents by alphabet onlyCSS from HTML only

Week 12

A monolith is:

An app deployed as one unitAlways badAlways a databaseA design pattern only for games

Week 12

Microservices add complexity because:

Systems communicate over networks and deploy separatelyThey remove all operations workThey need no monitoringThey avoid APIs

Week 12

Architecture decisions should be judged by:

Context and tradeoffsTrendiness onlyNumber of diagramsLogo size

Week 13

Refactoring means:

Changing internal structure without changing external behaviorAdding every feature at onceDeleting testsChanging the product goal

Week 13

A code smell is:

A warning sign of possible design troubleProof the code cannot runA syntax error onlyA CSS class

Week 13

Shotgun surgery means:

One change requires edits in many placesA method is too shortA variable is well namedTests run quickly

Week 13

Technical debt is:

Future cost created by current shortcutsAlways evilOnly unpaid invoicesA compiler feature

Week 13

Safe refactoring usually uses:

Small steps and feedbackOne huge secret rewriteNo tests or commitsRandom file moves

Week 14

A strong design review should explain:

Why choices were madeOnly the color paletteOnly how many files existNothing about tradeoffs

Week 14

A tradeoff is:

A benefit/cost decision in designAlways a mistakeA syntax errorA quiz type

Week 14

A good pattern explanation includes:

The problem it solvedOnly the pattern nameA claim that all patterns are requiredNo context

Week 14

A small clean capstone is:

Often better than a large messy projectAlways unacceptableNot softwareImpossible to grade

Week 14

Honest reflection shows:

Design maturityFailure onlyNo learningThat tests are unnecessary