Baseadas em fontes oficiais. Revisadas com cuidado.

Os modelos do Azure Resource Manager (ARM) usam sintaxe JSON declarativa para definir o estado desejado da sua infraestrutura. Os principais benefícios incluem: implantações repetíveis (o mesmo modelo produz ambientes idênticos todas as vezes), consistência entre dev/staging/prod, idempotência (reimplantar o mesmo modelo gera o mesmo resultado sem duplicar recursos) e orquestração integrada (o ARM resolve a ordem das dependências automaticamente). Os modelos não substituem as assinaturas — você ainda precisa de uma assinatura como destino da implantação. Um único modelo pode implantar dezenas de recursos ao mesmo tempo, não apenas um. A otimização de custos é território do Azure Advisor, não dos modelos ARM. Dica de prova: modelos ARM = infraestrutura como código declarativa, repetível, consistente e idempotente. Vale lembrar também que o Bicep é o sucessor recomendado dos modelos ARM em JSON. (Ref: learn.microsoft.com/azure/azure-resource-manager/templates/overview)

O Azure Cloud Shell é um terminal autenticado, executado no navegador, acessível pelo portal do Azure, por shell.azure.com ou pelo aplicativo móvel do Azure. Ele já vem com o Azure CLI (comandos az) e o Azure PowerShell (módulo Az) pré-instalados, além de ferramentas como kubectl, Terraform, git e editores de código. A persistência de arquivos funciona por meio de um compartilhamento do Azure Files (5 GB) montado no seu diretório $HOME, garantindo que scripts e configurações sobrevivam ao reinício da sessão. O Cloud Shell roda em um host Linux temporário que se autentica automaticamente com as suas credenciais do Azure. As sessões expiram após 20 minutos de inatividade. Na inicialização, você escolhe entre Bash ou PowerShell. A afirmação é “Verdadeiro” porque as duas CLIs vêm pré-instaladas e o Azure Files fornece persistência entre sessões. (Ref: learn.microsoft.com/azure/cloud-shell/overview)

Os bloqueios de recursos do Azure evitam a exclusão ou modificação acidental de recursos críticos. Dois tipos de bloqueio: CanNotDelete (bloqueio de exclusão) — usuários autorizados podem ler e modificar o recurso, mas não podem excluí-lo. ReadOnly — usuários autorizados podem ler o recurso, mas não podem modificá-lo nem excluí-lo. Bloqueios podem ser aplicados nos níveis de assinatura, grupo de recursos ou recurso individual e são herdados por recursos filhos. Bloqueios substituem permissões de RBAC — até Owners não conseguem excluir um recurso bloqueado com CanNotDelete sem primeiro remover o bloqueio. Azure Policy impõe regras de conformidade, mas não impede a exclusão diretamente. RBAC controla acesso, mas não consegue impedir exclusões em nível de Owner. Dica de prova: Bloqueios de recursos = impedir exclusão/modificação acidental. Dois tipos: CanNotDelete e ReadOnly. Substituem RBAC.

A hierarquia de recursos do Azure, do escopo mais alto para o mais baixo, é: Grupos de gerenciamento → Assinaturas → Grupos de recursos → Recursos. Os grupos de gerenciamento ficam no topo, organizando várias assinaturas e aplicando governança em escala. As assinaturas são limites de cobrança e acesso que contêm grupos de recursos. Os grupos de recursos são contêineres lógicos que agrupam recursos relacionados para gerenciamento do ciclo de vida. Os recursos são os serviços individuais do Azure (VMs, bancos de dados, contas de armazenamento). Políticas e atribuições de RBAC em níveis mais altos são herdadas pelos níveis mais baixos. Um recurso só pode pertencer a um grupo de recursos, um grupo de recursos a uma assinatura, e uma assinatura a um grupo de gerenciamento. Dica de prova: Hierarquia de cima para baixo: Grupos de gerenciamento > Assinaturas > Grupos de recursos > Recursos.