The VM-Series integration with Amazon GuardDuty feeds malicious IP addresses to the VM- Series NGFW using XML API to populate a Dynamic Address Group within a Security policy that blocks traffic…

Question

Options

• ASNS
• BSQS
• CCodeDeploy
• DLambda

• A
  7% (5)
• B
  3% (2)
• C
  13% (9)
• D
  77% (53)

Explanation

Lambda (D) orchestrates the integration because it acts as the serverless "glue" between GuardDuty's threat findings and the VM-Series NGFW - when GuardDuty detects a malicious IP, an event triggers a Lambda function that calls the Palo Alto XML API to push that IP into a Dynamic Address Group, automatically enforcing the block policy without manual intervention.

SNS (A) is a pub/sub notification service that could notify about GuardDuty findings, but it cannot execute logic or make API calls to the firewall on its own. SQS (B) is a message queue that could buffer GuardDuty events, but again lacks the ability to process events and call external APIs - it needs a compute layer like Lambda to consume and act on messages. CodeDeploy (C) is a deployment automation service for releasing software, which is entirely unrelated to real-time threat response workflows.

Memory tip: Think of Lambda as the "action taker" - GuardDuty sees the threat, Lambda acts on it. In AWS security automation, whenever you see "something detects → something reacts via API call," Lambda is almost always the bridge.

No community discussion yet for this question.