dezembro 21, 2025
15 min de leitura

Perguntas de entrevista para DevOps sênior em sistemas de produção

interview
career-advice
job-search
Perguntas de entrevista para DevOps sênior em sistemas de produção
Milad Bonakdar

Milad Bonakdar

Autor

Prepare-se com perguntas práticas sobre Kubernetes, estado do Terraform, GitOps, segurança, observabilidade, incident response e decisões de produção.


O que uma entrevista DevOps sênior avalia

Entrevistas DevOps sênior normalmente avaliam se você sabe operar sistemas em produção, não apenas citar ferramentas. Espere cenários sobre falhas em Kubernetes, segurança do estado do Terraform, rollouts GitOps, resiliência em nuvem, controles de segurança, observabilidade e resposta a incidentes.

Use este guia para praticar respostas com critério: o que verificar primeiro, qual risco reduzir, como validar a correção e como explicar o trade-off para engenharia, segurança ou produto.


Kubernetes Avançado

1. Explique a arquitetura do Kubernetes e a função dos principais componentes.

Resposta: O Kubernetes usa uma arquitetura com plano de controle e nós de trabalho. Uma boa resposta sênior explica os componentes e como o estado desejado percorre o sistema:

Componentes do Plano de Controle:

  • API Server: Frontend para o plano de controle do Kubernetes, lida com todas as solicitações REST
  • etcd: Armazenamento de chave-valor distribuído para o estado do cluster
  • Scheduler: Atribui pods aos nós com base nos requisitos de recursos
  • Controller Manager: Executa processos do controlador (replicação, endpoints, etc.)
  • Cloud Controller Manager: Integra-se com as APIs do provedor de nuvem

Componentes do Nó:

  • kubelet: Agente que garante que os contêineres estejam em execução nos pods
  • kube-proxy: Mantém as regras de rede para a comunicação do pod
  • Container Runtime: Executa contêineres (Docker, containerd, CRI-O)
Loading diagram...

Como funciona:

  1. O usuário envia a implantação via kubectl
  2. O API Server valida e armazena no etcd
  3. O Scheduler atribui pods aos nós
  4. O kubelet no nó cria contêineres
  5. O kube-proxy configura a rede

Raridade: Muito Comum Dificuldade: Difícil


2. Como você soluciona um pod preso em CrashLoopBackOff?

Resposta: Abordagem de depuração sistemática:

# 1. Verifique o status e os eventos do pod
kubectl describe pod <nome-do-pod>
# Procure por: Erros de pull de imagem, limites de recursos, verificações de saúde com falha

# 2. Verifique os logs
kubectl logs <nome-do-pod>
kubectl logs <nome-do-pod> --previous  # Logs do contêiner anterior

# 3. Verifique as restrições de recursos
kubectl top pod <nome-do-pod>
kubectl describe node <nome-do-nó>

# 4. Verifique as sondas de liveness/readiness
kubectl get pod <nome-do-pod> -o yaml | grep -A 10 livenessProbe

# 5. Execute dentro do contêiner (se ele permanecer ativo brevemente)
kubectl exec -it <nome-do-pod> -- /bin/sh

# 6. Verifique a imagem
kubectl get pod <nome-do-pod> -o jsonpath='{.spec.containers[*].image}'
docker pull <imagem>  # Teste localmente

# 7. Verifique ConfigMaps/Secrets
kubectl get configmap
kubectl get secret

# 8. Revise a especificação de implantação/pod
kubectl get deployment <nome-da-implantação> -o yaml

Causas comuns:

  • Aplicativo falha na inicialização
  • Variáveis de ambiente ausentes
  • Configuração incorreta da sonda de liveness
  • Recursos insuficientes (OOMKilled)
  • Erros de pull de imagem
  • Dependências ausentes

Exemplo de correção:

# Aumentar os limites de recursos
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Ajustar o tempo da sonda
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Dar tempo para o aplicativo iniciar
  periodSeconds: 10
  failureThreshold: 3

Raridade: Muito Comum Dificuldade: Média


3. Explique a rede do Kubernetes: Services, Ingress e Network Policies.

Resposta: Camadas de rede do Kubernetes:

Services: Tipos de exposição de serviço:

# ClusterIP (apenas interno)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (acesso externo via IP do nó)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (balanceador de carga da nuvem)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: Roteamento HTTP/HTTPS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Network Policies: Controlar a comunicação pod-a-pod:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Raridade: Muito Comum Dificuldade: Difícil


4. Como você implementa o autoscaling no Kubernetes?

Resposta: Várias estratégias de autoscaling:

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # ou "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: Ajusta automaticamente o tamanho do cluster com base nos pods pendentes:

# Exemplo da AWS
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

Raridade: Comum Dificuldade: Média


Terraform Avançado

5. Explique o gerenciamento de estado do Terraform e as melhores práticas.

Resposta: O estado do Terraform rastreia a infraestrutura e é fundamental para as operações.

Configuração de Estado Remoto:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Bloqueio de Estado:

# Tabela DynamoDB para bloqueio de estado
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Melhores Práticas:

1. Nunca envie arquivos de estado para o Git

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. Use workspaces para ambientes

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. Importe recursos existentes

# Importar instância EC2 existente
terraform import aws_instance.web i-1234567890abcdef0

# Verificar
terraform plan

4. Manipulação de estado (use com cuidado)

# Listar recursos no estado
terraform state list

# Mostrar recurso específico
terraform state show aws_instance.web

# Mover recurso no estado
terraform state mv aws_instance.old aws_instance.new

# Remover recurso do estado (não exclui)
terraform state rm aws_instance.web

5. Faça backup do estado antes de grandes alterações

terraform state pull > backup.tfstate

Raridade: Muito Comum Dificuldade: Difícil


6. Como você estrutura o código Terraform para grandes projetos?

Resposta: Estrutura modular para manutenção:

Estrutura de Diretórios:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

Exemplo de Módulo:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "Bloco CIDR para VPC"
  type        = string
}

variable "environment" {
  description = "Nome do ambiente"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "Blocos CIDR para sub-redes privadas"
  type        = list(string)
}

variable "availability_zones" {
  description = "Zonas de disponibilidade"
  type        = list(string)
}

variable "tags" {
  description = "Tags comuns"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Usando Módulos:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

Raridade: Comum Dificuldade: Difícil


Arquitetura de Nuvem

7. Projete uma arquitetura multi-região altamente disponível na AWS.

Resposta: Arquitetura multi-região para alta disponibilidade:

Loading diagram...

Componentes-chave:

1. DNS e Gerenciamento de Tráfego:

# Route 53 com verificações de saúde
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. Replicação de Banco de Dados:

# RDS com réplica de leitura entre regiões
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. Replicação de Dados:

# Replicação entre regiões S3
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

Princípios de Design:

  • Configuração ativo-ativo ou ativo-passivo
  • Failover automatizado com verificações de saúde
  • Replicação de dados com atraso mínimo
  • Implantação consistente em todas as regiões
  • Monitoramento e alertas para ambas as regiões

Raridade: Comum Dificuldade: Difícil


GitOps e CI/CD

8. Explique GitOps e como implementá-lo com ArgoCD.

Resposta: GitOps usa o Git como a única fonte de verdade para infraestrutura e aplicativos declarativos.

Princípios:

  1. Configuração declarativa no Git
  2. Sincronização automatizada
  3. Controle de versão para todas as alterações
  4. Reconciliação contínua

Implementação do ArgoCD:

# Manifesto do aplicativo
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Estrutura de Diretórios:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

Benefícios:

  • Git como trilha de auditoria
  • Rollbacks fáceis (git revert)
  • Estado desejado declarativo
  • Detecção automatizada de desvios
  • Gerenciamento multi-cluster

Raridade: Comum Dificuldade: Média


Segurança e Conformidade

9. Como você implementa as melhores práticas de segurança no Kubernetes?

Resposta: Abordagem de segurança em várias camadas:

1. Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (Controle de Acesso Baseado em Função):

# Função para desenvolvedores
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Network Policies:

# Negar todo o tráfego de entrada por padrão
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Secrets Management:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. Image Scanning:

# Admission controller com OPA
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("Image %v is not from approved registry", [image])
    }

Raridade: Muito Comum Dificuldade: Difícil


Observabilidade e SRE

10. Projete uma pilha de observabilidade abrangente.

Resposta: Três pilares da observabilidade: Métricas, Logs, Traces

Arquitetura:

Loading diagram...

1. Métricas (Prometheus + Grafana):

# ServiceMonitor para métricas do aplicativo
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. Logging (Loki):

# Configuração do Promtail para coleta de logs
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. Tracing (Jaeger):

# Instrumentação do aplicativo
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Configurar o tracing
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# Usar no código
with tracer.start_as_current_span("process_request"):
    # Seu código aqui
    pass

4. Regras de Alerta:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Alta taxa de erros detectada"
        description: "A taxa de erros é {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Alta latência detectada"

5. Monitoramento de SLO:

# Definição de SLO
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "As solicitações de API devem ser bem-sucedidas"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

Raridade: Comum Dificuldade: Difícil


Recuperação de Desastres

11. Como você implementa a recuperação de desastres para um cluster Kubernetes?

Resposta: Estratégia de DR abrangente:

1. Estratégia de Backup:

# Agendamento de backup do Velero
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 2 AM diariamente
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 dias

2. Backup do etcd:

#!/bin/bash
# Script de backup automatizado do etcd

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# Enviar para o S3
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Limpar backups antigos
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Procedimento de Restauração:

# Restaurar o etcd do snapshot
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Restaurar o aplicativo com o Velero
velero restore create --from-backup daily-backup-20231125
velero restore describe <nome-da-restauração>

4. Failover Multi-Região:

# Terraform para configuração multi-região
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... configuração
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... configuração
}

# Verificação de saúde e failover do Route 53
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. Metas de RTO/RPO:

  • RTO (Recovery Time Objective): < 1 hora
  • RPO (Recovery Point Objective): < 15 minutos
  • Simulações de DR regulares (mensais)
  • Runbooks documentados
  • Failover automatizado sempre que possível

Raridade: Comum Dificuldade: Difícil


Service Mesh

12. Explique a arquitetura de service mesh e quando usá-la.

Resposta: Um service mesh fornece uma camada de infraestrutura para comunicação serviço a serviço.

Componentes Principais:

Loading diagram...

Implementação do Istio:

# Virtual Service para roteamento de tráfego
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: v1
    labels:
      version: v1

Quando usar:

  • Comunicação complexa entre microserviços
  • mTLS, autorização e regras de tráfego consistentes
  • Canary releases, divisão de tráfego e melhor isolamento de falhas
  • Observabilidade comum para chamadas entre serviços

Atenção: Um service mesh adiciona complexidade, latência e esforço operacional. Em entrevistas sênior, explique por que o benefício compensa esse custo no sistema específico.


Conclusão

Não se prepare apenas para definições de ferramentas. Em cada resposta, mostre como você isolaria um problema de produção, priorizaria riscos, validaria a correção e transformaria o aprendizado em uma melhoria permanente.

Newsletter subscription

Dicas de carreira semanais que realmente funcionam

Receba as últimas ideias diretamente na sua caixa de entrada

Pare de Se Candidatar. Comece a Ser Contratado.

Transforme seu currículo em um ímã de entrevistas com otimização impulsionada por IA em que candidatos a emprego em todo o mundo confiam.

Comece grátis

Compartilhar esta publicação

Faça Seus 6 Segundos Contarem

Os recrutadores escaneiam currículos por uma média de apenas 6 a 7 segundos. Nossos modelos comprovados são projetados para capturar atenção instantaneamente e mantê-los lendo.