Search
7 results for “module”
Search results
Auto-Scaling Azure VMSS with Modular Terraform
From Basic Terraform to Production IaC: Building an Auto-Scaling Azure Web App with Modular Terraform.
Why is scanning IaC source (Terraform files) not sufficient on its own, without also checking the plan?
Static scanning can catch hardcoded insecure defaults but cannot see the complete result of runtime inputs, data sources, and module composition. A Terraform plan is the best prediction of the concrete resource changes Terraform is about to make, so plan policy sees substantially more than source scanning. It is not guaranteed to know every value before apply, however; security-sensitive unknown values need an explicit fail-closed or exception rule rather than being assumed safe.
Azure Monitor Alerts, Action Groups, and Processing Rules
Set up Azure Monitor alerts, action groups, and alert processing rules step by step, so critical changes like a VM deletion never go unnoticed.
How do management groups extend governance above the subscription level?
Management groups let an organization apply policies (via Azure Policy) and role assignments (via Azure RBAC) across multiple subscriptions at once, instead of configuring each subscription independently. They form a hierarchy above subscriptions, a root management group can contain child management groups (e.g., by department or environment type), each containing multiple subscriptions, so a single policy assignment at the right level of that hierarchy can enforce a rule (like "no public IP addresses" or "must use approved regions") across every subscription beneath it.
Why would an organization use multiple AWS accounts instead of one account holding all resources?
Separate accounts per environment (production, staging, development) or per team give a hard isolation boundary that a single account with tags or naming conventions cannot: a mistake or compromised credential in a development account cannot reach production resources at all, rather than merely being restricted by IAM policy within the same account. It also gives cleaner cost attribution (billing rolls up per account), independent service quotas, and a natural blast-radius limit for security incidents. AWS Organizations, and patterns built on top of it like a landing zone, exist specifically to make many accounts manageable, centralized billing, centralized logging, and org-wide SCPs, without losing that isolation.
Why does GitOps improve auditability compared to engineers running kubectl or terraform apply directly?
Every change to cluster state has to go through a Git commit, which means it inherits Git's existing history, authorship, and (if branch protection is configured) pull-request review, automatically. Direct `kubectl apply` access leaves no equivalent trail: two changes with the same effect are indistinguishable, there's no required review step, and reconstructing "who changed what and why" after an incident means digging through cluster event logs instead of reading a linear, reviewed commit history.
What problem does policy-as-code solve that a manual infrastructure change review does not?
A manual review depends on a human noticing a specific misconfiguration, an open security group, an unencrypted storage bucket, in a plan diff that may span hundreds of resources, and that scrutiny has to be repeated consistently by every reviewer on every change. Policy-as-code encodes the same rule once as executable logic and runs it automatically against every plan, so an overly permissive security group is caught the same way on the hundredth change as the first, without depending on which reviewer happened to be paying attention that day.