DEV Community: Klleriston Andrade

Como passar no exame AWS CLF-C02

Klleriston Andrade — Mon, 26 Jan 2026 02:25:33 +0000

Como colecionador de badges e considerando que meu ambiente de trabalho atual faz uso extensivo da AWS, optei por realizar a certificação AWS Certified Cloud Practitioner (CLF-C02).

Observação inicial

Aqui vai uma dica: caso você já compreenda os conceitos fundamentais de cloud computing e os problemas que esse paradigma se propõe a resolver, ou possua experiência prévia com outras plataformas de nuvem, você já parte de uma vantagem significativa.

Metodologia de Estudo

Após ter sido aprovado nas certificações AZ-900 e AI-900 da Microsoft, ficou claro que certificações de nível introdutório seguem padrões bastante semelhantes de avaliação.

De forma geral, todas cobram:

Conceitos fundamentais de computação em nuvem
Modelos de serviço (IaaS, PaaS, SaaS)
Serviços mais populares do provedor, como:
- Computação
- Bancos de dados relacionais e não relacionais
- Filas e mensageria*
- Redes
- Identidade e controle de acesso (IAM)

A principal diferença entre os exames está na ênfase dada a determinados domínios, conforme a estratégia do provedor.

Estrutura do Exame

Aqui temos diferenças entre provas de diferentes provedores. Na AWS, por exemplo, até o dia 25/01/2025 estão sendo cobrados os seguintes domínios:

Domain 1 – Cloud Concepts (24%)
Domain 2 – Security and Compliance (30%)
Domain 3 – Cloud Technology and Services (34%)
Domain 4 – Billing, Pricing, and Support (12%)

Conhecer essa distribuição permite priorizar os domínios com maior peso na pontuação final. Ou seja, dedique-se mais aos conceitos que se enquadram nesses domínios.

Como me preparar para a prova?

A documentação oficial da AWS é uma boa forma de se preparar para o exame, mas caso você seja como eu e prefira vídeos (alguém basicamente lendo a documentação para você), recomendo os seguintes cursos: André Iacono (conteúdo em português) ou Stephane Maarek (conteúdo em inglês), ambos na Udemy, que apresentam cobertura adequada dos tópicos.

Processo de Preparação

Fase de Absorção: leitura da documentação oficial ou curso estruturado
Fase de Consolidação: anotações técnicas dos serviços principais (não pule esta etapa)
Fase de Validação: simulados (simulado oficial da AWS, YouTube ou Exam Topics)

Critério de Aprovação

Uma taxa de acerto consistente ≥ 80% nos simulados indica prontidão para o exame real.

O tempo de preparação é variável, indo de dias a semanas, dependendo do nível de dedicação e do conhecimento prévio.

Idempotência, Potência e Métodos HTTP em REST

Klleriston Andrade — Sun, 29 Dec 2024 20:05:42 +0000

Em sistemas de grande porte, onde podem haver milhares ou até milhões de acessos simultâneos, garantir consistência e confiabilidade nas operações é imprescindível. Imagine um cenário em que cada cliente realiza um pagamento e, devido a uma falha de conexão, ou qualquer outro problema externo que dificulte a comunicação entre cliente x servidor, o mesmo pedido é enviado varias vezes, resultando assim em múltiplas cobranças causando insatisfação por parte do usuário.

É exatamente nesses casos que entram os conceitos de idempotência e potência.

Idempotência

O conceito de idempotência diz respeito a uma operação que, quando executada várias vezes, sempre produz o mesmo estado final. Ou seja, independentemente do número de vezes que o usuário realize uma operação, o estado do sistema permanece consistente após a primeira execução bem-sucedida.

Um exemplo clássico é a confirmação de um pedido:

Se o cliente enviar a requisição para confirmar o pedido várias vezes, apenas a primeira tentativa será processada. As outras tentativas não terão efeito adicional.

Exemplos:

Pagamentos online: Garantir que uma transação não seja processada mais de uma vez.
Confirmação de ações: Certificar-se de que uma ação, como envio de e-mail, não seja duplicada.

Potência

Enquanto a idempotência está relacionada à repetição de uma operação, potência refere-se ao impacto que uma operação tem sobre o estado do recurso no servidor

Operações potentes: Modificam o estado do recurso (ex.: POST, PUT).
Operações não potentes: Não alteram o estado do recurso (ex.: GET, HEAD).

Motivo:

Um método GET apenas recupera informações de um recurso, sem alterar o estado.
Um método POST cria ou modifica um recurso, impactando o estado no servidor.

Chaves de Idempotência

As chaves de idempotência são uma ferramenta essencial para garantir a segurança e a confiabilidade das operações.

Uma chave de idempotência é um identificador único gerado pelo cliente e vai junto com uma requisição ao servidor. Pense em um rotulo exclusivo para cada operação que quer realizar

Como funciona ?

Geração da Chave: Antes de enviar uma requisição, o cliente gera uma chave única
Envio da Requisição: A chave é incluída no cabeçalho da requisição
Processamento no Servidor: Se é a primeira vez que o servidor recebe essa chave, ele processa a requisição normalmente.

Se a mesma chave é recebida novamente, o servidor retorna o resultado da operação original, sem reprocessá-la

Exemplo:

Imagine que você está fazendo um pagamento online:

Você clica em "Pagar" e seu aplicativo gera uma chave de idempotência (ex: "idempotencia-pagamento-123").
O aplicativo envia a requisição de pagamento com esta chave.
Se, por algum problema de conexão, a requisição for enviada duas vezes, o servidor:

Processará apenas a primeira requisição.
Para a segunda, retornará o resultado da primeira, evitando um pagamento duplicado.

Algoritmos e Big O notation

Klleriston Andrade — Fri, 23 Feb 2024 19:01:14 +0000

Olá a todos, eu sou o Klleriston, estudante de análise e desenvolvimento de sistemas pela FIAP, e estou animado em apresentar a vocês os conceitos de Big O e algoritmos.

Ao longo deste texto, vou explorar conceitos sobre o assunto que são indispensáveis, seja para um desenvolvedor iniciante ou mais experiente.

Algoritmos

Resumidamente, um algoritmo não passa de uma sequência finita de instruções para resolver determinado problema, seja matemático ou computacional.

Podemos encontrar exemplos de algoritmos em muitas atividades do nosso cotidiano. Por exemplo, quando seguimos uma receita, estamos na verdade executando um algoritmo, um processo com passos determinados que nos leva a um resultado delicioso: um bolo, por exemplo.

Big O

Big O é uma notação para saber o quão eficaz é um algoritmo em relação ao espaço e tempo. Em poucas palavras, pode-se dizer que é uma forma de classificar o quanto aquele determinado algoritmo é escalável. Podemos categorizar o Big O em 6 níveis de complexidade:

O(n) Complexidade linear
O(log n) Complexidade logarítmica
O(1) Complexidade constante
O(n log n) Complexidade log-linear
O(n^2): Complexidade quadrática
O(2^n): Complexidade exponencial

Não irei entrar a fundo neste artigo sobre exemplos e definições sobre cada tipo de complexidade. Caso tenham interesse, eu recomendo o livro 'Entendendo algoritmos - Aditya Y. Bhargava' ou o vídeo do 'Lucas Montano "Big O Notation: O Pesadelo do Programador Iniciante"'. Ambos foram essenciais para o meu entendimento sobre o tema.

Conclusão

Bom, neste artigo eu optei por trazer um conteúdo breve e resumido sobre um assunto que estou estudando agora. Gostaria que este artigo tenha despertado o interesse em algoritmos e na notação Big O.

Como já disse antes, eu fortemente recomendo o livro 'Entendendo algoritmos - Aditya Y. Bhargava' e o vídeo do Lucas Montano 'Big O Notation: O Pesadelo do Programador Iniciante' para aprofundar seu conhecimento.

Se sentirem dificuldade em algo relacionado ao tema, ou se quiserem deixar um feedback e discutir mais sobre o assunto, sintam-se à vontade para deixar um comentário ou me chamar no Linkedin. Estou ansioso para continuar essa discussão.

Obrigado pela atenção. Espero que você tenha achado este artigo útil.

Recomendações

SOLID para desenvolvedores iniciantes.

Klleriston Andrade — Tue, 23 Jan 2024 17:46:40 +0000

Antes de mais nada, precisamos definir o que, afinal, é SOLID e por que ele é tão importante na Programação Orientada a Objetos (POO)?

Bem, SOLID é um acrônimo, ou seja, uma sigla na qual cada letra corresponde a um dos cinco princípios de design de código. Esses princípios são utilizados para facilitar a compreensão, o desenvolvimento e a manutenção de software, ou seja, o famoso Clean Code.

Acredito que a maioria de vocês já deve ter ouvido falar de Robert C. Martin, mais conhecido no mundo do desenvolvimento como Uncle Bob.

A história da origem do SOLID começou no final da década de 1980, enquanto Uncle Bob discutia os princípios de design de software com outros usuários de uma rede social chamada USENET, com o objetivo de catalogar os mais importantes. Essa catalogação durou bastante tempo, mas, como foi dito em sua obra “Clean Architecture” ou “Arquitetura Limpa”, Bob explica que, em 2004, seu amigo Michael Fathers enviou um e-mail dizendo que, se reorganizasse esses princípios tão importantes para o desenvolvimento, as primeiras letras formariam o que conhecemos como SOLID (sólido em português), e foi aí que nasceu o acrônimo.

Sem mais delongas, vou explicar o que cada letra significa e demonstrar um exemplo que faça sentido.

Começamos com a letra S de Single Responsiblity Principle (Principio da responsabilidade única)

O primeiro princípio diz que uma classe deve ser especialista em apenas um assunto. Isto é, a classe precisa ter apenas uma função. Se mais de uma função for atribuída a ela, ou se estiver lidando com mais de uma responsabilidade, provavelmente o código precisa ser revisado, pois isso dificultará a realização de testes. Se o código estiver difícil de ser testado, então ele pode ser melhorado.

Vou usar de exemplo aqui o anime "One Punch Man", sabemos que o Saitama tem uma única responsabilidade, derrotar monstros com um unico soco. Ele não se envolve em outras tarefas como por exemplo, liderar uma equipe ou planejar estratégias

codigo em c# para exemplificar:

using System;
public class Heroi
{
    public string Nome { get; private set; }
    public HeroiAnimeCombate(string nome)
    {
        Nome = nome;
    }
    public void DerrotarMonstroComUmSoco()
    {
        Console.WriteLine($"{Nome} derrota o monstro com um único soco!");
    }
}

class Program
{
    static void Main()
    {
        HeroiAnimeCombate saitama = new Heroi("Saitama");
        saitama.DerrotarMonstroComUmSoco();
    }
}

O de Open-Closed Principle (Principio Aberto-fechado)

Esse principio diz que um objeto ou entidade deve estar aberto a extensões porém fechado a modificações, O que quer dizer isso ? aberto e fechado ? bom, isso significa que um objeto deve estar apto a receber novos comportamentos e recursos porem ele não deve sofrer alteração em seu codigo fonte.

por exemplo, dessa vez irei utilizar o mundo de "Naruto". O personagem Naruto é um otimo exemplo desse principio ja que ele é aberto para extensão, ou seja, consegue aprender muitos jutsus novos como rasengan e jutsu clone das sombras porem fechado para modificação pois em nenhum momento ele deixou de querer ser o hokage da vila. Seu objetivo continuou o mesmo.

codigo em c# para exemplificar:

using System;
using System.Collections.Generic;

public interface IJutsu
{
    void Executar();
}

public class Rasengan : IJutsu
{
    public void Executar()
    {
        Console.WriteLine("Executando Rasengan!");
    }
}

public class JutsuCloneSombras : IJutsu
{
    public void Executar()
    {
        Console.WriteLine("Executando Jutsu Clone das Sombras!");
    }
}

public class Ninja
{
    public string Nome { get; private set; }
    private List<IJutsu> jutsus;

    public Ninja(string nome)
    {
        Nome = nome;
        jutsus = new List<IJutsu>();
    }

    public void AprenderNovoJutsu(IJutsu novoJutsu)
    {
        jutsus.Add(novoJutsu);
    }

    public void ExecutarJutsus()
    {
        Console.WriteLine($"{Nome} está executando seus jutsus:");
        foreach (var jutsu in jutsus)
        {
            jutsu.Executar();
        }
    }
}

class Program
{
    static void Main()
    {
        Ninja naruto = new Ninja("Naruto");
        naruto.AprenderNovoJutsu(new Rasengan());
        naruto.AprenderNovoJutsu(new JutsuCloneSombras());

        naruto.ExecutarJutsus();
    }
}

L - Liskov Substitution Principle (Princípio de substituição de Liskov)

O princípio de Liskov diz que uma classe derivada deve ser substituível por sua classe base, ou seja, basicamente, levando para a questão de herança em OO (Orientação a Objetos), a classe filha deve desempenhar as mesmas funções da classe pai.

Vamos usar como exemplo o anime "My Hero Academy", onde todos os estudantes da U.A. School podem ser substituídos numa luta contra vilões (obviamente, uns vão desempenhar melhor que outros, mas isso não vem ao caso), porque todos eles foram treinados para se tornarem heróis, ou seja, herdam da classe pai "Herói".

codigo em c# para exemplificar:

using System;

public class Heroi
{
    public string Nome { get; private set; }

    public Heroi(string nome)
    {
        Nome = nome;
    }

    public virtual void RealizarAcaoHeroica()
    {
        Console.WriteLine($"{Nome} está realizando uma ação heroica!");
    }
}

public class EstudanteUA : Heroi
{
    public EstudanteUA(string nome) : base(nome)
    {
    }

    public override void RealizarAcaoHeroica()
    {
        base.RealizarAcaoHeroica();
        Console.WriteLine($"{Nome} está usando seus poderes de estudante para complementar a ação heroica!");
    }
}

class Program
{
    static void Main()
    {
        Heroi heroi = new EstudanteUA("Midoriya");
        heroi.RealizarAcaoHeroica();
    }
}

I - Interface Segregation Principle (Principio da segregação de interface)

O princípio de segregação de interface diz que uma classe não deve ser forçada a implementar interfaces e métodos que não irá utilizar.

Basicamente, esse princípio diz que criar interfaces mais específicas é melhor do que genéricas, pois nem todas as funções podem ser realizadas e isso causaria um trabalho a mais.

Como exemplo, posso citar ‘One Piece’, onde o bando do Chapéu de Palha é um exemplo do princípio de segregação de interface. Cada membro da tripulação tem habilidades e funções específicas e interage apenas com as partes de seu sistema (navio) que são relevantes para sua função.

Por exemplo, Sanji é o cozinheiro e sua principal interface é a cozinha. Ele não precisa saber navegar e nem lutar com espadas, pois isso é dever de Nami e Zoro, que seguem as devidas interfaces

codigo em c# para exemplificar:

using System;

public interface IHabilidadesEspecificas
{
    void RealizarHabilidadeEspecifica();
}

public class Sanji : IHabilidadesEspecificas
{
    public void RealizarHabilidadeEspecifica()
    {
        Console.WriteLine("Sanji está cozinhando!");
    }
}

public class Nami : IHabilidadesEspecificas
{
    public void RealizarHabilidadeEspecifica()
    {
        Console.WriteLine("Nami está navegando!");
    }
}

public class Zoro : IHabilidadesEspecificas
{
    public void RealizarHabilidadeEspecifica()
    {
        Console.WriteLine("Zoro está duelando!");
    }
}

public class TripulacaoChapeuDePalha
{
    private IHabilidadesEspecificas membroTripulacao;

    public void DefinirMembroDaTripulacao(IHabilidadesEspecificas membro)
    {
        membroTripulacao = membro;
    }


    public void RealizarAcaoTripulacao()
    {
        if (membroTripulacao != null)
            membroTripulacao.RealizarHabilidadeEspecifica();
        else
            Console.WriteLine("Sem membro definido na tripulação.");
    }
}

class Program
{
    static void Main()
    {
        TripulacaoChapeuDePalha tripulacao = new TripulacaoChapeuDePalha();

        tripulacao.DefinirMembroDaTripulacao(new Sanji());
        tripulacao.RealizarAcaoTripulacao();

        tripulacao.DefinirMembroDaTripulacao(new Nami());
        tripulacao.RealizarAcaoTripulacao();

        tripulacao.DefinirMembroDaTripulacao(new Zoro());
        tripulacao.RealizarAcaoTripulacao();
    }
}

D - Dependency Inversion Principle (Principio da inversão da dependência)

O princípio de inversão de dependência afirma que módulos de alto nível devem depender de módulos de baixo nível por meio de abstrações, e não de implementações concretas.

Em outras palavras, o conceito diz que a classes de alto nível deve depender de interfaces ou classes abstratas, e não de classes concretas.

Um anime que faz bastante sentido ser usado como exemplo é FullMetal Alchemist. No anime, os irmãos Elric estão em busca da pedra filosofal, pra isso, eles precisam aprender alquimia avançada. Eles dependem da alquimia para atingir seus objetivos, mas não se importam com a implementação específica dela. Eles só precisam saber que a alquimia pode ajudá-los.

A alquimia é uma abstração que representa a capacidade de transmutar a matéria. A implementação pode variar, porém a abstração permanece a mesma.

codigo em c# para exemplificar:

using System;

// Abstração
public interface IAlquimia
{
    void Transmutar();
}

// Implementação
public class AlquimiaAvancada : IAlquimia
{
    public void Transmutar()
    {
        Console.WriteLine("Realizando transmutação avançada...");
    }
}

// Classe de alto nível dependendo da abstração
public class BuscaPedraFilosofal
{
    private readonly IAlquimia alquimia;

    public BuscaPedraFilosofal(IAlquimia alquimia)
    {
        this.alquimia = alquimia;
    }

    public void RealizarMissao()
    {
        Console.WriteLine("Iniciando missão para encontrar a pedra filosofal.");
        alquimia.Transmutar();
        Console.WriteLine("Missão concluída.");
    }
}

class Program
{
    static void Main()
    {
        //a classe de alto nível depende da abstração (IAlquimia), não da implementação concreta
        IAlquimia alquimiaAvancada = new AlquimiaAvancada();
        BuscaPedraFilosofal missao = new BuscaPedraFilosofal(alquimiaAvancada);

        missao.RealizarMissao();
    }
}

Por que um desenvolvedor precisa aprender sobre o modelo TCP/IP ?

Klleriston Andrade — Mon, 08 Jan 2024 19:17:06 +0000

Há muitas razões para aprender, mesmo que o básico sobre protocolos de redes. Já que 90% do mercado hoje é focado em web, esse conhecimento se torna não apenas relevante, mas indispensável para qualquer desenvolvedor. Nesse artigo, trarei o básico sobre modelo TCP/IP, desde suas camadas até a aplicação prática no desenvolvimento web.

Para começo de conversa, a estrutura da internet é construída sobre o modelo TCP/IP. Entender esse modelo ajuda na compreensão de como os dados são transmitidos (cliente x servidor).

Mas qual a diferença entre HTTP(s) para o tcp/ip e qual a relação entre eles?

O HTTP/HTTPs utilizam do modelo TCP/IP na camada de transporte (vou explicar logo mais) para estabelecer conexão entre clientes e servidores.

Basicamente, o TCP/IP fornece a infraestrutura para o transporte, enquanto o HTTP(s) especificam como os dados devem ser formatados e transferidos.

Pense que a relação deles seja uma conversa entre dois amigos que estão enviando cartas um para o outro.

Imagine que o TCP/IP é como o correio, que cuida do roteamento, da entrega e da confirmação recebida. Agora o HTTP(s) como o conteúdo da carta com informações específicas.

Camadas do modelo TCP/IP

O modelo TCP/IP é composto por quatro camadas, sendo elas: acesso de rede, internet, transporte e aplicação. Para melhor entendimento, imagine cada camada como um andar de um prédio, cada uma desempenha uma função crucial no processo de comunicação.

Camada de acesso:

Responsável pela transmissão de dados entre dispositivos em uma mesma rede local.

Camada de internet:

Lida com o roteamento de pacotes de dados entre diferentes redes.

Camada de transporte:

Aqui é onde reside o TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol), sendo o TCP responsável pela confiabilidade na transmissão.

Camada de aplicação:

Engloba protocolos de nível de aplicação, como já ditos anteriormente, HTTP, HTTP(s). Existem outros também, como por exemplo o FTP e o SMTP, mas não abordaremos eles nesse artigo.

Como o desenvolvimento é impactado usando o modelo TCP/IP?

Compreender como as camadas interagem é crucial para o desenvolvimento web. Ao criar aplicações, os desenvolvedores interagem principalmente com a camada de aplicação, utilizando o HTTP e o HTTPS.

O que são sockets? (Sockets Programming)

Sockets são uma interface de programação (API) que fornece um mecanismo para a comunicação entre processos em diferentes dispositivos, seja na mesma máquina ou em máquinas remotas.
Os sockets permitem que programas troquem dados e informações de maneira bidirecional, estabelecendo conexão entre cliente x servidor.

Há dois tipos de sockets, os sockets de fluxo (TCP) e sockets de datagrama (UDP).

Sockets de fluxo garantem uma transmissão confiável de dados, assegurando que os dados sejam entregues na ordem correta e sem perda.
Sockets de datagrama (UDP) oferecem uma comunicação mais leve, sem garantias de entrega ou ordem. (São úteis para aplicações onde a perda de pacotes é aceitável, como por exemplo streams ou jogos online).

Segurança com o modelo TCP/IP

O modelo TCP/IP é essencial para entender as práticas de segurança na web. Aspectos como criptografia em camadas de transporte (HTTPS), firewalls na camada de internet e boas práticas na camada de aplicação são fundamentais para proteger aplicações contra ameaças.

Criptografia em camadas de transporte:

A criptografia em camadas de transporte, como TLS/SSL, é uma prática de segurança que envolve a aplicação de técnicas criptográficas para proteger a confidencialidade dos dados durante a transmissão. Utilizando um protocolo seguro na camada de transporte (geralmente sobre o TCP), a criptografia assegura que as informações transmitidas entre cliente e servidor permaneçam privadas e seguras contra interceptação.

Firewalls:

Os firewalls são dispositivos ou softwares que monitoram e controlam o tráfego de rede com base em regras predefinidas. Essa medida de segurança é implementada em diferentes camadas do modelo TCP/IP, incluindo a camada de Internet e a camada de Aplicação. Os firewalls ajudam a prevenir acessos não autorizados, filtrar tráfego malicioso e proteger contra ameaças externas, contribuindo para a segurança global de uma rede ou sistema.

Conclusão

Dominar o modelo TCP/IP ou pelo menos saber o básico é essencial para qualquer desenvolvedor que almeje trabalhar com web. Essa compreensão facilita o desenvolvimento de aplicações eficientes e seguras.

Referencias

CISCO - Visão geral sobre TCP/IP
DevChannel - Introdução TCP/IP
Proeminente - Modelo de redes TCP/IP
IBM - Sockets
CISCO - Firewalls