Network firewall-style rules the city configures on Amazon EC2 security groups for a permitting system are under whose responsibility?
Select an answer to reveal the explanation.
Short Explanation
AWS hands you the lock kit; you still pick which keys open which doors. Security groups are customer-configured controls, so the city owns those allow/deny choices. Having an AWS logo on the feature does not make AWS the author of your rules.
Full Explanation
Customer-configured Amazon EC2 security group rules for a permitting system are a customer responsibility. Security groups are AWS-provided building blocks, but the allow and deny decisions — which ports, which sources, which associations — are chosen and maintained by the city. Branding alone does not move authorship of those rules to AWS. Amazon GuardDuty detects potentially malicious or unauthorized behavior; it does not author and own every security group rule automatically. AWS Support is not a mandatory approver for each inbound port change in normal operations. Conceptually, AWS supplies the lock kit; the municipality still decides which keys open which doors for the permitting workload. Distractors fail by equating "AWS feature" with "AWS-operated rule set," by confusing threat detection with firewall rule ownership, and by inventing a Support gate for routine network ACL-style changes at the instance level. Exam caveat: distinguish platform capability from configuration accountability — many CLF items hinge on that distinction. Operational check: review security group rules for the permitting tiers, ensure least privilege on ingress, track changes in change management, and confirm that monitoring alerts on overly open groups rather than assuming AWS rewrote the rules for you.