Microsoft AZ-204: Azure API Management — Guia de estudos

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Developer Associate AZ-204 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Azure API Management (APIM) fornece uma fachada unificada sobre diversos serviços de backend, combinando um gateway de alto desempenho com um mecanismo de políticas configurável, integração de desenvolvedores e um plano de gerenciamento completo. Ele permite controles consistentes de segurança, limitação de taxa (throttling), transformação, observabilidade e ciclo de vida em backends REST, SOAP e GraphQL. O APIM é tanto um gateway de tempo de execução para o tráfego quanto um sistema orientado por configuração que você gerencia através do portal do Azure, ARM/Bicep/CLI ou CI/CD. Compreender o pipeline de requisições, as capacidades das políticas, o versionamento/revisões, o modelo de assinatura e as características das camadas (tiers) é fundamental para construir APIs robustas e seguras em escala.

Arquitetura, Camadas e Componentes Principais

O gateway é o plano de dados. Ele encerra as conexões dos clientes, aplica políticas em uma ordem determinística, roteia para os backends e retorna as respostas. Ele suporta cache integrado, validação de JWT, TLS mútuo e transformação de conteúdo na velocidade da linha (line rate). Os gateways podem ser hospedados pela Microsoft por região ou auto-hospedados (em contêineres) para serem executados mais perto de cargas de trabalho on-premises ou de borda (edge), permanecendo gerenciados centralmente. O gateway expõe rastreamento (tracing) e métricas e se integra com o Application Insights para telemetria distribuída.

O portal do desenvolvedor é a experiência voltada para o consumidor para descoberta, documentação e gerenciamento de assinaturas. Ele renderiza a documentação OpenAPI/GraphQL, fornece consoles interativos “experimente”, lida com fluxos OAuth 2.0 no navegador e suporta personalização de marca e provedores de identidade. Os desenvolvedores autogerenciam assinaturas de produtos e rotacionam chaves aqui.

O plano de gerenciamento é a superfície de configuração e governança. Ele armazena APIs, operações, políticas, produtos, usuários/grupos, backends, certificados e diagnósticos. É acessível através do portal do Azure, ARM/Bicep/CLI/PowerShell, da API REST de Gerenciamento e da sincronização de configuração baseada em Git. Este plano orquestra implantações, versionamento, revisões e RBAC.

As camadas (tiers) do APIM determinam a escala, os recursos e as capacidades de rede:

Consumption (Consumo) é serverless e cobrado por chamada. Ele escala automaticamente, é ideal para cenários com picos de tráfego (spiky) ou de baixa vazão, e suporta a maioria das políticas principais. Não inclui cache de resposta integrado e não possui recursos avançados de rede e multirregionais.
Developer (Desenvolvedor) é para ambientes de não produção. Oferece funcionalidade quase completa sem um SLA e sem vazão em escala de produção.
Basic (Básico) e Standard (Padrão) são camadas de produção dedicadas e de região única com vazão previsível, unidades de scale-out e cache de resposta integrado. São adequadas para muitas cargas de trabalho empresariais que não exigem recursos multirregionais ou de rede avançada.
Premium adiciona implantação multirregional, rede avançada (incluindo integração com VNet), maior escala, zonas de disponibilidade em regiões suportadas e licenciamento de gateway auto-hospedado. Escolha a camada Premium para implantações globais, de missão crítica e com rede privada.

Políticas e o Pipeline de Requisições

As políticas do APIM são declarações declarativas que executam em uma ordem estrita em quatro seções: inbound (entrada), backend, outbound (saída) e on-error (em caso de erro).

As políticas de inbound são executadas antes que a requisição seja encaminhada para o backend. Tarefas típicas incluem exigir ou validar chaves de assinatura, validar JWTs (impondo emissor, público e assinatura), verificar IPs de clientes, aplicar limites de taxa e cotas, normalizar cabeçalhos, reescrever URIs e transformar o payload. Você pode rotear condicionalmente para diferentes backends e definir variáveis para estágios posteriores.

A seção de backend configura e modifica a chamada para o serviço upstream. Use-a para selecionar uma entidade de backend, anexar credenciais de cliente (autenticação Basic, certificados de cliente ou tokens adquiridos via identidade gerenciada para backends protegidos pelo Azure AD), definir timeouts, habilitar novas tentativas e aplicar o padrão circuit breaker. O TLS mútuo com o backend é configurado aqui associando um certificado de cliente que o gateway apresentará.

As políticas de outbound são executadas após o recebimento da resposta do backend. Elas comumente realizam transformações de resposta (por exemplo, JSON para XML ou vice-versa), reescrita de cabeçalho, modelagem de dados (data shaping), mascaramento de detalhes internos e cache de resposta. Este também é o local para aplicar conversões de negociação de conteúdo ou para normalizar códigos de status.

As políticas on-error são executadas se ocorrer uma exceção em qualquer seção anterior, incluindo a chamada ao backend. Use esta seção para mapear erros do backend para formatos de erro de API padronizados, definir códigos de status apropriados, redigir mensagens sensíveis, adicionar IDs de correlação ou fornecer respostas de fallback.

Padrões comuns de políticas:

A limitação de taxa (rate limiting) controla picos de vazão e protege os backends. A política rate-limit-by-key impõe uma limitação por identidade usando uma chave como a chave de assinatura, uma claim do JWT ou o IP. Para janelas de tempo maiores, combine com quota-by-key para limitar o uso diário ou mensal.
A filtragem de IP bloqueia ou permite tráfego por IP de cliente ou intervalos CIDR usando ip-filter, frequentemente posicionada no início da seção inbound para minimizar custos e exposição.
A validação de JWT com validate-jwt impõe parâmetros do OpenID Connect. Configure a URL de configuração do OpenID ou o emissor, defina públicos/escopos aceitos, selecione as claims necessárias e ajuste a distorção de relógio (clock skew) e as verificações de tempo de vida do token. Negue o acesso anônimo exigindo um token válido para todas as operações onde chamadas anônimas não são permitidas.
A transformação inclui rewrite-uri, set-header, set-query-parameter, set-body e find-and-replace. Use xml-to-json ou json-to-xml para fazer a ponte entre formatos de cliente/backend incompatíveis sem alterar o código.
O cache utiliza cache-lookup e cache-store para armazenar em cache respostas inteiras com base em chaves que podem incluir caminho, consulta, cabeçalhos e claims de JWT. Use cache-lookup-value/cache-store-value para cache de chave/valor dentro das políticas, como para armazenar tokens em cache. Observe que o cache de resposta integrado não está disponível na camada Consumption.

Segurança, Identidade e Assinaturas

A segurança do front-end (cliente para o gateway) e a segurança do back-end (gateway para o serviço) devem ser ambas abordadas.

Para a segurança do front-end, o padrão dominante é o OAuth 2.0 com o Azure AD. Os clientes adquirem tokens do Azure AD e os apresentam ao gateway. O APIM impõe os requisitos do token usando a política validate-jwt, que referencia os metadados OpenID Connect do Azure AD (o endpoint “well-known” do tenant). As políticas podem impor verificações de público (audience) para garantir que o token se destina à API correta, claims de escopo (scope) para garantir que os chamadores tenham as permissões apropriadas e claims opcionais, como funções de aplicativo (app roles). Para eliminar chamadas anônimas, a política validate-jwt deve ser aplicada a todas as operações. O portal do desenvolvedor pode ser configurado com o Azure AD para simplificar a aquisição de tokens durante os testes.

Para certificados de cliente e TLS mútuo (mTLS), o APIM pode exigir certificados de cliente de entrada dos chamadores, validando emissor/assunto/expiração e, opcionalmente, o status de CRL/OCSP usando a política validate-client-certificate. Isso é adequado para integrações B2B e de alta garantia. Para mTLS do gateway para o back-end, faça o upload de um certificado de cliente para o APIM, associe-o a uma entidade de back-end ou use set-backend-service, e o APIM o apresentará durante o handshake TLS para se autenticar no back-end. Essa abordagem é frequentemente exigida por serviços App Service protegidos ou serviços personalizados que impõem autenticação por certificado.

Para back-ends protegidos pelo Azure AD, use a política authentication-managed-identity na seção de back-end para adquirir um token de acesso com a identidade gerenciada do APIM, seja ela atribuída pelo sistema ou pelo usuário. A política injeta o cabeçalho Authorization na chamada para o back-end. Isso evita o armazenamento de segredos e atende aos requisitos modernos de confiança zero (zero trust).

As assinaturas (Subscriptions) fornecem um modelo de acesso e monetização de granularidade mais ampla. Produtos são pacotes de APIs governados por termos, aprovação e limites de uso. Os desenvolvedores assinam produtos para obter chaves de assinatura (primária e secundária) usadas por meio do cabeçalho Ocp-Apim-Subscription-Key ou de um parâmetro de consulta. As chaves podem ser rotacionadas sem tempo de inatividade graças às chaves duplas. O escopo da assinatura determina onde as chaves se aplicam: a todas as APIs, a uma única API ou a um produto específico. O acesso baseado em assinatura é complementar ao OAuth 2.0; ambos podem ser exigidos, permitindo limitação de taxa (throttling) e contabilização separadas, enquanto a autenticação depende de tokens. Os produtos podem impor cotas e limites de taxa por assinatura, independentemente das políticas por operação, fornecendo proteção e governança em camadas.

Backends, Resiliência, Versionamento e Revisões

Backends no APIM são entidades de primeira classe e reutilizáveis que encapsulam a URL base de um serviço de destino, protocolo, credenciais, configurações de TLS, modelos de cabeçalho e configuração de proxy. Associar APIs e operações a backends desacopla o roteamento das políticas e centraliza os detalhes de conexão. Use set-backend-service pelo ID do backend em políticas para rotear requisições sem codificar URLs fixamente (hard-coding), simplificando a promoção entre ambientes de desenvolvimento, teste e produção.

A resiliência é imposta com novas tentativas (retries) e interrupção de circuito (circuit breaking). Novas tentativas com backoff exponencial podem mitigar falhas transitórias; elas devem ser limitadas a operações idempotentes e delimitadas por timeouts razoáveis para evitar amplificação. Uma política de circuit breaker abre quando a taxa de falha, falhas consecutivas ou latência excedem os limiares configurados dentro de uma janela de amostragem, interrompendo as requisições por uma duração de quebra definida. Durante o estado aberto, a política pode retornar imediatamente uma resposta de fallback ou rotear para um backend de standby. Quando semiaberto (half-open), um número limitado de requisições de teste sonda a saúde do backend antes de fechar o circuito. Isso protege os backends, melhora a experiência do cliente e estabiliza os sistemas sob falha parcial.

O balanceamento de carga e o roteamento podem ser implementados na camada de políticas. O roteamento condicional com choose pode direcionar o tráfego por segmento de usuário, geografia, conteúdo da requisição ou sinais de saúde. O roteamento ponderado pode ser alcançado por meio de expressões de política que selecionam um backend pseudoaleatoriamente de acordo com os pesos desejados, permitindo canary releases e rollouts graduais. Backends ativo-ativo entre regiões podem ser gerenciados por uma implantação multirregional do APIM de nível Premium, combinada com roteamento condicional para a região saudável mais próxima; alternativamente, integre com o Azure Front Door para balanceamento de carga global de camada 7, enquanto o APIM lida com autenticação e transformação.

Versionamento e revisões governam o ciclo de vida da API. Conjuntos de versões (version sets) definem como múltiplas versões da API são apresentadas aos clientes usando um esquema de versionamento por caminho (path), query string ou cabeçalho. Use versões para breaking changes; cada versão é uma entidade de API separada, associada ao mesmo conjunto de versões. Alterações iterativas que não quebram a compatibilidade (non-breaking) são implementadas como revisões. Uma revisão é um snapshot mutável de uma API que pode ser invocado explicitamente (através do sufixo de revisão) para testes, enquanto uma revisão anterior permanece como a revisão de produção atual. Após a validação, promova a nova revisão para atual (current) sem alterar o identificador de versão. Essa separação permite uma entrega segura e progressiva: revisões para atualizações non-breaking; versões para breaking changes, apresentadas através de descoberta e documentação claras no portal do desenvolvedor.

Finalmente, observe e governe. Habilite o rastreamento (tracing), defina IDs de correlação e exporte diagnósticos para o Application Insights para visibilidade de ponta a ponta. Gerencie a configuração via ARM/Bicep ou o APIM DevOps Resource Kit para alcançar implantações repetíveis, e aplique RBAC no plano de gerenciamento para separar as responsabilidades entre autores, publicadores e operadores de API.

Cenário de Problema Prático

A Starbucks precisa expor uma API pública unificada para pedidos via aplicativo móvel que agrega microsserviços em duas regiões do Azure. A API deve bloquear o acesso anônimo, limitar clientes abusivos (throttling), proteger os backends regionais de falhas em cascata e permitir o rollout gradual de um esquema de pedidos v2 sem quebrar os clientes da v1.

Implantar uma instância APIM Premium em duas regiões e habilitar a implantação multirregional. O nível Premium é selecionado pela presença de gateways multirregionais, rede avançada e escala empresarial. Gateways regionais reduzem a latência para clientes móveis e fornecem resiliência ativo-ativo.
Importar os serviços de backend como entidades de backend do APIM, incluindo as instâncias do App Service em ambas as regiões. Entidades de backend centralizam URLs base, TLS e configurações de credenciais, permitindo políticas de roteamento limpas e portabilidade entre ambientes.
Proteger a comunicação cliente-gateway com Azure AD OAuth 2.0 e validar tokens usando validate-jwt na seção de entrada (inbound). O Azure AD fornece identidade centralizada, acesso condicional e validação robusta de tokens. A política validate-jwt garante que apenas chamadores autenticados com as audiências/escopos corretos possam invocar a API.
Exigir assinaturas de produto (product subscriptions) e emitir chaves de assinatura (subscription keys) por aplicativo parceiro. Isso adiciona uma camada de governança e medição independente do OAuth e permite cotas por parceiro, rotação fácil de chaves e onboarding self-service baseado no portal.
Configurar rate-limit-by-key e quota-by-key na seção de entrada (inbound), usando a chave de assinatura como identificador. O throttling protege os backends de picos de tráfego e permite SLAs diferenciados para parceiros. Usar chaves de assinatura como discriminador alinha a aplicação das políticas com os contratos de negócio.
Implementar filtragem de IP para bloquear faixas de IP maliciosas conhecidas e permitir faixas corporativas da Starbucks para administração. A política ip-filter reduz a superfície de ataque no início do pipeline e economiza recursos downstream.
Configurar mTLS (mutual TLS) de backend para serviços sensíveis, fazendo o upload de certificados de cliente para o APIM e vinculando-os às entidades de backend relevantes. O mTLS fornece autenticação forte de serviço a serviço onde os backends exigem certificados, satisfazendo as políticas de segurança internas.
Adicionar authentication-managed-identity na seção de backend para serviços protegidos pelo Azure AD. A identidade gerenciada (managed identity) do APIM adquire tokens de acesso para o backend, removendo segredos e integrando-se com o Azure RBAC e o acesso condicional.
Implementar um circuit-breaker com retry e fallback na seção de backend. Em caso de falhas repetidas dentro de uma janela de tempo, abra o circuito e roteie as requisições para o backend regional saudável; se ambos estiverem fora do ar, retorne uma resposta de fallback padronizada e em cache. Isso protege os serviços degradados e entrega um comportamento previsível sob falha.
Usar roteamento condicional para balancear a carga de leituras para a região mais próxima e fazer failover com base em sinais de saúde. Expressões de política selecionam a região local inspecionando um cabeçalho personalizado ou geolocalização de IP; sondas de saúde (health probes) preenchem variáveis para as decisões de roteamento. Isso proporciona baixa latência e continuidade durante incidentes regionais.
Introduzir um conjunto de versões (version set) para a API de Pedidos com versionamento baseado em caminho (/v1, /v2). Criar uma nova revisão da v2 para testes, validar com clientes selecionados invocando a URL específica da revisão e, em seguida, promovê-la para atual (current). Conjuntos de versões comunicam breaking changes de forma limpa, enquanto as revisões permitem iteração segura e non-breaking.
Habilitar o cache de resposta para endpoints com muita leitura (menu/catálogo) na seção de saída (outbound) com cache-lookup e cache-store, variando por localidade e tipo de dispositivo. O cache alivia os backends de buscas repetidas e melhora o desempenho móvel; o nível Premium suporta esses recursos em escala.

Este design entrega APIs autenticadas, com throttling, resilientes e evolutivas. O APIM Premium fornece o gateway global e seguro; as políticas impõem identidade, throttling, transformação e resiliência; entidades de backend e identidades gerenciadas protegem e desacoplam as conexões; conjuntos de versões e revisões fornecem um ciclo de vida disciplinado para entrega contínua sem interrupção para o cliente.

← Autenticação · Todos os domínios · Soluções do Azure Baseadas em Eventos e Mensagens →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →