Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
50 results for “Container Image Strategy”
Base Image Currency
How far behind the fleet's running images are from their patched base, which is the number that decides how fast a critical vulnerability can be closed.
Container Image
A layered, content-addressed filesystem bundle plus metadata, from which containers are instantiated — immutable by construction and identified by digest.
Image Registry
The store from which container images are pulled, and an under-appreciated availability and security dependency of every deployment and every autoscale event.
Attribute History Strategy
The per-attribute decision about whether history is overwritten, versioned or kept alongside the current value, which is a business question rather than a technical one.
Backup Strategy
A plan for what is copied, how often, where to, how long it is kept, and — the part that decides whether it is real — how the restore is verified.
Caching Strategy
The chosen pattern for how a cache is populated, read and invalidated — cache-aside, read-through, write-through or write-behind.
Chunk Boundary Strategy
How source documents are split for embedding, which determines whether retrieved passages are self-contained and coherent.
Database Migration Strategy
The approach for moving data to a new store, which is usually the longest pole and the highest risk in any modernisation.
Fallback Strategy
What a caller does instead when a circuit breaker is open — the part of the pattern that determines whether failing fast helps anyone.
Indexing Strategy
Choosing the set of indexes a table carries by working backwards from its actual queries, and accepting the write cost that each one adds.
Subject Naming Strategy
How schemas are keyed in a registry — per topic, per record type, or both — which determines whether one topic may carry several event types.
Tagging Strategy
A defined, enforced set of metadata labels applied to every resource, without which cost allocation, ownership and lifecycle automation are all impossible.
Test Strategy Altitude
Deciding which risks are verified at which level, so that each layer tests something the layers below it structurally cannot.
Testing Strategy Shape
The distribution of tests across levels, chosen so that feedback is fast where it can be and confidence is real where it must be.
A/B Partition Update
Writing firmware to an inactive partition and switching on next boot, so a failed update falls back to the previous image rather than bricking the device.
Architecture Review Board
A forum that reviews significant designs against standards, risks and strategy before commitment.
Build Graph Scoping
Determining which packages a change actually affects, so a monorepo builds and tests a subset rather than everything on every commit.
Business Capability
What a business does, expressed stably and independently of how it currently does it or who is responsible.
C4 Model
A set of four nested diagram levels — context, container, component, code — that keeps each diagram at one consistent level of abstraction.
Capability Map
A structured view of everything a business does, used as the stable frame for mapping applications, investment, ownership and gaps.
Environment Ladder
The ordered set of environments a change climbs, where each rung is justified by a distinct claim it can prove that the one below cannot.
Forced Upgrade
Blocking an installed client version from operating until it updates, which is the only lever available and is disruptive enough to need a policy.
Kubernetes
A container orchestrator that continuously reconciles the running state of a cluster towards a declared desired state.
Multi-Cloud
Deliberately running across more than one cloud provider — a decision with a much higher cost than the lock-in it is usually adopted to avoid.
Non-Functional Acceptance
Treating quality-attribute targets as acceptance criteria with automated verification, so a release can fail on latency the way it fails on a broken feature.
Query Plan
The database's chosen strategy for executing a query, and the first thing to look at when one is slow.
Recovery Point Objective
The maximum acceptable data loss measured as a duration, determining the replication and backup strategy.
Resource Requests and Limits
The declared minimum a container is guaranteed (request) and the maximum it may consume (limit) — the two numbers that determine scheduling, packing and throttling.
Six Rs of Migration
The standard menu of options for each application in a migration — rehost, replatform, refactor, repurchase, retire, retain.
Slowly Changing Dimension
A strategy for handling attributes that change over time, deciding whether history is preserved and how facts attach to the correct version.
Testability as a Design Property
How cheaply a system's behaviour can be observed and controlled, which is decided by architecture and largely fixed before any test is written.
Time to Market
How long it takes to get a capability in front of customers — often the constraint that dominates every other architectural quality.
Twitter's Timeline Fan-Out
Twitter precomputes each user's timeline at write time but handles very-high-follower accounts at read time, because neither strategy alone survives both ends of the distribution.
A platform of 40 services has logs only, and incidents take hours to diagnose. Design the observability strategy and its rollout order.
Why logs alone fail at this size Logs answer "what happened in this service". They cannot answer "where did this request spend its time across twelve services",
An executive says "we need an AI strategy" and asks you to come back in two weeks. How do you handle the ambiguity?
Do not go away and produce a strategy document A document answering a question nobody has articulated will be received politely and shelved. The brief is ambigu
A new platform must serve a public partner API, three internal front-ends with different data needs, and high-volume service-to-service traffic. Choose the API styles and defend the choice.
Resist "pick one" These are three different problems with three different consumers. Standardising on one style optimises for architectural tidiness at the expe
An end-to-end suite of 340 tests takes four hours and fails spuriously about half the time. The team wants to parallelise it. Is that the right move?
Parallelising treats the symptom It might halve the runtime. It will not touch the flakiness — in fact parallelisation often worsens it, by exposing shared stat
Leadership wants to consolidate a warehouse, a data lake and three departmental marts into a lakehouse. How do you scope and sequence this?
Establish the actual driver "Consolidate onto a lakehouse" is a solution. The driver is usually one of: cost of maintaining several copies, inconsistency betwee
Six teams share one integration test environment. Bookings are made a week ahead and releases slip when someone overruns. How do you fix it?
Name the cost first The queue is not an inconvenience; it is lead time. Measure it: for the last twenty changes, how many days elapsed between "ready to test" a
Container Image Strategy
Base images, layer hygiene, rebuild cadence, and patching a fleet of images.
Environment Strategy
How many environments earn their cost, what each proves, and what none of them prove.
Mobile Release Strategy
Store review, staged rollout, and supporting versions you can never force off.
Non-Functional Test Strategy
Testing availability, latency, security and recovery rather than only behaviour.
Test Architecture Strategy
Choosing what to verify where, given the failure modes that actually occur.
UI Monorepo Strategy
One repository for many front ends, and the build graph that makes it viable.
C4 Model
Context, container, component and code as four separate diagrams.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
Testing & Quality Architecture
General material on designing a testing strategy as an architectural concern.