EXMP study materials
EXMP study resources

EXMP flashcards

EXMP · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

System boundary
The line separating a system from its environment. It determines which components, interactions, and data flows are inside the scope of analysis and which are external influences.
Emergent behavior
A property or behavior that appears only from interactions among components and cannot be predicted by examining any component alone. Examples include traffic jams and cascading failures.
Cohesion and coupling
Cohesion measures how strongly related the responsibilities inside one module are. Coupling measures interdependence between modules. Good design seeks high cohesion and low coupling.
Feedback loop polarity
A reinforcing loop amplifies change and drives growth or collapse. A balancing loop counteracts change and seeks a target. Polarity is the product of link signs around the loop.
Functional requirement
A statement of what the system must do, expressed as behavior or a service the system provides to a user or another system. It is verifiable by a test.
Non-functional requirement
A constraint on how well the system performs its functions, covering qualities such as performance, availability, security, usability, and maintainability. It must be measurable to be testable.
MoSCoW prioritization
A ranking scheme that classifies requirements as Must have, Should have, Could have, or Won't have this time. All Must items must fit the fixed timebox or scope is renegotiated.
Three-point estimation
An estimation technique using optimistic, likely, and pessimistic values. The expected value is (optimistic + 4 times likely + pessimistic) divided by six, reducing single-estimate bias.
Work breakdown structure
A hierarchical decomposition of project deliverables into smaller, manageable pieces. The lowest level is a work package that can be estimated, assigned, and tracked.
Layered architecture
A structure organizing components into layers where each layer depends only on the one beneath it. This isolates change and allows a layer to be replaced without affecting others.
Interface contract
A specification of the inputs, outputs, preconditions, postconditions, and error behavior a component promises. It lets callers depend on behavior rather than on implementation details.
Quality attribute scenario
A structured statement of a quality requirement containing source, stimulus, environment, affected artifact, response, and a measurable response measure. It makes vague qualities testable.
Idempotency
A property where performing an operation multiple times produces the same result as performing it once. It makes retries safe in distributed systems where responses can be lost.
CAP theorem
A theorem stating a distributed data store cannot simultaneously guarantee consistency, availability, and partition tolerance. During a network partition, a system must choose between consistency and availability.
Baseline
A fixed, approved reference point for configuration items. Changes after the baseline are controlled through formal change procedures so the reference remains comparable over time.
Infrastructure as code
The practice of defining servers, networks, and platform configuration in version-controlled files. Environments become reproducible, reviewable, and auditable rather than manually assembled.
Environment parity
Keeping development, test, staging, and production environments aligned in configuration, dependency versions, and platform settings. Drift between them causes defects that appear only in production.
Blue-green deployment
A release technique maintaining two identical environments. Traffic switches from the live blue environment to the updated green one, enabling fast rollback by switching back.
Canary release
A deployment pattern routing a small fraction of traffic to a new version before full rollout. Monitored error and latency signals decide whether to proceed or roll back.
Verification versus validation
Verification confirms the product was built according to its specification. Validation confirms the specification reflects actual user need. Both are required for quality assurance.
Equivalence partitioning
A test design technique dividing inputs into classes expected to behave identically. One representative value per class is tested, reducing cases without losing meaningful coverage.
Boundary value analysis
A technique testing values at and adjacent to the edges of input ranges. Defects cluster at boundaries because off-by-one errors and limit handling are common implementation mistakes.
Test pyramid
A guideline balancing test types: many fast unit tests at the base, fewer integration tests in the middle, and few slow end-to-end tests at the top.
Code coverage limits
Coverage reports which lines or branches tests execute, not whether behavior was asserted correctly. High coverage with weak assertions still allows defects to escape.
Error budget
The allowable amount of unreliability derived from a service level objective. If the objective is 99.9 percent availability, the error budget is the remaining 0.1 percent of time.
Four golden signals
Latency, traffic, errors, and saturation. These four metrics give a compact view of service health and are commonly used as the basis for monitoring dashboards and alerts.
Symptom-based alerting
Alerting on user-visible impact such as elevated error rate or latency, rather than on internal causes. This reduces noise and pages only when service quality is actually degraded.
Blameless post-incident review
A structured review after an incident focused on systemic causes and preventive actions rather than individual fault. It produces owned, dated action items to reduce recurrence.
CIA triad
Confidentiality, integrity, and availability. These three properties frame security objectives, and each control should be mapped to the property it is intended to protect.
Least privilege
Granting only the permissions required for a specific task, for the shortest practical duration. Standing administrative access violates the principle and enlarges the impact of compromise.
Risk treatment options
Four responses to identified risk: avoid the activity, mitigate likelihood or impact, transfer it to another party such as an insurer, or accept it with documented rationale.
Authentication versus authorization
Authentication establishes who a subject is. Authorization decides which actions that subject may perform. Confusing the two is a frequent source of access control defects.