An organization must demonstrate to external auditors that all automated changes made by their GitHub agent comply with their change management policy. The auditors require evidence that every automated change was authorized, executed within approved parameters, and reviewed. Which combination of architectural planning decisions best supports this audit requirement?
Select an answer to reveal the explanation.
Short Explanation
You need a paper trail with three links: what the agent planned, what authority it acted under, and what it actually did. Build that traceability into the architecture from day one with structured artifacts, commit references, and immutable storage. That's the approach that holds up under scrutiny.
Full Explanation
Compliance audits for automated change management require evidence of three things: authorization (who approved this change and under what policy), execution (what the agent did, when, and how), and review (that a human validated the outcome). The structured run artifacts approach is correct because it designs for this from the start with three architectural decisions.
First, the pre-execution plan artifact: before taking action, the agent writes a structured document that identifies the triggering authorization record (e.g., an issue number, a linked RFC, or an approval event), what it intends to do, and what constraints it is operating under. This is the 'authorized scope' document.
Second, structured commit attribution: every commit the agent makes includes metadata tying it to the authorization record (e.g., Refs: CHANGE-1234, Approved-by: JIRA-456, or equivalent). This links every code change to its authorization chain.
Third, a post-execution summary artifact: stored alongside the workflow run, this records what the agent actually did, any deviations from the plan, and links to the workflow run ID for cross-reference.
Storing these in an immutable audit log (e.g., a write-once S3 bucket with object lock, or an append-only logging service) prevents retroactive modification, which is required for SOC 2 and ISO 27001 audits.
The weekly email summary approach is incorrect because email summaries are not structured, not immutable, not linked to individual changes, and easily lost or misread.
The GitHub issue per change approach is incorrect because GitHub issues provide some traceability but are mutable (anyone can edit or delete them), lack structured format, and do not capture the detailed execution context auditors require.
The approach of requiring plain-text log files in the repository is incorrect because plain-text log files in the repository are mutable (a later commit can overwrite them) and do not carry the structured, cross-referenced metadata an audit requires.