Rpo Rto Confusion — Azure DevOps Engineer (AZ-400)

Whether to wire GitHub PR events to Teams via custom incoming webhooks—satisfying notification latency but leaving the audit-completeness and work item traceability requirements unmet—or to use the first-party Azure Boards GitHub App plus the Azure Boards app for Microsoft Teams, which satisfies both notification latency and zero-gap traceability as a managed unit.

Whether to adopt trunk-based development with short-lived feature branches and strict branch policies on main — where the RTO of integration failure is minimised by small, frequently merged changesets — or a GitFlow model with long-lived release and hotfix branches that appears to improve release isolation (an RPO-like constraint) but accumulates merge debt and slows the team's ability to detect and roll back a bad commit at the stated deployment frequency.

Whether to adopt trunk-based development with short-lived feature branches enforced via Azure Repos branch policies (minimum reviewer count + build validation pipeline) or GitFlow with long-lived release and hotfix branches, given a small team deploying at continuous-delivery cadence where long-lived branches accumulate merge debt and degrade hotfix recovery speed.

Select the Azure Pipelines deployment topology—among backup-restore, pilot light, warm standby, and active-active patterns—that satisfies BOTH the stated RPO ≤ 15 min and RTO ≤ 60 min targets; warm standby (pipeline deploys to secondary on every run, secondary runs at minimum scale) satisfies both, while a post-deploy backup stage satisfies RPO but fails RTO because restoration duration exceeds 60 minutes.

Whether blue-green deployment alone satisfies both the zero-downtime RTO requirement and the zero-data-loss RPO requirement on rollback, or whether an expand-contract database migration pattern gated by feature flags is also required to satisfy the RPO constraint independently of traffic switching.

Whether the selected guest OS configuration mechanism independently satisfies both the RPO (maximum undetected drift window) and the RTO (maximum time to return to desired state after detection), given that a DSC pull interval can match the RPO number while the pull-server remediation execution model structurally cannot meet the separate RTO target.

Whether the proposed integration closes the full traceability chain through build-artifact tagging and deployment-event annotation (zero traceability-gap requirement met) or only establishes commit-to-work-item references (partial chain that satisfies fast lookup but leaves the build-to-deployment segment unlinked and fails the audit).

Select Git LFS (binary blob offload) over Scalar (sparse-checkout and commit-graph acceleration for large trees) when measured clone latency is caused by large binary file sizes rather than deep commit history or wide directory trees — the bottleneck type must be matched to the tool's optimization target before a solution is chosen.

Distinguish between retention duration (preventing deletion after a time window, analogous to RTO recovery capability) and version immutability (preventing overwrite of a published version, analogous to RPO write-protection); only immutable publishing satisfies the bit-for-bit identical audit constraint because retention policies cannot block a version from being overwritten before any deletion window is evaluated.