Automating a no-public-IP governance rule
preventive policy-as-code governance.
use organization-level policy guardrails (SCP, Azure Policy, Org Policy) to deny public IP attachment before creation, applied across all accounts.
What's really being asked
The interviewer wants to see that you reach for preventive, centrally enforced policy-as-code rather than relying on humans to notice and undo violations, and that you apply it organization-wide.
The full answer
The strongest control is preventive: stop the public IP from ever being attached. Each major cloud has a native mechanism. AWS uses Service Control Policies in Organizations to deny the relevant actions across every member account; you can deny running an instance that associates a public IP. Azure uses Azure Policy with a deny effect targeting the public IP resource or the NIC property, scoped at a management group so it cascades to all subscriptions. GCP uses Organization Policy constraints, such as the constraint that restricts external IPs on VM instances, applied at the org node. Applying the policy at the highest scope means new accounts and subscriptions inherit it automatically, so coverage does not depend on per-team discipline. Because preventive policies can have gaps or exceptions, pair them with detective controls: a continuous compliance scanner like AWS Config rules or Azure Policy audit effect flags any noncompliant resource, and an automated remediation can detach the IP or alert. Defining all of this as code in your infrastructure pipeline makes it reviewable, versioned, and consistently deployed.
The mistakes people make
Relying solely on a detective scan and manual cleanup, which leaves a window where the VM is publicly exposed. Enforcing the rule per-account by hand, which drifts as accounts grow. Using IAM permissions alone, which is harder to express as a resource-shape rule.
What usually comes next
What is the difference between a preventive and detective control? How do you handle legitimate exceptions? How does the policy inherit to new accounts?
A concrete example
An SCP attached to the organization root denies ec2:RunInstances when the request associates a public IP, so any team in any account is blocked at creation time, while an AWS Config rule audits for drift as a second layer.
Interview question
Which approach best guarantees no new VM is ever launched with a public IP across all accounts?
- a.Granting each team admin rights and trusting them to comply
- b.A nightly script that scans for and detaches public IPs after the fact
- c.An email reminder asking teams not to attach public IPs
- d.An organization-level deny policy that blocks the attachment at creation timeCorrect
Why? this is the answer
A preventive org-level deny policy stops the violation before the resource is created and inherits to all accounts. A nightly scan is detective and leaves an exposure window before remediation.
Just read this? Test yourself on what you have been reading.
Read the original → docs.cloud.google.com
- #governance
- #policy-as-code
- #security
- #compliance
- #cloud
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on governance — each one lists the topics its interview covers.
See open roles