A company runs its ML workflows on an on-premises Kubernetes cluster. The ML workflows include ML services that perform training and inferences for ML models. Each ML service runs from its own…

Question

Options

• ARedesign the ML services to be configured in Kubeflow. Deploy the new Kubeflow managed ML
• BUpload the Docker images to an Amazon Elastic Container Registry (Amazon ECR) repository.
• CMigrate the training data to an Amazon Redshift cluster. Retrain the models from the migrated
• DConfigure an Amazon SageMaker AI notebook. Retrain the models with the same code. Deploy

• B
  95% (55)
• C
  3% (2)
• D
  2% (1)

Explanation

A lift-and-shift migration means moving workloads to the cloud with minimal architectural changes. Since the ML services already run as standalone Docker images on Kubernetes, the path of least resistance is to push those existing images to Amazon ECR (a managed container registry) and redeploy them on Amazon EKS, which is AWS's managed Kubernetes service. The workloads run on the same containerized architecture with virtually no code changes. Redesigning for Kubeflow (A) requires significant re-engineering. Migrating to Redshift and retraining (C) completely changes the architecture. Switching to SageMaker notebooks (D) abandons the container-based approach entirely - all three alternatives contradict the lift-and-shift requirement.

No community discussion yet for this question.