OCI Foundations Associate (1Z0-1085-25): infraestrutura Oracle Cloud na prática

Então, quer começar em Oracle Cloud? Essa é a prova certa. Sem pré-requisitos, sem exigência de experiência prévia — e melhor ainda, a Oracle não cobra nada. A ideia da certificação não é transformar ninguém em um Arquiteto de Cloud. Ela exige que você entenda o que tem dentro do OCI: quais são os serviços, pra que cada um serve, e quando faz sentido escolher um em vez do outro.

E isso faz toda a diferença. Quem entra sem ter essa visão geral passa os primeiros meses sofrendo de verdade. Descobre o serviço certo depois de já ter resolvido o problema de um jeito bem mais caro. Ou acaba criando uma solução super elaborada quando existia um serviço gerenciado pronto pra usar que fazia exatamente a mesma coisa.

DADOS DA PROVA:

- Código: 1Z0-1085-25
- Questões: 40, múltipla escolha
- Duração: 60 minutos
- Aprovação: 65%
- Custo: gratuito
- Aposentadoria da versão 2025: 15 de junho de 2026

PARTE 1 - O QUE É OCI E O QUE A PROVA COBRE?

OCI é a nuvem da Oracle. Concorre com AWS, Azure e GCP, claro - mas a Oracle tem três diferenciais: banco de dados, performance de rede e aquele preço de egress (saída de dados) que não dói tanto no bolso. Além desses pontos, tem tudo que qualquer nuvem séria oferece hoje em dia: Compute, storage, rede, database, segurança, monitoramento, containers - ou seja, tudo!

A prova de certificação organiza todos esses serviços em quatro domínios. E aqui é a parte importante - os pesos não são iguais pra todos:

Core OCI Services: 50%

Security Services: 25%

Getting Started with OCI: 15%

Governance and Administration: 10%

E o que esses números querem dizer? Metade da prova é sobre serviços do dia a dia mesmo: compute, storage, networking, database. Outros 25%? Segurança. Por isso é importante estudar tendo esses pesos em mente para aproveitar melhor o tempo. Quem se organiza dessa maneira acaba se saindo muito melhor.

O que cai em cada domínio:

GETTING STARTED WITH OCI - arquitetura de regiões, Availability Domains (ADs) e Fault Domains (FDs), modelo de tenancy e compartimentos, modelos de serviço de nuvem (IaaS, PaaS, SaaS), formas de acessar o OCI (console, CLI, SDKs, APIs).

CORE OCI SERVICES - Compute (VMs, Bare Metal, OKE, Functions), Networking (VCN, subnets, gateways, load balancer, DNS), Storage (Block Volume, Object Storage, File Storage, NVMe local), Database (Autonomous Database com suas variantes, Base Database Service, MySQL HeatWave, NoSQL).

SECURITY SERVICES - IAM (usuários, grupos, políticas, compartimentos), modelo de responsabilidade compartilhada, Cloud Guard, Security Zones, Vault, Bastion Service.

GOVERNANCE AND ADMINISTRATION - budgets, Cost Analysis, Usage Reports, Tagging, Pricing Calculator.

PARTE 2 - SERVIÇOS ORACLE NA PRÁTICA

ARQUITETURA: REGIÕES, ADS E FAULT DOMAINS

Tudo no OCI mora dentro de uma hierarquia geográfica bem estruturada.

REGIÕES - são conjuntos de data centers espalhados pelo mundo. São Paulo, por exemplo (sa-saopaulo-1). Dentro de cada região? A Oracle tem de um a três AVAILABILITY DOMAINS - os ADs. Cada um é um data center fisicamente separado: tem energia própria, rede própria e refrigeração própria. E dentro de cada AD existem três FAULT DOMAINS, agrupamentos de hardware que não compartilham pontos únicos de falha.

E por que isso é importante? Simples. Você coloca duas instâncias no mesmo AD, mas em Fault Domains diferentes. Se um rack pega fogo, a outra fica de pé. Quer alta disponibilidade de verdade? Distribui entre ADs distintos.

Pra quem trabalha no Brasil, ter São Paulo como região muda tudo. Dados sujeitos a LGPD ficam no Brasil, sem precisar daquele monte de controle extra sobre residência. Quem trabalha com setor público ou financeiro já sabe como isso dá trabalho.

IAM: QUEM PODE FAZER O QUÊ E ONDE

O IAM do OCI não funciona como os demais. Esqueça policies coladas em usuários e roles por aí - a Oracle não usa essa abordagem. Eles tem algo bem mais direto: políticas escritas em linguagem quase natural. Aplicadas a grupos? Claro. Resultado? Por exemplo, isso esse grupo consegue fazer, só nesse compartimento.

A estrutura é sempre a mesma:

Allow <grupo> to <verbo> <tipo-de-recurso> in <compartimento ou tenancy>

Os verbos são quatro, em ordem crescente de poder:

- inspect - listar recursos e ver metadados

- use - usar recursos existentes sem modificar

- manage - criar, alterar e excluir

- admin - tudo, incluindo gerenciar as próprias políticas

Alguns exemplos do mundo real:

# Desenvolvedor pode usar instâncias no compartimento de desenvolvimento
Allow group Developers to use compute-family in compartment Development

# DBA pode gerenciar Autonomous Database em produção
Allow group DBAdmins to manage autonomous-database-family in compartment Production

# Time de segurança pode auditar tudo sem alterar nada
Allow group SecurityTeam to inspect all-resources in tenancy

# Instância pode acessar Object Storage (Dynamic Group)
Allow dynamic-group AppServers to use object-family in compartment Production

Dynamic Groups agrupam recursos em vez de pessoas. Simples assim. Você define o critério de entrada - por exemplo, "qualquer instância dentro do compartimento Production". Aí a mágica acontece: sua instância consegue ler secrets do Vault ou gravar no Object Storage sem precisar guardar credencial dentro do servidor. Elimina aquele anti-pattern chato de hardcoded em código.

# Regra de Dynamic Group: qualquer instância no compartimento Production
Any {instance.compartment.id = 'ocid1.compartment.oc1..xxxxxxxx'}

# Política que usa o Dynamic Group
Allow dynamic-group AppServers to read secret-family in compartment Production

Pela CLI fica assim:

# Criar um grupo
oci iam group create \
 --name "Developers" \
 --description "Time de desenvolvimento de produto"

# Criar política
oci iam policy create \
 --compartment-id <tenancy-ocid> \
 --name "dev-compute-policy" \
 --statements '["Allow group Developers to use compute-family in compartment Development"]' \
 --description "Permissao de compute para desenvolvedores"

# Listar políticas existentes
oci iam policy list --compartment-id <tenancy-ocid> --all

COMPUTE: SHAPES, VMS E QUANDO USAR CADA OPÇÃO

Toda instância no OCI tem um SHAPE, que é uma receita de bolo do hardware: quantas OCPUs, quanto de RAM, quanto de rede. Os shapes Flex dão uma margem de ajuste para esses valores, já os fixos já vem prontos com uma configuração só.

Os principais para uso geral:

Shape                 Tipo                 Casos de uso
VM.Standard.E4.Flex   AMD EPYC, Flex       Workloads gerais
VM.Standard.E5.Flex   AMD EPYC Gen5, Flex  Performance melhorada
VM.Standard3.Flex     Intel Xeon, Flex     Workloads Intel-specific
VM.Standard.A1.Flex   ARM Ampere, Flex     Containers, apps cloud-native
BM.Standard.E4.128    Bare Metal           Alta performance, sem hypervisor
VM.GPU.A10.1          GPU NVIDIA A10       Inferência de IA, rendering

Um detalhe importante: o A1.Flex (ARM da Ampere) é o shape mais barato do OCI, e está no Always Free com 4 OCPUs e 24 GB de RAM no total, ou seja, gratuito para sempre. Se sua aplicação roda em Node, Python, Java ou qualquer coisa que não exija x86, você pode rodar workload de produção sem pagar nada.

# Criar instância VM.Standard.E4.Flex com 2 OCPUs e 16 GB
oci compute instance launch \
 --compartment-id <compartment-ocid> \
 --availability-domain "GrCH:SA-SAOPAULO-1-AD-1" \
 --shape "VM.Standard.E4.Flex" \
 --shape-config '{"ocpus": 2, "memoryInGBs": 16}' \
 --image-id <image-ocid> \
 --subnet-id <subnet-ocid> \
 --display-name "app-prod-01" \
 --ssh-authorized-keys-file ~/.ssh/id_rsa.pub \
 --assign-public-ip true

# Verificar status
oci compute instance get \
 --instance-id <instance-ocid> \
 --query 'data."lifecycle-state"'

# Listar instâncias em um compartimento
oci compute instance list \
 --compartment-id <compartment-ocid> \
 --lifecycle-state "RUNNING"

O ORACLE CONTAINER ENGINE FOR KUBERNETES (OKE) é o Kubernetes gerenciado do OCI. Toda a parte chata (etcd, API server, scheduler) fica nas mãos da Oracle, sem custo adicional. Você só cuida dos worker nodes, que no fim das contas são instâncias Compute normais dentro do seu compartimento. Para quem conhece EKS ou GKE não tem segredo.

# Criar cluster OKE básico
oci ce cluster create \
 --compartment-id <compartment-ocid> \
 --name "producao-k8s" \
 --vcn-id <vcn-ocid> \
 --kubernetes-version "v1.30.1" \
 --services-cidr "10.96.0.0/16" \
 --pods-cidr "10.244.0.0/16"

# Obter kubeconfig
oci ce cluster create-kubeconfig \
 --cluster-id <cluster-ocid> \
 --file ~/.kube/config \
 --region sa-saopaulo-1

O ORACLE FUNCTIONS é o serverless da casa, construído em cima do projeto open source Fn. Você manda o código em Python, Node, Java, Go ou Ruby, a Oracle roda, e cobra por invocação e por tempo de execução. Quando ninguém chama a função, o custo é zero. Nada de ficar pagando por tempo ocioso.

# Criar aplicação Functions
oci fn application create \
 --compartment-id <compartment-ocid> \
 --display-name "processamento-eventos" \
 --subnet-ids '["<subnet-ocid>"]'

# Deploy de uma função (requer Fn CLI instalado)
fn deploy --app processamento-eventos

NETWORKING: VCN, SUBNETS E O QUE SEPARA O TRÁFEGO

O que é a Virtual Cloud Network? É sua rede privada dentro do OCI. Simples. Você escolhe o bloco CIDR, fatia em subnets, controla tráfego com regras de firewall. E quem manda pra onde cada pacote vai? As Route Tables - tudo baseado no destino.

COMO FUNCIONAM OS CINCO GATEWAYS:

- Internet Gateway - libera tráfego nos dois sentidos entre subnet pública e internet. Recurso precisa ter IP público pra ficar acessível de fora.

- NAT Gateway - deixa instâncias de subnet privada sair pra internet (baixar pacote, atualizar SO) sem aceitar conexão vinda de fora.

- Service Gateway - rota direta pros serviços Oracle (Object Storage, Autonomous Database e cia) sem passar pela internet pública. O tráfego fica dentro da rede da Oracle mesmo. Faz muita diferença em latência e em compliance.

- Local Peering Gateway (LPG) - conecta duas VCNs na mesma região sem precisar atravessar a internet.

- Dynamic Routing Gateway (DRG) - seu ponto de conexão com redes externas - FastConnect (link dedicado), VPN IPSec ou até outras regiões do próprio OCI.

# Criar VCN
oci network vcn create \
 --compartment-id <compartment-ocid> \
 --display-name "vcn-producao" \
 --cidr-block "10.0.0.0/16" \
 --dns-label "producao"

# Criar subnet pública
oci network subnet create \
 --compartment-id <compartment-ocid> \
 --vcn-id <vcn-ocid> \
 --display-name "subnet-publica" \
 --cidr-block "10.0.0.0/24" \
 --dns-label "publica" \
 --prohibit-public-ip-on-vnic false

# Criar subnet privada
oci network subnet create \
 --compartment-id <compartment-ocid> \
 --vcn-id <vcn-ocid> \
 --display-name "subnet-privada" \
 --cidr-block "10.0.1.0/24" \
 --dns-label "privada" \
 --prohibit-public-ip-on-vnic true

# Criar Internet Gateway
oci network internet-gateway create \
 --compartment-id <compartment-ocid> \
 --vcn-id <vcn-ocid> \
 --display-name "igw-producao" \
 --is-enabled true

# Criar NAT Gateway
oci network nat-gateway create \
 --compartment-id <compartment-ocid> \
 --vcn-id <vcn-ocid> \
 --display-name "nat-producao"

SECURITY LISTS X NETWORK SECURITY GROUPS (NSGS):

Security Lists? Ficam grudadas na subnet inteira. Toda instância nessa subnet herda as regras, queira ou não - é automático mesmo. NSGs já são diferentes - ficam presos em VNICs específicas (interfaces de rede), não importa em qual subnet a instância está. O bom dos NSGs é poder referenciar um no outro: "deixa meu NSG de app servers conversar com o NSG dos bancos de dados na porta 1521". Bem mais limpo do que abrir um CIDR inteiro. Detalhe: Isso sempre cai na prova.

# Criar NSG
oci network nsg create \
 --compartment-id <compartment-ocid> \
 --vcn-id <vcn-ocid> \
 --display-name "nsg-app-servers"

# Adicionar regra de ingress: porta 443 da internet
oci network nsg-rules add \
 --nsg-id <nsg-ocid> \
 --security-rules '[{
"direction": "INGRESS",
"protocol": "6",
"source": "0.0.0.0/0",
"sourceType": "CIDR_BLOCK",
"tcpOptions": {"destinationPortRange": {"min": 443, "max": 443}}
 }]'

Sobre balanceamento: o LOAD BALANCER trabalha em Layer 7 (HTTP/HTTPS) e faz roteamento por path, terminação SSL, health check e sticky session. Já o Network Load Balancer trabalha em Layer 4, com latência menor, mais indicado para protocolos que não são HTTP.

STORAGE: QUATRO OPÇÕES, QUATRO CASOS DE USO

BLOCK VOLUME é o disco persistente. Você cria, pluga numa instância, formata, monta. Se a instância parar, o disco continua intacto. Dá para clonar, tirar snapshot e mover de instância.

# Criar Block Volume de 200 GB
oci bv volume create \
 --compartment-id <compartment-ocid> \
 --availability-domain "GrCH:SA-SAOPAULO-1-AD-1" \
 --display-name "vol-dados-app" \
 --size-in-gbs 200 \
 --vpus-per-gb 20

# Anexar à instância
oci compute volume-attachment attach \
 --instance-id <instance-ocid> \
 --type paravirtualized \
 --volume-id <volume-ocid>

O parâmetro vpus-per-gb ajusta a performance: 0 é Lower Cost (bom para backup), 10 é Balanced (uso geral), 20 é Higher Performance (banco de dados) e 120 é Ultra High Performance (quando latência é essencial).

OBJECT STORAGE guarda objetos acessados via API REST ou CLI. Esquece sistema de arquivos, esquece pasta. O que tem é bucket e objeto com chave. Escala sem teto, durabilidade alta. Dois tiers: Standard, para acesso frequente, e Archive, para o que você quase nunca vai ler (restauração demora horas, mas o custa muito menos).

# Criar bucket
oci os bucket create \
 --compartment-id <compartment-ocid> \
 --name "dados-producao" \
 --storage-tier "Standard"

# Upload de arquivo
oci os object put \
 --bucket-name "dados-producao" \
 --file ./relatorio-abril.csv \
 --name "relatorios/2026/04/relatorio-abril.csv"

# Listar objetos por prefixo
oci os object list \
 --bucket-name "dados-producao" \
 --prefix "relatorios/2026/"

# Gerar URL pré-assinado válido por 1 hora
oci os preauth-request create \
 --bucket-name "dados-producao" \
 --name "acesso-relatorio" \
 --access-type "ObjectRead" \
 --object-name "relatorios/2026/04/relatorio-abril.csv" \
 --time-expires "$(date -u -d '+1 hour' '+%Y-%m-%dT%H:%M:%SZ')"

# Mover objeto para Archive (reduz custo de armazenamento)
oci os object copy \
 --bucket-name "dados-producao" \
 --source-object-name "relatorios/2024/01/relatorio.csv" \
 --destination-bucket "dados-arquivo" \
 --destination-object-name "relatorios/2024/01/relatorio.csv"

FILE STORAGE é NFS gerenciado pela Oracle. A grande diferença em relação ao Block Volume é que várias instâncias conseguem montar o mesmo filesystem ao mesmo tempo. Imagine um cluster de aplicação que compartilha arquivo, pipeline de ML que precisa ler o mesmo dataset em paralelo e ambiente de desenvolvimento compartilhado por um time.

# Criar File System
oci fs file-system create \
 --compartment-id <compartment-ocid> \
 --availability-domain "GrCH:SA-SAOPAULO-1-AD-1" \
 --display-name "dados-compartilhados"

# Criar Mount Target (ponto de acesso NFS na VCN)
oci fs mount-target create \
 --compartment-id <compartment-ocid> \
 --availability-domain "GrCH:SA-SAOPAULO-1-AD-1" \
 --subnet-id <subnet-privada-ocid> \
 --display-name "mt-producao"

Dentro de cada instância Linux que vai montar:

# Montar o File Storage
sudo mount -t nfs \
 -o nfsvers=3 \
 <mount-target-ip>:/<export-path> \
 /mnt/dados-compartilhados

# Para montar automaticamente no boot, adicionar ao /etc/fstab:
# <ip>:/<export> /mnt/dados-compartilhados nfs nfsvers=3,_netdev 0 0

LOCAL NVME aparece só nos shapes DenseIO. É o disco físico parafusado no servidor mesmo, sem rede no caminho. Latência cai de milissegundo para dezenas de microssegundos. O preço a pagar é que, na hora que a instância desliga, o dado vai junto. Use para cache de banco, scratch de treinamento de ML, ou qualquer coisa que você já replica para storage persistente.

DATABASE: AUTONOMOUS DATABASE E SUAS VARIANTES

O Autonomous Database é o banco relacional auto-gerenciado da Oracle. Na prática isso quer dizer que a Oracle cuida do patching, do backup, de subir e descer CPU, de melhorar query e detectar anomalia de segurança. Você fica só com o que realmente importa: modelar dados, escrever query, manter o esquema.

Quatro variantes, cada uma para um cenário:

- ATP (Autonomous Transaction Processing) - para OLTP. Muita concorrência, transação curta, milhares de conexões abertas. Ótimo para e-commerce, ERP, sistemas com escrita e leitura constantes.

- ADW (Autonomous Data Warehouse) - para analytics. Query analítica pesada em volume grande de histórico. Columnstore por padrão, paralelismo automático.

- AJD (Autonomous JSON Database) - banco de documentos JSON com API SODA, compatível com a API do MongoDB. Bom para aplicações que trabalham com dados sem esquema fixo.

- APEX Application Development - banco com Oracle APEX instalado para fazer aplicação web low-code.

# Criar Autonomous Database (ATP)
oci db autonomous-database create \
 --compartment-id <compartment-ocid> \
 --db-name "APPDB01" \
 --display-name "banco-producao" \
 --db-workload "OLTP" \
 --cpu-core-count 2 \
 --data-storage-size-in-tbs 1 \
 --admin-password "SenhaForte#2026!" \
 --is-auto-scaling-enabled true

# Verificar status
oci db autonomous-database get \
 --autonomous-database-id <adb-ocid> \
 --query 'data."lifecycle-state"'

# Escalar CPU sem downtime
oci db autonomous-database update \
 --autonomous-database-id <adb-ocid> \
 --cpu-core-count 4

# Criar conexão via SQL Developer Web (obtém URL do service console)
oci db autonomous-database get \
 --autonomous-database-id <adb-ocid> \
 --query 'data."connection-urls"."sql-dev-web-url"'

Depois que o banco está de pé, o gerenciamento via browser fica no DATABASE ACTIONS (o antigo SQL Developer Web):

-- Criar schema de aplicação
CREATE USER app_user IDENTIFIED BY "SenhaApp#2026!";
GRANT CONNECT, RESOURCE TO app_user;
GRANT UNLIMITED TABLESPACE TO app_user;

-- Exemplo de tabela com coluna JSON
CREATE TABLE pedidos (
id      NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
cliente_id  NUMBER NOT NULL,
detalhes   CLOB CHECK (detalhes IS JSON),
criado_em  TIMESTAMP WITH TIME ZONE DEFAULT SYSTIMESTAMP
);

-- Inserir pedido com detalhe JSON
INSERT INTO pedidos (cliente_id, detalhes) VALUES (
1001,
'{"itens": [{"produto": "Notebook", "qty": 1, "preco": 4500.00}], "total": 4500.00}'
);

-- Consultar usando JSON_VALUE
SELECT id, cliente_id,
  JSON_VALUE(detalhes, '$.total') AS total
FROM pedidos
WHERE JSON_VALUE(detalhes, '$.itens[0].produto') = 'Notebook';

SEGURANÇA: CLOUD GUARD, VAULT E BASTION

O CLOUD GUARD fica de olho no seu tenancy procurando configuração problemática. Ele roda Detectors que pegam coisas como bucket aberto para a internet por engano, instância sem patch recente ou regra de Security List liberal demais. Cada problema vira um Finding para você investigar. Dá para amarrar Responders que agem sozinhos: fechar o bucket, mandar email ou disparar uma Function.

Para ligar:

# Verificar status do Cloud Guard na região
oci cloud-guard configuration get \
 --compartment-id <tenancy-ocid>

# Ativar Cloud Guard com reporting region
oci cloud-guard configuration update \
 --compartment-id <tenancy-ocid> \
 --status "ENABLED" \
 --reporting-region "sa-saopaulo-1"

O VAULT guarda chaves de criptografia e secrets. Por padrão, o OCI já criptografa dado em repouso com chave da própria Oracle. Quando o compliance exige chave sua, você cria uma Customer-Managed Key (CMK) dentro do Vault e passa a usar ela.

# Criar Vault
oci kms management vault create \
 --compartment-id <compartment-ocid> \
 --display-name "vault-producao" \
 --vault-type "DEFAULT"

# Criar chave de criptografia AES-256
oci kms management key create \
 --compartment-id <compartment-ocid> \
 --display-name "chave-dados-sensiveis" \
 --key-shape '{"algorithm": "AES", "length": 32}' \
 --management-endpoint <vault-management-endpoint>

# Armazenar secret (credencial de banco externo, API key, etc.)
oci vault secret create-base64 \
 --compartment-id <compartment-ocid> \
 --secret-name "db-senha-externa" \
 --vault-id <vault-ocid> \
 --key-id <chave-ocid> \
 --secret-content-content "$(echo -n 'SenhaExterna#123' | base64)"

O BASTION SERVICE dá acesso SSH em instância de subnet privada sem precisar abrir porta 22 para a internet. Você abre uma sessão com tempo definido, o OCI cria um túnel temporário, e pronto. A instância não precisa nem ter IP público.

# Criar Bastion
oci bastion bastion create \
 --bastion-type "STANDARD" \
 --compartment-id <compartment-ocid> \
 --target-subnet-id <subnet-privada-ocid> \
 --display-name "bastion-producao"

# Criar sessão SSH para instância específica
oci bastion session create-managed-ssh \
 --bastion-id <bastion-ocid> \
 --display-name "sessao-debug" \
 --target-resource-id <instance-ocid> \
 --target-os-username "opc" \
 --session-ttl-in-seconds 3600 \
 --ssh-public-key-file ~/.ssh/id_rsa.pub

CUSTOS E GOVERNANÇA

A Oracle tem dois modelos básicos de preço. No Pay-as-you-go você paga por hora ou por segundo, sem nenhuma fidelidade. Quanda acaba, acabou. Universal Credits é diferente - você se compromete com um volume mensal ou anual, ganha desconto sobre o PAYG e aplica o crédito onde quiser. Workload previsível de longo prazo compensa no Universal Credits. Agora, se estiver apenas testando alguma coisa que pode sumir amanhã, é bem mais tranquilo no PAYG mesmo.

Budgets servem pra você colocar um teto de gasto e receber alertas se estiver chegando no limite:

# Criar budget mensal de $500 com alerta em 80%
oci budgets budget create \
 --compartment-id <tenancy-ocid> \
 --display-name "budget-producao" \
 --amount 500 \
 --reset-period "MONTHLY" \
 --budget-processing-period-start-offset 0

# Criar regra de alerta no budget
oci budgets alert-rule create \
 --budget-id <budget-ocid> \
 --display-name "alerta-80-porcento" \
 --threshold 80 \
 --threshold-type "PERCENTAGE" \
 --type "ACTUAL" \
 --recipients "devops@empresa.com"

Tags? É o que separa "vou ter Cost Analysis útil de verdade" de "vou olhar o relatório sem entender nada". A verdade é: se você não taggear recurso por projeto, time e ambiente, daqui alguns meses fica impossível descobrir de onde veio cada centavo da fatura. Sem tags você acaba se perdendo.

# Aplicar tags a uma instância
oci compute instance update \
 --instance-id <instance-ocid> \
 --freeform-tags '{"projeto": "checkout", "time": "backend", "ambiente": "producao"}'

# Consultar custos por tag via Cost Analysis
oci usage-api usage-summary request-summarized-usages \
 --tenant-id <tenancy-ocid> \
 --time-usage-started "2026-04-01T00:00:00Z" \
 --time-usage-ended "2026-04-30T23:59:59Z" \
 --granularity "MONTHLY" \
 --query-type "COST" \
 --group-by '["tags/projeto"]'

PARTE 3 - O CURSO ONLINE E O RITMO DE ESTUDOS

A Oracle disponibiliza o learning path oficial no MyLearn, e tudo graça. O material cobre todos os domínios da prova: vídeo, demo e alguns labs. Quanto tempo no total? Umas 4 ou 5 horas.

Tem legenda em português, é bem produzido, é direto e cobre exataente o que cai. Se você já tem alguma experiência em outras clouds é quer ir um pouco mais rápido, dá para assistir os vídeos em 1,5x sem se perder.

SOBRE RITMO:

Quem vem de AWS, Azure ou GCP acha a OCI Foundations bem tranquila. A maioria dos conceitos tem equivalente direto. O que merece atenção mesmo? A terminologia da casa - Fault Domains, compartimentos, a sintaxe das policies do IAM, as variantes do Autonomous Database. Se vocë tem esse perfil, duas semanas de estudo leve resolvem.

Agora, pra quem está chegando no cloud agora, invista três ou quatro semanas. A primeira parte mergulhe conceitos gerais - região, zona, responsabilidade compartilhada, IaaS, PaaS, SaaS. Depois entre na parte específica do OCI. Uma hora por dia durante esse tempo é o suficiente pra chegar na prova com confiança.

IMPORTANTE: a versão 2025 (1Z0-1085-25) se aposenta em 15 de junho de 2026. Depois disso entra a 2026, também gratuita. Fez e passou antes de junho? A certificação vale do mesmo jeito, não importa qual versão você tirou.

PARTE 4 - PLANO DE ESTUDOS

SEMANA 1 - FUNDAMENTOS E ARQUITETURA

DIAS 1 E 2: Assista aos módulos "Getting Started with OCI" no MyLearn. Passe por região, AD, Fault Domain, tenancy e compartimento. Não decore nada - entenda por que a Oracle organizou assim mesmo e como isso muda a decisão de deploy.

DIAS 3 E 4: IAM do começo ao fim. Usuário, grupo, política, sintaxe das regras - tudo. Abra um tenancy de teste no Always Free e experimente criar grupos, política e compartimento direto no console. E quer saber do melhor? O Always Free é permanente - sem pedir cartão de crédito.

DIA 5: Revisão do que você viu na semana. Responda as questões de prática do MyLearn sobre esses tópicos - não pule.

SEMANA 2 - COMPUTE, NETWORKING E STORAGE

DIAS 1 E 2: Compute mesmo. Tipos de instância, shape Flex, quando faz sentido VM e quando faz sentido Bare Metal. Crie uma instância no seu ambiente de teste. OKE e Functions? Você precisa entender no conceito só - não precisa deployar cluster agora, mas saiba quando escolher cada um.

DIAS 3 E 4: Networking. VCN, subnet, os cinco gateways, quando usar cada um. Security List vs NSG cai bastante na prova, então gastar um tempo nisso aí fasz diferença, pode confiar. Suba uma VCN com subnet pública e privada no seu ambiente de teste.

DIA 5: Storage. Faça um mapa mental dos quatro tipos com seus casos de uso. Como isso cai na prova? Eles te dão um cenário e perguntam qual storage encaixa. Block Volume pra disco de instância, Object Storage pra arquivo e backup, File Storage pra acesso compartilhado entre instâncias, NVMe pra performance máxima e temporária.

SEMANA 3 - DATABASE, SEGURANÇA E CUSTOS

DIAS 1 E 2: Autonomous Database. Passe pelas quatro variantes (ATP, ADW, AJD, APEX), entenda o que "autonomous" quer dizer na prática, e saiba quando vale Autonomous e quando vale Base Database Service. Suba um ATP no Always Free - 1 OCPU, 20 GB, gratuito pra sempre.

DIAS 3 E 4: Segurança. Responsabilidade compartilhada, Cloud Guard, Security Zones, Vault e Bastion. Esses serviços são 25% da prova, então atenção. Saiba o que cada um faz e que problema cada um resolve.

DIA 5: Custos e Governance. Modelos de preço, Budget, Cost Analysis, Tag. É o domínio que menos cai na prova (10%), mas não ignora, pode fazer a diferença.

SEMANA 4 - REVISÃO E SIMULADOS

DIAS 1 E 2: Volte nos tópicos onde você foi pior nas questões da semana passada. Não perca tempo com o que você já domina.

DIAS 3 E 4: Faça dois simulados completos, cronometrados - de verdade. O MyLearn tem um practice exam. ExamTopics e Oracle University também têm questões. Anote em quais tópicos você errou mais e por quê.

DIA 5: Revisão final, focada só nos pontos fracos dos simulados. Não tente revisar a prova inteira do zero - é perda de tempo. Priorize o que tem peso: Core Services e Security somam 75%.

MARCAR A PROVA: em algum momento da semana 3 ou 4. Ter data definida ajuda a manter o ritmo do estudo.

PARTE 5 - POR QUE ESSA CERTIFICAÇÃO É IMPORTANTE

A OCI Foundations não é uma certificação extremamente técnica. Ninguém vai te chamar pra fazer arquitetura de infra só porque você passou nela. Mas ela é importante: te entrega o mapa da plataforma inteira antes de você tentar navegar no escuro.

Quem aprende cloud aos poucos, só quando é cobrado, acaba com vários furos. Aprende o equivalente do EC2, aprende o equivalente do Object Storage, aprende IAM quando aparece um problema de permissão. Depois, meses depois mesmo, descobre que existia um Service Gateway que teria cortado custo de egress, que o Bastion Service teria eliminado aquela gambiarra ou que o Autonomous Database tinha uma variante AJD que simplificava tudo.

Essa prova fecha esses buracos de forma organizada. E o melhor? Não custa nada. O investimento é só tempo mesmo.

Se você quer seguir na trilha Oracle (OCI Architect Associate, OCI Developer Associate), a Foundations também dá aquela base necessária. As provas mais avançadas assumem que você conhece o básico que essa cobre. Dá pra pular direto, claro - mas aí você acaba estudando duas certificações ao mesmo tempo sem ter planejado.

O prazo? 15 de junho de 2026. Depois disso entra a 2026, também gratuita. Mesmo assim, melhor focar e tirar a versão atual. O conteúdo deve mudar então para que esperar mais?

É só seguir esse plano, estudar e você vai estar preparado a tempo de conseguir sua primeira certificação da Oracle. E depois exibir sua badge no Linkedin.