Cloud e DevOps

O que um pipeline de CI/CD faz, etapa por etapa

CI: valida cada push num ambiente limpo. Delivery: deixa o artefato pronto pra promover. Deployment: publica sozinho quando passa.

Deploy não é release

Deploy = código rodando no servidor. Release = comportamento visível ao usuário. Feature flag desacopla os dois: deploy frio, release controlada.

Logs, métricas e traces: o que cada um responde

Logs: o que aconteceu nesta request. Métricas: o sistema está saudável e a tendência. Traces: onde o tempo foi gasto no fluxo entre serviços.

Infra imutável e por que 'não dê SSH pra consertar'

Servidor nunca é editado in-place; muda-se recriando do código. SSH pra consertar cria snowflake não-reproduzível que o próximo deploy apaga.

Cenário: deploy sem downtime e com rollback rápido

Blue-green: troca tudo de uma vez, rollback = virar o roteador. Canary: fatia pequena crescente, rollback = cortar a fatia, menor blast radius (exige compat entre versões).

EC2, ECS/Fargate ou Lambda: escolher a computação

Lambda: evento esporádico, escala a zero, limite de tempo. Fargate: serviço contínuo em container sem gerenciar host. EC2: precisa administrar a máquina.

Modelo de responsabilidade compartilhada

AWS cuida da segurança 'da' nuvem (físico, hipervisor); você cuida 'na' nuvem (IAM, criptografia, config de acesso, patch). Bucket público é problema seu.

Cenário: servir um site e uploads de usuário com S3

Estáticos: S3 + CloudFront (cache nas bordas, bucket privado via OAC). Uploads: backend gera presigned URL curta e o cliente faz PUT direto no S3.

Pod, Deployment e Service: o que cada um é

Pod: containers agendados juntos, efêmeros. Deployment: mantém N réplicas de um Pod, faz rollout/rollback. Service: IP/DNS estável que balanceia pros Pods saudáveis por label.

Liveness x readiness probe

Readiness falhou → sai do Service, sem restart (warm-up, drenar). Liveness falhou → container reiniciado. Liveness que checa dependência externa vira crash loop quando a dependência cai.

Requests e limits de recurso

requests = reserva pro scheduler (mínimo garantido); limits = teto. Estourar CPU → throttling; estourar memória → OOMKilled. Sem limits, um container come o nó inteiro.

VPC, subnet pública x privada e como algo privado alcança a internet

Pública: route table com rota pro Internet Gateway. Privada: sem essa rota — inalcançável de fora. Saída da privada: NAT Gateway numa subnet pública faz a tradução; entrada de fora continua bloqueada.

SQS x SNS x EventBridge

SQS: fila, 1 mensagem → 1 consumidor, buffer/retry/DLQ. SNS: pub/sub fan-out, 1 → N inscritos. EventBridge: barramento com roteamento por regra sobre o conteúdo do evento, muitas integrações.

De onde vêm as contas surpresa da AWS

Data transfer de saída e entre regiões, NAT Gateway (hora + GB), recursos órfãos (EIP, EBS, snapshots), CloudWatch Logs sem retenção, non-prod 24/7, loop recursivo Lambda. Proteja com Budgets + alerta e tags de custo.

ConfigMap x Secret (e por que Secret não é 'seguro' por padrão)

ConfigMap: config não sensível. Secret: dado sensível, com um pouco mais de cuidado da API — mas é só base64 no etcd por padrão, não criptografado. Ligue encryption-at-rest + RBAC, ou use Vault/External Secrets.

Service x Ingress: como o tráfego externo chega num Pod

ClusterIP: interno. NodePort: porta alta em todo nó. LoadBalancer: LB do cloud por serviço (caro, sem roteamento L7). Ingress: regras HTTP por host/path + TLS, servidas por um Ingress Controller atrás de um LB só.

Autoscaling horizontal (HPA) e por que ele às vezes 'não escala'

HPA ajusta réplicas por métrica (CPU/custom) vs alvo. Não escala se: falta `resources.requests` de CPU, sem metrics-server, gargalo não é CPU, `maxReplicas` baixo, ou sem nós (precisa Cluster Autoscaler).