Blocking a Suspicious Source IP to a SageMaker Domain with a Subnet Network ACL Rule

MLA-C01 By islever Editorial Last updated

Secure AWS resources.

Short answer

B Security groups have no deny, only allows, so a subnet network ACL with an inbound deny rule is the only option that blocks one source IP.

Question

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?
  1. Create a security group inbound rule to deny traffic from the specific IP address. Assign the security group to the domain.
  2. Create a network ACL inbound rule to deny traffic from the specific IP address. Assign the rule to the default network Ad for the subnet where the domain is located. Correct Answer
  3. Create a shadow variant for the domain. Configure SageMaker Inference Recommender to send traffic from the specific IP address to the shadow endpoint.
  4. Create a VPC route table to deny inbound traffic from the specific IP address. Assign the route table to the domain.

Key Takeaways

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.

Common mistake: 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.

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

https://docs.aws.amazon.com/vpc/latest/userguide/working-with-network-acls.html

This link opens the official vendor documentation in a new tab.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. Saransundar 👍 2 Answered B
    Protection at subnet level: Network ACL. Specific IP addresses can be denied at inbound connection level
  2. Certified101 👍 1 Answered B
    There is no deny in SG's - only allows- So NACL is the clear answer here
  3. GiorgioGss 👍 2 Answered B
    That's basic network topic.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Choosing LightGBM in SageMaker for Fraud Detection with Class Imbalance and Correlated Features

S-grade

Processing Mixed CSV JSON XLSX Parquet Files in One S3 Folder with DataBrew and Outputting Apache Parquet

S-grade

Rebuilding the Model Monitor Baseline After a Model Update Causes Data Quality Violations

S-grade

Orchestrating SageMaker ML Workflows as DAGs in Studio with ML Lineage Tracking for Governance

S-grade

Practice All MLA-C01 Questions

Access 115 questions with complete answers and detailed explanations.

View Full MLA-C01 Practice Test →

← Back to MLA-C01 Study Guide