Municipal engineering wants consistent secure coding across teams building internal services. What should leadership adopt?
Select an answer to reveal the explanation.
Short Explanation
Good secure coding is a team sport with a playbook. Publish standards and peer-review checklists so city developers catch the same classes of mistakes. Consistency beats heroic last-minute saves.
Full Explanation
Consistent secure coding across municipal engineering teams requires adopted secure coding standards and peer-review checklists. Standards define prohibited patterns (unsafe APIs, string-built queries, hard-coded secrets), required controls (parameterization, output encoding, least-privilege defaults), and language-specific guidance. Peer-review checklists operationalize those standards on every meaningful change so knowledge is not trapped in a few experts. Together they create repeatable quality for internal services that may later face integration or exposure pressures.
Ad-hoc style preferences unique to each developer with no review produce inconsistent vulnerability density and no shared baseline for audits.
A ban on all code comments to reduce repository size harms maintainability and does nothing to enforce security properties; size savings are trivial compared to defect cost.
Promoting unsigned binary drops as the primary quality gate ignores source review, tests, and provenance; unsigned drops weaken integrity assurance.
Exam caveat: administrative/process controls—standards plus peer review—are first-class Domain 8 answers alongside tooling. Operational check: publish standards in the engineering handbook, require checklist completion on pull requests for municipal services, train new hires, periodically measure common finding types, and update standards when new frameworks enter the city's stack.