AWS Generative AI Developer - Professional (AIP-C01) — Questões de prática e simulado

Amazon Q Developer (a opção “Amazon Q Developer”) é a resposta correta. O Amazon Q Developer é o assistente de programação com IA da AWS, que oferece sugestões de código inline, geração de código, ajuda com refatoração e varredura de segurança diretamente nas IDEs mais populares. Ele é o sucessor do AWS CodeWhisperer, que foi renomeado e incorporado ao Amazon Q Developer. Por que cada opção incorreta está errada: - A. AWS Cloud9 — O AWS Cloud9 é um ambiente de desenvolvimento integrado (IDE) na nuvem que permite escrever, executar e depurar código usando apenas um navegador. Embora seja uma IDE, ele em si não oferece sugestões de código inline com IA, geração de código nem ajuda com refatoração. Ele é o ambiente, não o assistente de IA. - C. AWS CodeWhisperer (legacy) — O CodeWhisperer realmente oferecia sugestões de código com IA, mas foi renomeado e seus recursos foram incorporados ao Amazon Q Developer. Como marca legada e descontinuada, não é a resposta correta atual. Hoje a AWS direciona os usuários ao Amazon Q Developer para esses recursos. - D. Amazon CodeGuru Reviewer — O Amazon CodeGuru Reviewer é um serviço de revisão automatizada de código que usa machine learning para detectar problemas em código Java e Python. Segundo a documentação da AWS, ele “fornece recomendações de melhoria para o seu código Java e Python” por meio de revisões de código, mas não oferece sugestões de código inline em tempo real, geração de código nem ajuda com refatoração dentro de uma IDE. Além disso, desde 7 de novembro de 2025 não é mais possível criar novas associações de repositório. (Fonte: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)

Amazon SageMaker AI é a resposta correta porque ele oferece suporte nativo a Model Cards como recurso para documentar modelos de ML. As SageMaker Model Cards permitem que os desenvolvedores criem, editem e compartilhem programaticamente a documentação dos seus modelos, incluindo casos de uso previstos, limitações, resultados de avaliação e detalhes de negócio.

Como confirma a documentação do AWS CloudFormation, existe o tipo de recurso `AWS::SageMaker::ModelCard`, que inclui propriedades como `BusinessDetails` para documentar “informações sobre como o modelo apoia os objetivos de negócio”. Isso demonstra que as SageMaker Model Cards são um recurso de primeira classe do SageMaker AI, que pode ser criado e gerenciado programaticamente pelo SDK do SageMaker, pela API ou por ferramentas de infraestrutura como código, como o CloudFormation.

Por que cada opção incorreta está errada:

• A) AWS CloudFormation — Embora o CloudFormation possa *provisionar* SageMaker Model Cards (via `AWS::SageMaker::ModelCard`), o CloudFormation em si é um serviço de infraestrutura como código, e não o serviço que *oferece suporte* à criação de model cards como recurso. A funcionalidade de model card pertence ao SageMaker AI; o CloudFormation apenas orquestra a implantação dela.

• B) Amazon Bedrock — O Amazon Bedrock é um serviço gerenciado para acessar modelos de fundação via API. Ele não oferece um recurso de model card para documentar limitações do modelo, casos de uso previstos ou resultados de avaliação. Segundo o guia de decisão da AWS, o Bedrock foca em tornar os FMs acessíveis sem gerenciar infraestrutura, enquanto o SageMaker fornece o ferramental completo do ciclo de vida de ML, incluindo recursos de governança como as model cards.

• D) Amazon Q Business — O Amazon Q Business é um assistente com IA para uso corporativo que ajuda os funcionários a obter respostas a partir dos dados da empresa. Ele não oferece funcionalidade de model card para documentar metadados e informações de governança de modelos de ML.

(Fonte: https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-sagemaker-modelcard-businessdetails.html)

Provisioned Throughput com model units (a opção “Provisioned Throughput com model units”) é a resposta correta. Quando uma aplicação em produção exige capacidade de invocação de modelo garantida e dedicada para tráfego constante e de alto volume, o Provisioned Throughput é a escolha adequada. Segundo a documentação da AWS, o Provisioned Throughput permite comprar capacidade dedicada medida em model units, com prazos de compromisso (1 mês ou 6 meses), garantindo que sua aplicação tenha throughput reservado sem ficar sujeita ao throttling dos pools de capacidade compartilhada. Como diz a documentação: “O Amazon Bedrock oferece opções flexíveis de capacidade para se adequar aos requisitos da sua carga de trabalho e ao seu orçamento. Entender as diferenças entre os tiers on-demand (Flex, Priority, Standard), o tier reservado, o processamento batch e a inferência entre regiões ajuda você a otimizar tanto o desempenho quanto o custo.” O Provisioned Throughput pertence à categoria de tier reservado, que fornece capacidade garantida. Por que cada opção incorreta está errada: - A. Tier On-Demand Standard — Os tiers On-Demand (incluindo o Standard) oferecem acesso por uso, mas não garantem capacidade dedicada. Eles ficam sujeitos a throttling em períodos de alta demanda, já que a capacidade é compartilhada entre os clientes. Isso não atende ao requisito de capacidade “garantida”. - B. Inferência batch — A inferência batch foi projetada para processar grandes volumes de requisições de forma assíncrona (não em tempo real). Ela é otimizada para economia de custos em cargas de trabalho em massa que não exigem respostas imediatas, o que a torna inadequada para uma aplicação em produção atendendo tráfego ao vivo. - C. Cross-Region Inference com perfil Global — A Cross-Region Inference distribui as requisições entre várias regiões da AWS para melhorar a disponibilidade e reduzir a latência, mas não fornece capacidade dedicada garantida. Ela ainda depende dos pools de capacidade on-demand das diversas regiões e é, sobretudo, uma estratégia de resiliência e otimização de latência, não um mecanismo de reserva de capacidade. (Fonte: https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html e https://docs.aws.amazon.com/bedrock/latest/userguide/capacity-limits-cost-optimization.html)

A resposta correta é Fluxos de usuário sintéticos com validação de saída específica para IA, medindo taxas de alucinação e deriva semântica. Ao validar modelos de IA generativa após atualizações, os desenvolvedores precisam de abordagens de validação automatizadas e repetíveis que meçam especificamente métricas relevantes para IA, como taxas de alucinação e deriva semântica. Fluxos de usuário sintéticos com golden datasets (saídas esperadas conhecidas) permitem detectar sistematicamente regressões na qualidade do modelo antes de expô-lo ao tráfego ao vivo. Essa abordagem está alinhada aos recursos de configuração de dados de validação do Amazon Bedrock, em que conjuntos de validação são usados durante a personalização do modelo para avaliar seu desempenho frente a benchmarks conhecidos. O Amazon Bedrock oferece suporte à configuração de dados de validação (validationDataConfig) como parte dos jobs de personalização de modelo, o que permite avaliar a qualidade do modelo com conjuntos de validação estruturados. Esse princípio se estende à validação pós-implantação, em que fluxos sintéticos funcionam como testes de regressão para métricas de qualidade específicas de IA. Por que as outras opções estão erradas: - B (Testes de carga com Apache JMeter): Testes de carga medem características de desempenho como throughput, latência e tratamento de concorrência. Eles não avaliam qualidade semântica, taxas de alucinação ou deriva de conteúdo — que são exatamente as preocupações citadas na pergunta. - C (Testes manuais feitos por membros do time): Testes manuais não escalam, não são repetíveis e são altamente subjetivos. Eles não conseguem medir sistematicamente taxas de alucinação nem detectar deriva semântica sutil entre atualizações do modelo. Além disso, introduzem atrasos significativos no pipeline de implantação. - D (Testes A/B com usuários reais imediatamente após a implantação): Testes A/B com usuários reais expõem pessoas de verdade a um modelo potencialmente degradado antes de a validação estar concluída. As boas práticas determinam que as verificações de qualidade específicas de IA (detecção de alucinações, análise de deriva semântica) aconteçam *antes* de servir tráfego ao vivo, não depois. Essa abordagem arrisca experiências ruins para o usuário e possíveis danos causados por saídas alucinadas. (Fonte: https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)