30
Review questions
All questions have a recorded response, assessment and action.
Technical programme review · 27 July 2026
A consolidated write-up of the 30-question TPM review, combining the team’s stated position with programme assessment and concrete next actions.
Programme snapshot
30
All questions have a recorded response, assessment and action.
11
Clear ownership exists for cost, evidence and core controls.
8
Most relate to continuity, rehearsal, evidence and teardown.
11
These need dates, owners or explicit team agreement.
Programme principle
A technically working system is not sufficient. It must also be explainable, observable, financially controlled, recoverable and safely decommissioned.
Immediate focus
These actions provide the highest protection for marks and demonstration continuity. They should take priority over new dashboard features.
Publish team acceptance criteria and identify one accountable final approver.
Name a backup and complete a rehearsal without Bernard’s intervention.
Correct stale IDs, hashes, costs, alarm statements, SSH wording and footer status.
Time the live path, degraded modes, Q&A and operator handoffs.
Record the five-member decision on public report and deck access.
Inventory out-of-band resources and define teardown evidence before demo day.
Full record
Open a review area to see the individual decisions. Status indicates whether the direction is agreed, still open, or requires immediate attention.
Pass the exam.
This is a valid primary outcome, but it should be converted into a measurable target with a safety margin above the minimum passing mark.
To be determined during discussion with all team members.
Acceptance criteria are pending team agreement. Until written and owned, the team cannot objectively declare the project ready.
A controlled clean-rebuild rehearsal has been recommended.
Current evidence proves the system has worked, but independent repeatability is not yet demonstrated.
Any team member could do so because accounts have been created for everyone.
Account availability is necessary, but it does not prove permissions, knowledge or confidence. One named backup is required.
No.
The key-person mitigation is documented but untested. This remains a high delivery risk.
26 August 2026 at 6:30 PM SGT.
The deadline leaves enough time, but it should not be treated as the working deadline because individual presentations carry 30% of each member’s grade.
Yes.
This is positive, but readiness should be demonstrated through questions rather than self-declared.
26 August 2026 at 6:30 PM SGT.
This date should drive the final rebuild, evidence refresh, configuration freeze and readiness review.
Before the day of the demonstration on 26 August 2026.
The intent is correct, but it needs a precise start time and recovery window.
A three-level contingency approach has been recommended.
A dashboard failure must not become a project failure. Cloud consoles, tests and deployment records remain the authoritative evidence.
Mainly ping tests between each site; the rest is still to be determined.
Ping proves network reachability but not application operation, monitoring or repeatability.
Not yet.
Timing is an open readiness risk, especially because the dashboard contains a large volume of material.
The distinction between live sources and explanatory text was initially unclear.
When two values conflict, the team needs a documented rule for deciding which one is trusted.
Everyone.
Everyone can contribute to verification, but one person must be accountable for the final go/no-go decision.
For ease of presentation and to try a new way of presenting.
This is a strong rationale. The dashboard should make the presentation faster and clearer without amplifying outdated information.
Probably not; its purpose was questioned.
Automation is optional. The control exists to catch outdated identifiers, hashes, costs and contradictory status statements before the exam.
The project is still at an early stage and the decision has not been finalized.
The risk is already active because the shared report is publicly downloadable before submission.
Yes, so everyone can access it.
Convenient access for team members and assessors is different from unrestricted access by anyone online.
Yes.
Retaining them is reasonable as assessment evidence. They are not credentials, but exposure should be intentional and controlled.
A named backup-operator model has been recommended.
Accounts exist, but continuity is not proven until another member succeeds from their own laptop without Bernard’s credentials.
The fully deployed environment will be activated before demonstration day.
The dashboard’s figures describe different scopes. Azure is about $7.85/day; AWS list price is about $3.66/day; combined theoretical list price is about $11.51/day.
Bernard.
Ownership is clear. Approximately $0.44/day should be used as the current parked Azure estimate unless a fresh calculation supersedes it.
Bernard owns them.
The export documents two AWS budgets and one Azure budget. That is three, while the dashboard displays four.
Bernard owns the budgets. Teardown will occur once the demonstration has concluded.
The trigger is sensible, but completion should be formally confirmed and independently verified.
No limit has been set.
A cap creates a deliberate decision point if provisioning or troubleshooting runs longer than planned.
The assessors.
Assessors provide external acceptance, but they should not be the team’s first verification layer.
AWS resources.
The platform is identified, but teardown needs an exact inventory of out-of-band resources.
Log files.
Logs are suitable only if they prove successful authentication and post-deletion inspection, not merely that delete commands were issued.
Bernard.
Bernard can be the custodian, but the archive should not become another single point of failure.
Learning outcomes.
The strongest outcome is not merely a working network, but an explainable, observable, controlled, recoverable and safely decommissioned system.
Recommended control dates
Conclusion
EG334S has credible architecture, unusually strong evidence and disciplined cost awareness. The work now shifts from building to controlling: agree acceptance criteria, remove contradictions, rehearse a backup operator, prove the demonstration path and prepare verified closure.
The strongest final message is not that two tunnels were built. It is that the team can explain the design, demonstrate the service, respond to failure, control cost and remove everything safely.