Pular para o conteúdo principal

Laboratório Técnico: Perform a Failover to a Secondary Region by Using Site Recovery

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de operações precisa validar o plano de recuperação antes de um evento real. O ambiente de produção não pode ser interrompido e as VMs replicadas devem permanecer protegidas ao final do processo.

Qual tipo de operação do Azure Site Recovery atende a esse requisito?

A) Failover planejado, porque interrompe a replicação temporariamente mas preserva o ambiente de origem.

B) Failover de teste, porque executa o failover em uma rede isolada sem afetar a replicação em andamento.

C) Failover não planejado, porque pode ser executado sem confirmação e revertido imediatamente.

D) Failback, porque move as cargas de trabalho de volta à região primária sem impacto na replicação.

Questão 2 — Cenário Técnico​

Um administrador executa um failover não planejado de uma VM crítica para a região secundária. Após confirmar que os sistemas estão operacionais na região secundária, ele precisa garantir que a VM da região primária não interfira nas operações e que a replicação inversa seja configurada.

Qual é a sequência correta de ações após o failover bem-sucedido?

A) Excluir a VM da região primária, reconfigurar o vault e criar uma nova política de replicação.

B) Executar "Commit" no failover e, em seguida, habilitar a replicação inversa para proteger a VM na nova região primária.

C) Executar "Failback" imediatamente para a região original e, em seguida, reativar a replicação.

D) Executar "Re-protect" sem antes confirmar o failover, pois o commit é opcional em failovers não planejados.

Questão 3 — Verdadeiro ou Falso​

Durante um failover de teste no Azure Site Recovery, as máquinas virtuais iniciadas na região secundária utilizam os mesmos endereços IP das VMs de produção, o que pode causar conflito de rede se a rede de teste não estiver isolada da rede de produção.

Questão 4 — Cenário Técnico​

Um administrador configura um Recovery Plan no Azure Site Recovery para orquestrar o failover de uma aplicação com três camadas: banco de dados, back-end e front-end. Durante um failover de teste, o front-end sobe antes do banco de dados, causando falhas de inicialização.

Recovery Plan — ordem atual:
  Group 1: frontend-vm
  Group 2: backend-vm
  Group 3: database-vm

Qual é a causa do problema e como corrigi-lo?

A) O Recovery Plan não suporta mais de dois grupos. A solução é separar a aplicação em dois planos distintos.

B) A ordem dos grupos está invertida. O banco de dados deve estar no Group 1 para iniciar primeiro, seguido de back-end e front-end.

C) O problema é a ausência de scripts de validação. A ordem dos grupos não influencia a sequência de inicialização das VMs.

D) Groups em um Recovery Plan são sempre executados em paralelo, portanto a ordem não pode ser controlada por esse mecanismo.

Questão 5 — Múltipla Escolha​

Após um failover bem-sucedido para a região secundária, a equipe decide que a região secundária será o novo ambiente de produção permanente. Qual afirmação descreve corretamente o que ocorre com a replicação nesse cenário?

A) A replicação original continua automaticamente no sentido oposto, protegendo a nova região primária assim que o failover é concluído.

B) A replicação é pausada após o failover e deve ser reativada manualmente por meio da operação "Re-protect", que inverte a direção da replicação.

C) A replicação é encerrada permanentemente após o commit do failover e não pode ser reestabelecida sem recriar o vault.

D) O failover confirma a replicação existente e a mantém ativa no mesmo sentido, protegendo a região primária original.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O failover de teste é o mecanismo projetado exatamente para validação sem impacto. Ele cria VMs na região secundária dentro de uma rede isolada especificada pelo administrador, de modo que a replicação em andamento não é interrompida e a VM de produção original permanece ativa e protegida.

O failover planejado (A) interrompe a replicação e desliga a VM de origem antes de iniciar o failover, sendo indicado para migrações controladas. O failover não planejado (C) é destinado a desastres reais e, embora possa ser revertido via "Discard", não é a abordagem para validação segura. O failback (D) pressupõe que já ocorreu um failover e tem direção oposta ao que a questão descreve.

Gabarito — Questão 2​

Resposta: B

Após um failover não planejado, o fluxo correto é: primeiro Commit, que finaliza o failover, descarta os pontos de recuperação anteriores e sinaliza ao Site Recovery que a região secundária é agora a ativa; depois Re-protect (replicação inversa), que passa a replicar da nova região primária de volta para a original.

A alternativa D representa um equívoco crítico: o "Re-protect" só pode ser executado após o commit. Sem o commit, o failover está em estado pendente e a replicação inversa não pode ser configurada. A alternativa C inverte a lógica ao propor failback imediato antes de estabilizar o ambiente. A alternativa A é destrutiva e desnecessária; o vault e as políticas não precisam ser recriados.

Gabarito — Questão 3​

Resposta: Verdadeiro

Essa afirmação é verdadeira. Por padrão, o Site Recovery tenta preservar os endereços IP das VMs durante o failover. Se a rede usada no failover de teste não for isolada da rede de produção, haverá conflito de IP, podendo causar instabilidade em ambas as VMs. Por isso, a Microsoft recomenda sempre criar uma rede virtual dedicada e isolada para testes de failover. Esse comportamento é um ponto de atenção frequentemente negligenciado em ambientes onde a rede de teste não é planejada adequadamente.

Gabarito — Questão 4​

Resposta: B

Em um Recovery Plan, os grupos são executados sequencialmente: o Group 1 inicia primeiro, depois o Group 2, e assim por diante. A configuração apresentada coloca o front-end no Group 1, fazendo-o subir antes do banco de dados, o que gera as falhas descritas. A correção é reorganizar os grupos colocando o banco de dados no Group 1, o back-end no Group 2 e o front-end no Group 3.

A alternativa C nega o funcionamento fundamental dos grupos, que sim controlam a ordem. A alternativa D confunde o comportamento dos grupos com o comportamento de VMs dentro de um mesmo grupo, que sobem em paralelo. A alternativa A é factualmente incorreta; Recovery Plans suportam múltiplos grupos.

Gabarito — Questão 5​

Resposta: B

Após o commit de um failover, a replicação é interrompida. O Azure Site Recovery não inverte a direção automaticamente. O administrador precisa executar a operação Re-protect, que reconfigura a replicação no sentido inverso, ou seja, da nova região primária para a antiga. Sem essa ação, a VM que passou a ser produção na região secundária não está protegida contra falhas.

A alternativa A representa o equívoco mais comum: assumir que o Site Recovery gerencia a inversão de replicação de forma automática. A alternativa C está errada porque o vault e a capacidade de replicação são preservados após o commit. A alternativa D contradiz o comportamento real, pois a replicação original é encerrada no momento do commit.