Engenharia de prompts para Infraestrutura como Código
Dica
Consulte a guia Texto e imagens para obter mais detalhes!
GitHub Copilot é tão útil quanto as instruções fornecidas. Para tarefas de infraestrutura, um prompt vago produz um modelo genérico que pode não corresponder às convenções de nomenclatura, aos padrões de segurança ou aos padrões de arquitetura. Um prompt bem elaborado produz uma saída quase pronta para produção.
Isso não é uma pequena diferença. Um prompt como create a Bicep template for a Rede Virtual pode produzir um exemplo mínimo sem sub-redes, sem marcas e uma região codificada. Um prompt como o que você escreverá ao final desta unidade pode produzir uma Rede Virtual totalmente parametrizada, etiquetada e com múltiplas sub-redes, com associações NSG e configurações de diagnóstico. Estruturado corretamente e pronto para validar.
A habilidade de escrever bons prompts é aprendível. Esta unidade aborda as técnicas que consistentemente produzem melhores resultados de infraestrutura com o GitHub Copilot.
A anatomia de um prompt de IaC eficaz
Todo prompt de infraestrutura robusto contém alguma combinação dos quatro elementos:
Contexto
O contexto informa Copilot que tipo de trabalho você está fazendo e quais restrições se aplicam. Sem contexto, Copilot faz suposições. Essas suposições podem não corresponder ao seu ambiente.
Exemplo de prompt menos eficiente: "crie uma conta de armazenamento no Bicep."
Prompt otimizado: "crie uma definição de recurso Bicep para uma Conta de Armazenamento do Azure." Executando em um ambiente de produção na região Leste da Austrália. A conta deve usar Standard_LRS e exigir acesso somente HTTPS.".
O contexto inclui o ambiente de destino (desenvolvimento/preparo/produção), a região, a ferramenta ou o idioma, restrições existentes (convenções de nomenclatura, políticas de marcação) e todos os padrões que você deseja seguir.
Requirements
Os requisitos são os recursos, propriedades ou comportamentos específicos que o recurso deve ter. Ser explícito sobre requisitos impede que Copilot omitissem coisas que não podem inferir.
Por exemplo:
The storage account must: have soft delete enabled for blobs (7 days), use a private endpoint, disable public blob access, and be tagged with Environment, Owner, and CostCenter.
Listar requisitos como pontos de marcador ou itens numerados quando você tiver vários. Copilot lida bem com listas estruturadas e é menos provável que ignore itens.
Formato da saída
Diga a Copilot que tipo de saída você espera. Para IaC, geralmente significa especificar o idioma ou a ferramenta, quer você queira um arquivo completo ou apenas um snippet e como os parâmetros devem ser tratados.
Por exemplo:
Output a complete Bicep file with parameters at the top, a resource block in the middle, and outputs at the bottom. Use decorators to add descriptions to all parameters.
Se você não especificar um formato, Copilot escolherá um. Pode escolher valores fixos embutidos quando você desejava parâmetros, ou um trecho quando você desejava um arquivo completo.
Constraints
As restrições indicam ao Copilot o que evitar. Fácil de ignorar, mas importante, especialmente para segurança ou conformidade.
Por exemplo:
Do not use any deprecated API versions. Do not expose any management ports (22, 3389) in NSG rules. Do not hardcode any subscription IDs or tenant IDs.
Prompt zero-shot
Prompt zero-shot significa que você descreve o que deseja sem fornecer exemplos. É a abordagem mais comum e funciona bem para padrões de infraestrutura padrão, com base nos dados treinados do Copilot.
Por exemplo:
Generate a Bicep template for an Azure Key Vault with the following requirements:
- SKU: Standard
- Soft delete enabled with a 90-day retention period
- Purge protection enabled
- RBAC authorization model (not access policies)
- Public network access disabled
- A private endpoint connected to a subnet parameter
- Tags: Environment, Owner, CostCenter (all as parameters)
Use descriptive parameter names and add @description() decorators to each.
O método zero-shot é mais eficaz quando o tipo de recurso é comum e seus requisitos são específicos. Se você estiver trabalhando com um tipo de recurso menos comum ou se precisar de uma estrutura específica, considere fornecer um exemplo.
Prompt few-shot
Prompt few-shot significa que você fornece um ou mais exemplos em seu prompt para que o Copilot entenda o padrão ou estilo desejado. Útil quando você tem uma base de código existente com convenções das quais o Copilot não saberia de outra forma.
Um exemplo de prompt few-shot poderia ser assim:
Here is an example of how we define storage accounts in our Bicep codebase:
[paste your existing storage account resource block]
Using the same naming convention, parameter style, and tag structure, generate
a similar resource block for an Azure Service Bus namespace with these requirements:
- Standard SKU
- Geo-redundant disaster recovery enabled
- Minimum TLS 1.2
- Same tagging pattern as the example
Ao mostrar Copilot seu padrão existente, você obtém uma saída que se mistura à base de código em vez da saída que segue o estilo padrão do Copilot. Economizando tempo de limpeza significativo ao integrar o código gerado com modelos existentes.
Prompt baseado em função
O prompt baseado em função pede ao Copilot que adote uma perspectiva específica antes de gerar a saída. Ele é eficaz para revisões de segurança e diretrizes arquitetônicas.
Um exemplo no contexto de segurança pode ter esta aparência:
You are a senior Azure security engineer reviewing Bicep templates for enterprise
production deployments. Review the following template and identify:
- Any security misconfigurations or missing security controls
- Resources that expose public endpoints unnecessarily
- Missing diagnostic settings or logging configuration
- RBAC assignments that are too broad
- Any deprecated API versions
For each issue found, explain the risk and provide the corrected Bicep snippet.
O prompt baseado em função muda a saída do Copilot de "aqui está um código que funciona" para "aqui está um código que funciona, é seguro e segue o princípio do menor privilégio". A diferença de qualidade é perceptível.
Refinamento iterativo
A maneira mais eficaz de trabalhar com GitHub Copilot em tarefas de Infraestrutura como Código não é escrever um prompt perfeito. É preciso começar com uma abordagem ampla e refinar progressivamente.
Um processo de criação de exemplo percorreria os seguintes estágios:
Etapa 1: começar com o recurso principal
Generate a Bicep template for a hub-spoke VNet topology with one hub and one spoke.
Revise o resultado. A estrutura básica está correta? Os espaços de endereço são sensatos?
Etapa 2: Adicionar requisitos de segurança
Add an NSG to the application subnet in the spoke that blocks all inbound
internet traffic except HTTPS (port 443). Add a deny-all rule at the end.
Etapa 3: Adicionar observabilidade
Add diagnostic settings to the NSG that send flow logs to a Log Analytics
workspace. Add the Log Analytics workspace as a new parameter.
Etapa 4: Adicionar parametrização
Replace all hardcoded values (address spaces, location, resource names)
with parameters. Add @description() and @allowed() decorators where appropriate.
Etapa 5: Adicionar tags
Add tag parameters for Environment, Owner, and CostCenter. Apply tags to
every resource in the template using a tags object parameter.
Essa abordagem de cinco etapas produz consistentemente uma saída melhor do que um único prompt complexo, pois cada etapa baseia-se na saída validada da anterior. Você analisa e aceita cada incremento antes de adicionar a próxima camada de requisitos.
Erros comuns de solicitação
Sendo muito vago
Problem: usando um prompt como Create a Bicep template for my infrastructure
Resultado: Um modelo mínimo com valores adivinhados, tipos de recurso incorretos e nenhuma configuração de segurança.
Corrigir: Seja específico sobre quais recursos você precisa, quais SKUs, quais regiões e quais requisitos de segurança se aplicam.
Esquecendo restrições de segurança
Problema: Gerar um modelo de VM sem especificar que as portas de gerenciamento não devem ser abertas
Resultado: Um NSG que permite SSH e RDP de entrada da Internet. Que é uma configuração incorreta de segurança crítica
Corrigir: Declarar explicitamente os requisitos de segurança como parte de cada prompt de infraestrutura. Não assuma que o Copilot usa o modo seguro por padrão.
Não especificando preferências de versão da API
Problem: usando um prompt como Use the latest API version
Result: Sem MCP, Copilot ainda pode usar versões de seus dados de treinamento, que podem estar desatualizados.
Fix: Habilitar o servidor MCP Bicep ou declarar explicitamente a versão da API, se conhecida. No mínimo, peça ao Copilot para sinalizar se houver incerteza sobre a versão da API.
Pedindo demais em um prompt
Problem: um prompt de 20 linhas solicitando uma zona de aterrissagem completa do Azure, com rede, identidade, governança e monitoramento. Tudo de uma vez.
Resultado: um modelo extenso com muitas lacunas, referências cruzadas de recursos ausentes e propriedades que o Copilot inferiu.
Corrigir: Use o refinamento iterativo. Crie o modelo em camadas e valide cada camada antes de adicionar a próxima.
Não fornecer contexto para bases de código existentes
Problema: solicitar ao Copilot que add a subnet to the Rede Virtual sem compartilhar a definição de recurso de Rede Virtual existente.
Resultado: Um novo recurso de sub-rede que pode entrar em conflito com a estrutura ou a nomenclatura da definição existente.
Corrigir: Sempre cole o código existente relevante no prompt quando você estiver estendendo ou modificando modelos existentes.
Padrões de prompt para infraestrutura
Os padrões a seguir são diretamente aplicáveis às tarefas neste módulo.
Padrão de geração
Use ao começar do zero:
Generate a [tool: Bicep/CLI/YAML] [resource type] with the following requirements:
- [requirement 1]
- [requirement 2]
- [requirement 3]
Parameterize: [list of values to parameterize]
Tag every resource with: [tag names]
Do not: [constraints]
Padrão de extensão
Use ao adicionar a um modelo existente:
Given this existing [tool] [resource definition]:
[paste existing code]
Add the following:
- [addition 1]
- [addition 2]
Maintain the existing naming convention and parameter style.
Padrão de revisão
Use ao auditar um modelo existente:
Review this [tool] template for:
- Security misconfigurations
- Missing required properties
- Deprecated API versions
- Resources exposed to the public internet unnecessarily
- Missing tags or diagnostic settings
For each issue, explain the problem and provide the corrected snippet.
[paste template]
Padrão de tradução
Use ao fazer a conversão entre ferramentas:
Translate this [source tool] [script/template/pipeline] to [target tool].
Preserve:
- The same variable/parameter names where possible
- Error handling logic
- The same resource naming and tagging
Do not add features that are not in the original.
[paste source code]
Padrão de explicação
Use quando precisar entender a infraestrutura existente:
Explain what this [tool] template deploys in plain language.
Describe each resource, its purpose, and how the resources relate to each other.
Identify any security controls that are configured.
Highlight anything that looks unusual or that might cause problems in production.
[paste template]
A mentalidade de revisão
GitHub Copilot é um colaborador, não uma autoridade. Todas as saídas produzidas devem ser revisadas antes de usar. Especialmente para a infraestrutura, em que uma configuração incorreta pode expor sistemas à Internet, bloqueá-lo de recursos ou incorrer em custos inesperados.
As perguntas a serem feitas ao revisar a saída de infraestrutura do Copilot:
- A versão da API é atual? Verifique a documentação do Azure ou use Bicep MCP.
- Todas as propriedades necessárias estão presentes? Rode
az bicep buildpara capturar campos obrigatórios ausentes. - Os padrões de segurança são apropriados? Verifique o acesso à rede pública, a exposição à porta de gerenciamento e as configurações de criptografia.
- Os recursos são referenciados corretamente? Verifique se nomes simbólicos, não IDs codificadas, são usados para referências de recurso.
- É idempotente? Executar esse modelo duas vezes criaria conflitos ou duplicatas?
Tratar a saída de Copilot como um primeiro rascunho, não uma resposta final, é a mentalidade que produz os melhores resultados.
Principais conclusões
- Os prompts de IaC efetivos incluem contexto, requisitos, formato de saída e restrições.
- A solicitação sem exemplos funciona para tipos de recursos comuns; a solicitação com poucos exemplos funciona melhor quando você tem padrões de código existentes para corresponder.
- A solicitação baseada em função ("Você é um engenheiro de segurança sênior do Azure...") melhora a qualidade das revisões e da orientação arquitetônica.
- O refinamento iterativo, através da construção em camadas, produz uma saída melhor do que um prompt único e grande.
- Sempre examine a saída do Copilot antes de usá-la: verifique as versões da API, as propriedades necessárias, as configurações de segurança e as referências de recurso.