Blocking a Suspicious Source IP to a SageMaker Domain with a Subnet Network ACL Rule
A company runs an Amazon SageMaker domain in a public subnet of a newly created VPC. The network is configured properly, and ML engineers can access the SageMaker domain. Recently, the company discovered suspicious traffic to the domain from a specific IP address. The company needs to block traffic from the specific IP address. Which update to the network configuration will meet this requirement?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Security groups only support allow rules and have no deny, so they cannot block a specific source address. A network ACL is evaluated with an explicit deny rule and can be attached at the subnet level, which makes it the only option that can reject one IP.
A SageMaker domain runs in a public subnet of a properly configured VPC, engineers can reach it, and suspicious traffic from one specific IP address has been identified. The company needs to block traffic from that address, so the control has to be an explicit deny for a single source IP.
Creating a security group inbound rule to deny the address, which is impossible because security group rules are allow-only. Attempting to use a route table to deny inbound traffic also fails, since route tables govern route selection for outbound and return traffic, not inbound acceptance.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The requirement is to deny traffic from one specific IP address to the SageMaker domain, and the deciding constraint is that this needs to be a deny rather than an allow. Network ACLs are the VPC component that supports explicit deny rules evaluated in rule-number order, so an inbound deny rule for the offending address can be applied at the subnet where the domain lives, which blocks the traffic. The vote was unanimous at 100 for B. Certified101 identified the core fact that there is no deny in security groups, only allows, which is exactly why the NACL is the only viable answer, and Saransundar described it as subnet-level protection where specific IP addresses can be denied at the inbound connection level.Why the Other Options Are Wrong
Creating a security group inbound rule to deny traffic from the specific IP address (A) is not possible, because security group rules are allow-only and have no deny action, so the rule described in option A cannot be created at all. Creating a shadow variant and configuring Inference Recommender to send traffic from the address to the shadow endpoint (C) does not block anything; a shadow variant duplicates inference for testing and Inference Recommender analyzes instance types, so this option would use the suspicious address rather than exclude it. Creating a VPC route table to deny inbound traffic (D) misunderstands how route tables work, because a route table selects which route traffic takes and does not make an inbound accept or deny decision for traffic already arriving at the subnet.Community Comment Notes
The community was unanimous at 100 for B, and the two substance comments both focused on the same decisive technical fact. Certified101 stated that there is no deny in security groups, only allows, which eliminates option A outright and makes the network ACL the clear answer. Saransundar added the level distinction, identifying the network ACL as subnet-level protection where a specific source IP can be denied on inbound connections, which is precisely the granularity this question requires.Official Reference
Related Analysis
Practice All MLA-C01 Questions
Access 115 questions with complete answers and detailed explanations.
View Full MLA-C01 Practice Test →