The correct answer is B: Create an Amazon API Gateway HTTP API. Implement each webhook logic in a separate AWS Lambda function. Update the Git servers to call the API Gateway endpoint.

This solution best meets the requirements for a serverless architecture with the least operational overhead.

Why Option B?

• Fully serverless compute: Each webhook's logic runs in its own AWS Lambda function. Lambda is event-driven, automatically scales from zero to thousands of concurrent executions, and you pay only for actual compute time (no idle costs).
• Fully managed API layer: Amazon API Gateway HTTP API acts as the single, stable endpoint that the on-premises Git server calls (replacing the current ALB).
  • HTTP APIs are lightweight, cost-effective (cheaper than REST APIs), and optimized for Lambda integrations.
  • You can route different webhook paths/events (e.g., /webhook/push, /webhook/pull-request) to the appropriate Lambda function using simple route configurations.
  • API Gateway handles common webhook needs like request validation, throttling, CORS, logging, and basic security (e.g., API keys or IAM) with minimal setup.
• Minimal changes on the Git side: The Git server only needs to update its webhook URLs to point to one (or a few) API Gateway endpoints instead of the old ALB. No need to manage multiple individual URLs.
• Low operational overhead: No servers, no clusters, no container management, no Auto Scaling groups, and no load balancers to maintain. Everything scales and manages itself. Deployment is fast via infrastructure as code (e.g., AWS SAM or CDK).

This closely mirrors the current setup (one entry point calling multiple backend logics) but removes all operational burden.

Why Not the Other Options?

• Option A (Lambda Function URLs):

  • You would create a separate function URL for each webhook. This is simple and very low-cost/latency for basic cases, and function URLs are explicitly suitable for webhooks.
  • However, it requires the Git server to be updated with multiple distinct URLs (one per webhook). Managing, securing, and updating many long/random URLs adds operational friction on the on-premises side. Function URLs also offer fewer built-in features (limited auth, no easy routing, weaker DDoS protection, no usage plans). For production webhooks from an external Git server, API Gateway provides better manageability and security with similar serverless benefits.

• Option C (AWS App Runner + ALB):

  • App Runner is serverless for containers/web apps and has low overhead, but you still need to create and manage an ALB in front of it (plus potential container image handling). This is not fully serverless (you retain a load balancer) and introduces more components/management than pure Lambda + API Gateway. It also doesn't naturally split "each webhook logic" as cleanly.

• Option D (ECS Fargate + API Gateway REST API):

  • This uses containers on Fargate (serverless compute) but requires containerization, an ECS cluster, task definitions, and a full REST API in API Gateway. It adds significant operational overhead (orchestration, image management, scaling configuration) compared to pure Lambda. REST APIs are also heavier/more expensive than HTTP APIs for this use case.

Key Takeaways for the SAP-C02 Exam

• "Least operational overhead" in AWS usually points to Lambda + API Gateway (especially HTTP API) for event-driven/webhook-style workloads. It eliminates infrastructure management while providing a clean, single endpoint.
• Lambda function URLs are great for very simple or internal scenarios but are often not the best when you need routing, better security features, or a unified public endpoint.
• Prefer HTTP API over REST API for cost/performance when integrating directly with Lambda.
• For Git webhooks (e.g., GitHub, GitLab, or on-prem), the pattern is: Git server → API Gateway (stable URL) → Lambda (business logic). You can add Lambda authorizers or verify signatures (e.g., HMAC) inside the function if needed.

This approach gives you automatic scaling, high availability, pay-per-use pricing, and near-zero ops work—exactly what the question is testing. If you have the original webhook code, it's usually straightforward to port it into Lambda functions.