Chapter 10 - Worked Answers

1. Eligibility precedes scoring

Node b already reserves fixed TCP port 31080. Atlas requests that same published port, so b is rejected before its larger remaining memory can win a score comparison. Node a is offline. Node c is ready and has sufficient CPU, memory and the requested port for atlas-01. After that assignment, c still has 600m and 128Mi available, but its fixed port is reserved. The second replica therefore remains unassigned. The executed teaching fixture asserts this result and permutation invariance without running containers.

2. Dynamic published ports

With the original unrelated reservation still present on b, a dynamic Atlas port can avoid 31080. Both b and c can now be eligible. For the first replica, b has more memory remaining after placement and wins that first score component. After reserving 128Mi there, b has 320Mi before the second placement, versus c with 256Mi; its post-placement remaining memory is still larger, so the second replica also prefers b when a distinct dynamic port is available. Do not assume dynamic ports imply spreading. The same-service and total-task tie-breakers only matter after remaining-memory equality. This is a reasoning answer; the chapter recorded the fixed-port fixture, not this modification.

3. Distinct rows do not serialize capacity

Each writer can successfully assign a different pending task using that task row’s valid optimistic token. Both may have read the same node resource budget and treated it as free. Winning both task claims does not atomically subtract from a shared reservation row. The Plan-local clusterState prevents conflicting selections within one invocation, but separate invocations do not share that temporary object. To claim global reservation correctness, test an atomic shared reservation or a deliberately serialized/revalidated allocation protocol under concurrent planners, including fixed-port collisions.

4. Two missing integration edges

First, ordinary MemoryService service creation makes assigned tasks directly, so Plan’s property assertions cannot prove every live deployment passed through its resource filters. Second, the agent’s ContainerSpec literal forwards command and volumes but omits Resources, even though the lower Engine adapter can translate resource fields into HostConfig. Planner accounting is not kernel enforcement. Trace both the placement path and the complete resource field path, then inspect the actual container’s limits under an owned daemon before making the operational claim. A passing pure function property test establishes neither edge.

These answers distinguish source reasoning from the scoped execution records linked in chapter 10. Proposed changes require separate implementation and validation.