1) Tratar segurança como “configuração final”

Um dos erros mais comuns é habilitar recursos e só depois pensar em quem pode acessar.
No Azure, isso vira um problema de governança: permissões excessivas, ausência de trilhas e configurações inconsistentes entre ambientes.

• Conceder acesso “de qualquer jeito”: preferir escopo correto (recurso vs. resource group vs. subscription).
• Não auditar: sem logs e sem alertas, você só descobre incidente tarde.
• Esquecer ambientes: permissões e segredos misturados entre dev/homolog/produção.
• Ignorar “allow lists” em integrações e acessos externos.

2) Ignorar custos e dimensionamento desde o início

Outro erro recorrente é deixar custos “para depois”. Acontece que muitos serviços no Azure têm comportamentos
que mudam o valor final: auto-scaling mal configurado, SKUs inadequadas, retenção de logs e
dependência de dados em movimento.

• Manter serviços ligados o tempo todo (ex.: VMs e ambientes de teste sem política de desligamento).
• Logs/diagnósticos sem retenção planejada: o volume cresce rápido e vira custo permanente.
• Rede e dados: tráfego entre regiões e egress podem dominar o orçamento.
• Escolha de SKU sem baseline: “subir mais” para resolver problema vira desperdício quando o ajuste é rede/consumo.

3) Subestimar rede: conectividade, IPs e isolamento

Rede é onde muitos sistemas “não fecham”. O problema costuma começar como um ajuste simples e termina em
regras de firewall complexas, rotas inesperadas ou falhas intermitentes.

• Expor endpoints sem necessidade: abrir tudo “para funcionar” antes de restringir.
• Ignorar DNS e resolução: integrar serviços sem planejar nomes, zonas e dependências.
• Falhar no modelo de sub-redes: misturar sub-redes com finalidades diferentes (ex.: app vs. private endpoints).
• Não validar portas/fluxos com antecedência: ambientes diferem e o teste vira correção.
• Não considerar latência e throughput: especialmente em serviços distribuídos.

4) Deployment frágil e diagnóstico insuficiente

O último erro é o mais caro no longo prazo: quando o deploy funciona “hoje”, mas não entrega rastreabilidade
(logs, métricas e correlação) para investigar falhas amanhã.

• Não padronizar variáveis por ambiente (URLs, chaves, permissões e flags) e depender de ajustes manuais.
• Ausência de correlação entre logs: você vê eventos soltos e não entende o fluxo completo.
• Não definir SLOs/alertas: o sistema degrada sem ninguém perceber até virar incidente.
• Ignorar limites (timeouts, retry, rate limit): falhas viram loops e multiplicam carga.

Abaixo vai um exemplo de configuração de diagnóstico e telemetria de forma prática:
garanta que logs sejam enviados para um destino consistente e que você consiga filtrar por recurso e operação.

<!-- Exemplo conceitual (Azure Monitor / Log Analytics) -->
<!-- Objetivo: centralizar diagnósticos para consultar por ResourceId e operação -->

resource "azurerm_monitor_diagnostic_setting" "example" {
  name                       = "diag-app"
  target_resource_id        = azurerm_app_service.app.id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id

  enabled_log {
    category = "AppServiceHTTPLogs"
  }

  enabled_log {
    category = "AppServiceConsoleLogs"
  }

  enabled_log {
    category = "AppServiceAuditLogs"
  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }

  retention_policy {
    enabled = true
    days    = 30
  }
}