Introduction
I changed a vehicle patrol dashboard’s deployment configuration, registry integration, startup dependency declaration, and deployment-role trust policy. The problems spanned production settings, network access, application startup, and workflow authentication. During the work, I observed two concrete responses: HTTP 200 from a production registry lookup after configuration was added, and 401 from a later API redeploy when no login token was sent. Neither response proves that every deployment issue was resolved.
Before the configuration change, the registry Lambda threw errors because NZSCV_URL, NZSCV_IDENTIFIER, and NZSCV_AUTH_KEY were empty in production. An outdated build was also rejecting requests while not checking the required token. Separately, a missing class-validator dependency caused a startup failure associated with 502 responses.
I also changed the API to call the registry directly and updated the OIDC trust policy. I haven’t verified an authenticated production lookup through the migrated path or a successful deployment using the revised policy. Those checks remain separate from the responses I observed.
The Rule That Shipped
The registry Lambda must have NZSCV_URL, NZSCV_IDENTIFIER, and NZSCV_AUTH_KEY set. The recorded network requirement also says the Lambda must belong to the registry’s network configuration to pass its NAT allowlist. I made that network-membership change, but membership alone does not prove that the Lambda uses an accepted public egress address. The available evidence does not identify its VPC attachment details, subnet route through a NAT gateway, or public egress address accepted by the registry. I can’t treat network membership as sufficient proof of allowlisted egress.
I changed the vehicle patrol API to call the registry directly instead of proxying through the existing administrative API. The direct call uses the existing lookup logic with authorization headers attached. That is the implemented integration, not a verified authenticated result from the migrated production path.
After the missing-package startup failure, I added class-validator as an explicit bundle dependency. For deployment authentication, I updated the IAM trust policy to accept both the existing repository-based OIDC subject format and a new organization-ID-based format. The exact subject-condition string is unavailable, so I can’t reproduce the literal match rule or assess its complete access scope.
Worked Example
The test input was a production lookup for [plate redacted]. That label redacts the recorded vehicle registration; it is not a replacement test input. NZSCV_URL, NZSCV_IDENTIFIER, and NZSCV_AUTH_KEY had been added to the production Lambda’s configuration.
Before those settings were populated, the Lambda encountered errors because its registry configuration was blank. After I added them, the production Lambda reached the registry for the recorded plate and returned HTTP 200. This is the supported input-and-response pair. It shows that the request reached the registry successfully under the tested conditions. It does not establish that every returned vehicle field was correct, that other registrations were covered, or that repeated requests would be reliable.
The network-membership and direct-call changes are also recorded. The successful response does not, however, prove that the later migrated path worked. The available record explicitly leaves an authenticated lookup through that path pending the new build going live.
A later redeploy returned 401 when no login token was sent. I treat that response as evidence that the API was running and enforcing authentication for that request. It did not exercise the protected registry operation, so it cannot replace the missing authenticated lookup.
Challenges and Tradeoffs
The direct-call change puts the registry request in the vehicle patrol API instead of keeping the administrative API as an intermediary. Looking back at the design, retaining the intermediary would preserve that boundary; calling directly removes an intermediary from the request path. The evidence establishes the change, but not a measured latency benefit, a particular motivation for choosing it, or reduced credential synchronization. The direct caller still needs the registry configuration and authorization headers.
The startup repair has a similar limit. I added class-validator explicitly after a missing-module startup failure, but why it was absent from the deployed artifact remains unknown. The evidence does not establish decorator-based dependency discovery, tree-shaking, or any other bundler mechanism as the cause. Declaring the dependency addresses the recorded omission. It does not universally guarantee that a packaging process will include it. Inspecting the artifact would provide different evidence from observing a running endpoint.
For OIDC, accepting two subject formats expresses compatibility intent, not a security ranking. A separate role is another possible arrangement, but it is not inherently safer than one role with two matching conditions. Without the literal subject conditions and role permissions, I can’t determine whether the revised policy is appropriately narrow or compare the alternatives’ effective access.
Verification Process
I keep configuration changes, runtime observations, and unresolved end-to-end checks separate. The record establishes that I added the three registry environment variables, changed network membership, implemented the direct registry call with authorization headers, added class-validator explicitly, and revised OIDC subject matching. Each is a recorded change, not interchangeable proof that the system works.
For runtime behavior, the production lookup for [plate redacted] returned HTTP 200 after the environment variables were added. Following the dependency change and a later redeploy, a request without a login token returned 401. That response supports recovery from the earlier startup failure and confirms authentication enforcement for the tested request. It does not explain the original packaging omission or validate authenticated business behavior.
I also configured GitHub Actions workflows to trigger on changes within the relevant API or UI directories. I haven’t separately confirmed that those path filters behave as intended on real pushes. A meaningful check would distinguish an in-scope directory change from an out-of-scope change; the configuration alone demonstrates neither outcome.
Three end-to-end results remain unconfirmed: successful role assumption and deployment after the OIDC policy update, a correct authenticated production lookup through the migrated direct-call path, and reliable workflow triggering only for changes within the intended directories. Network verification has another gap: the NAT route and accepted public egress address are not established. A successful status at one layer does not close these checks at another.
Conclusion
I changed registry configuration and network membership, direct-call integration, dependency declaration, and OIDC trust matching. The observed results are narrower: one production registry lookup returned HTTP 200, and a later unauthenticated API request returned 401.
I haven’t confirmed the migrated authenticated lookup, a subsequent successful OIDC deployment, or path-scoped workflow behavior. The precise NAT egress configuration, original package-omission mechanism, and literal OIDC subject condition also remain unavailable. The result is a clear record of what changed, what responded, and what still needs checking—not proof of the entire deployment path.