Free HPE0-G04 sample questions

Correct answer: By abstracting the underlying clouds through agnostic instance types and layouts, allowing a single workflow to target multiple clouds.

Morpheus solves the challenge of fragmented automation by providing cloud-agnostic abstractions (Instance Types, Layouts, and Node Types). This allows administrators to define a workload once and deploy it across disparate cloud environments using a unified provisioning workflow. flowchart LR A[Self-Service Request] --> B[Morpheus Abstraction Layer] B -->|Layout 1| C[VMware vCenter] B -->|Layout 2| D[AWS EC2] B -->|Layout 3| E[Azure Compute]

Correct answers: RabbitMQ; OpenSearch

RabbitMQ is the appliance's embedded messaging tier. The `morpheus-ctl` command can start, stop or restart it alone, for example with `morpheus-ctl restart rabbitmq`.

OpenSearch is the appliance's embedded logs and metrics store, replacing Elasticsearch from 8.1.0. The `morpheus-ctl` command can start, stop or restart it on its own.

Correct answer: morpheus.rb

The `morpheus.rb` file located in `/etc/morpheus/` is the central configuration file for the appliance. After making changes to this Ruby-based configuration file, administrators must run `morpheus-ctl reconfigure` to apply the settings.

Correct answer: morpheus-ctl reconfigure

The documented procedure copies the key and certificate to /etc/morpheus/ssl/ and sets nginx['ssl_certificate'] and nginx['ssl_server_key'] in /etc/morpheus/morpheus.rb. Then you 'reconfigure the appliance and restart nginx': `morpheus-ctl reconfigure` followed by `morpheus-ctl restart nginx`. The reconfigure step is what regenerates the NGINX configuration from morpheus.rb. NGINX is managed by morpheus-ctl, not by `systemctl restart nginx`, restarting only morpheus-ui does not apply the certificate, and there is no `morpheus-ssl` command.

Correct answer: To act as a logical boundary for organizing Clouds and applying RBAC and Policies.

Infrastructure Groups in Morpheus serve as logical containers. They organize underlying Cloud integrations into manageable boundaries, making it easier to apply Role-Based Access Control (RBAC) and governance Policies across multiple environments.

Correct answer: Create two Groups: 'Internal-Dev' and 'Customer-Prod'. Add the vCenter and AWS integrations twice—once to each Group—scoping each Cloud integration to the specific vCenter cluster/Resource Pool and AWS VPC used by that environment.

To ensure strict separation and least privilege, create distinct Infrastructure Groups for each environment and add a separately scoped Cloud integration to each. A vCenter cloud integration "is scoped to a specific data center, and can optionally be scoped down to a single cluster or even a single resource pool", and an AWS cloud can be pointed at one selected VPC instead of All VPCs. The Configuring Access guide uses exactly this pattern (the same Azure account integrated several times, each Cloud scoped to one resource group and added to its own Group); Roles then grant users access only to their Group. graph TD subgraph Morpheus Groups G1[Internal-Dev Group] G2[Customer-Prod Group] end subgraph Cloud Integrations C1[vCenter - Dev Cluster] C2[AWS - Dev VPC] C3[vCenter - Prod Cluster] C4[AWS - Prod VPC] end G1 --> C1 G1 --> C2 G2 --> C3 G2 --> C4