最新 [2026年07月28日]RedHat EX380試験練習でテストの素晴らしい結果を出そう
あなたのキャリアーを稼いで飛躍せよRedHat EX380
RedHat EX380 認定試験の出題範囲：
| トピック | 出題範囲 |
|---|---|
| トピック 1 |
|
| トピック 2 |
|
| トピック 3 |
|
| トピック 4 |
|
| トピック 5 |
|
| トピック 6 |
|
質問 # 16
Identity Management - Create CA ConfigMap
正解：
解説：
See the solution below in Explanation:
Explanation:
Step 1: Ensure the certificate file rhds_ca.crt is available in your current working directory or use the correct path.
The Task requires creating a configmap from this CA certificate file.
Step 2: Run the command:
oc create configmap rhds-ca-config-map --from-file ca.crt=rhds_ca.crt -n openshift-config Step 3: Confirm the configmap is created.
The lab output shows:
configmap/rhds-ca-config-map created
Detailed explanation:
This creates a configmap named rhds-ca-config-map in the openshift-config namespace and maps the local file rhds_ca.crt to the key name ca.crt inside the configmap. This is important in external identity integration because OpenShift may need to trust a custom certificate authority when communicating with LDAP or another secured external service. By placing the certificate in a configmap, the authentication operator or related cluster configuration can reference it cleanly. The key name matters because many OpenShift resources expect a CA bundle key with a specific filename-like convention. If the file path is wrong, the command fails immediately. If the configmap name or key mapping is wrong, the authentication provider referencing it may not trust the external endpoint.
質問 # 17
Export and import a Kubernetes application (YAML export)
Task Information : Export typical app objects from orders and apply them into a new namespace orders- copy.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Export objects to YAML
* oc -n orders get deploy,svc,route,cm,secret -o yaml > orders-app.yaml
* Exports key application resources.
* Create target namespace
* oc new-project orders-copy
* Apply exported YAML
* oc -n orders-copy apply -f orders-app.yaml
* Recreates resources (some fields may need adjustment, like namespaces or immutable fields).
* Validate
* oc -n orders-copy get all
質問 # 18
Maintain group synchronization on a schedule (CronJob)
Task Information : Create a CronJob that runs LDAP group sync on a schedule using a service account that has the required permissions.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Create a namespace for the sync job
* oc new-project id-sync
* Keeps the automation components organized.
* Create a service account for the sync job
* oc -n id-sync create sa group-sync
* CronJob runs under this SA identity.
* Grant cluster permissions to manage groups
* oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:id-sync:group-sync
* In real environments you should scope down, but lab Task SIMULATIONs often accept cluster- admin for speed.
* Create a ConfigMap for groupsync.yaml and Secret(s) for bind password/CA
* Mount them into the job container.
* Create CronJob to run group sync
* Command inside job:
* oc adm groups sync --sync-config=/config/groupsync.yaml --confirm
* The CronJob ensures periodic reconciliation with LDAP.
* Verify job runs
* oc -n id-sync get cronjob
* oc -n id-sync get jobs
* oc -n id-sync logs job/ < job-name >
質問 # 19
Deploy Event Router and capture Kubernetes events in logging
Task Information : Deploy an event router so Kubernetes events are recorded as logs, then trigger events and confirm they appear in logging queries.
正解：
解説：
See the solution below in Explanation:
* Deploy event router resources
* Apply a deployment/serviceaccount/rolebinding manifest for eventrouter:
* oc apply -f eventrouter.yaml -n openshift-logging
* Eventrouter watches event API and writes them to stdout (collected by logging).
* Verify eventrouter pod is running
* oc -n openshift-logging get pods | grep -i event
* Trigger some events
* oc -n default run evtest --image=busybox --restart=Never -- sleep 1
* oc -n default delete pod evtest
* Creation/deletion generates events.
* Query logs for events
* In the logging UI/backend, search for the namespace/pod name evtest or eventrouter messages.
* Explanation: Validates that events are being converted to searchable logs.
質問 # 20
Create an Argo CD Application (OpenShift GitOps)
Task Information : Create an Argo CD Application that syncs from Git into namespace gitops-demo with automated sync enabled.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Create target namespace
* oc new-project gitops-demo
* Destination must exist (unless Argo is configured to auto-create).
* Create Application manifest
* apiVersion: argoproj.io/v1alpha1
* kind: Application
* metadata:
* name: demo-app
* namespace: openshift-gitops
* spec:
* project: default
* source:
* repoURL: https://git.example.com/org/repo.git
* targetRevision: main
* path: manifests/demo
* destination:
* server: https://kubernetes.default.svc
* namespace: gitops-demo
* syncPolicy:
* automated:
* prune: true
* selfHeal: true
* automated: enables auto sync.
* prune: removes deleted objects from Git.
* selfHeal: corrects drift.
* Apply Application
* oc apply -f demo-app.yaml
* Verify sync health
* oc -n openshift-gitops get application demo-app -o yaml | grep -i -E "sync|health" -n
* oc -n gitops-demo get all
質問 # 21
Create and use client certificates with kubeconfig (CSR flow)
Task Information : Generate a client key/CSR for audit2, approve it, extract the signed cert, and build a kubeconfig using that cert.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Generate private key and CSR
* openssl genrsa -out audit2.key 2048
* openssl req -new -key audit2.key -out audit2.csr -subj "/CN=audit2/O=auditors"
* CN becomes username; O can map to groups in some setups.
* Base64 encode CSR for the API object
* CSR=$(base64 -w0 audit2.csr)
* Kubernetes CSR object expects base64-encoded request data.
* Create the CSR object
* cat < < EOF | oc apply -f -
* apiVersion: certificates.k8s.io/v1
* kind: CertificateSigningRequest
* metadata:
* name: audit2-csr
* spec:
* request: ${CSR}
* signerName: kubernetes.io/kube-apiserver-client
* usages:
* - client auth
* EOF
* Approve the CSR
* oc adm certificate approve audit2-csr
* Approval triggers certificate issuance.
* Extract the signed certificate
* oc get csr audit2-csr -o jsonpath='{.status.certificate}' | base64 -d > audit2.crt
* Produces the client certificate file.
* Build kubeconfig using cert/key
* oc config set-credentials audit2 \
* --client-certificate=audit2.crt --client-key=audit2.key \
* --embed-certs=true --kubeconfig=audit2.kubeconfig
* oc config set-cluster lab \
* --server="$(oc whoami --show-server)" \
* --insecure-skip-tls-verify=true \
* --kubeconfig=audit2.kubeconfig
* oc config set-context audit2 \
* --cluster=lab --user=audit2 --namespace=default \
* --kubeconfig=audit2.kubeconfig
* Creates a kubeconfig that authenticates using client certificates.
* Test
* oc --kubeconfig=audit2.kubeconfig get ns
質問 # 22
Configure project-wide default tolerations
Task Information : Configure the payments namespace so new pods automatically include a default toleration.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Annotate the namespace with default tolerations
* oc annotate ns payments \
* scheduler.alpha.kubernetes.io/defaultTolerations='[{"key":"dedicated","operator":"Equal","value":" payments","effect":"NoSchedule"}]' \
* --overwrite
* Some clusters honor this pattern; if not, the fallback is mutating admission or editing workloads.
* Create a new pod/deployment in the namespace
* Then verify its spec includes tolerations:
* oc -n payments get pod < pod > -o yaml | grep -n tolerations -A5
質問 # 23
Identity Management - Create HTPasswd Secret
正解：
解説：
See the solution below in Explanation:
Explanation:
Step 1: Open a terminal with oc access to the cluster.
This Task is CLI-driven and targets the openshift-config namespace.
Step 2: Run the command:
oc create secret generic rhds-ldap-secret --from-literal bindPassword=redhatocp -n openshift-config Step 3: Verify that the secret is created successfully.
The lab output shows:
secret/rhds-ldap-secret created
Detailed explanation:
This step creates a generic secret named rhds-ldap-secret in the openshift-config namespace. The secret stores a key called bindPassword with the value redhatocp. In an identity-provider or LDAP integration workflow, the bind password is used by OpenShift when connecting to the external directory service. Storing this value in a secret is the correct operational pattern because authentication material should not be embedded directly into configuration objects. The openshift-config namespace is specifically important because cluster authentication configuration commonly references secrets and configmaps from that namespace. If the secret name or key is wrong, the authentication configuration that depends on it may fail to validate or connect properly.
質問 # 24
Spread replicas using podAntiAffinity
Task Information : Configure payments/api to prefer scheduling pods on different nodes.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Patch deployment with preferred podAntiAffinity
* oc -n payments patch deploy api --type=merge -p '{
* "spec":{"template":{"spec":{"affinity":{
* "podAntiAffinity":{
* "preferredDuringSchedulingIgnoredDuringExecution":[{
* "weight":100,
* "podAffinityTerm":{
* "labelSelector":{"matchLabels":{"app":"api"}},
* "topologyKey":"kubernetes.io/hostname"
* }
* }]
* }
* }}}}
* }'
* Encourages spread across nodes to reduce single-node impact.
* Verify spread
* oc -n payments get pods -o wide
質問 # 25
Kubeconfig Management - Use Context
正解：
解説：
See the solution below in Explanation:
Explanation:
Step 1: Make sure the context already exists in the kubeconfig file.
This follows the context creation Task SIMULATION .
Step 2: Run the command:
oc config use-context audit --kubeconfig audit.config
Step 3: Confirm the active context switches successfully.
The lab output shows:
Switched to context "audit".
Detailed explanation:
This command activates the audit context inside the specified kubeconfig file. Once selected, subsequent oc commands using that kubeconfig will default to the cluster, user, and namespace associated with that context.
This is operationally important because many administration mistakes come from running commands against the wrong cluster or project. Using explicit context switching reduces that risk and makes the kubeconfig usable for the intended audit workflow. In exams and real environments alike, the context is what turns separate kubeconfig elements into a working session configuration. Without switching to the correct context, even a well-formed kubeconfig may not be used as expected.
質問 # 26
Create and apply a MachineConfig (set MOTD on workers)
Task Information : Create a MachineConfig that writes /etc/motd on worker nodes.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Create the MachineConfig YAML (example content encoded in base64)
* apiVersion: machineconfiguration.openshift.io/v1
* kind: MachineConfig
* metadata:
* name: 99-worker-motd
* labels:
* machineconfiguration.openshift.io/role: worker
* spec:
* config:
* ignition:
* version: 3.2.0
* storage:
* files:
* - path: /etc/motd
* mode: 0644
* contents:
* source: data:text/plain;charset=utf-8;base64,VGhpcyBpcyBhIHdvcmtlciBub2RlLg==
* MachineConfig uses Ignition format; file content is typically base64.
* Apply it
* oc apply -f 99-worker-motd.yaml
* Watch worker MachineConfigPool roll out
* oc get mcp worker
* MCP will show Updating then Updated.
* Validate on a worker node (if you have node access)
* Confirm /etc/motd contains the expected text.
質問 # 27
Configure BackupStorageLocation and VolumeSnapshotLocation
Task Information : Configure OADP/Velero storage locations and confirm they show as Available.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Create a secret for cloud credentials (S3-compatible example)
* oc -n openshift-adp create secret generic cloud-credentials \
* --from-file=cloud=/path/to/credentials
* Velero uses this secret to authenticate to object storage.
* Create/Update the DataProtectionApplication (DPA)
* Apply a DPA CR that defines:
* backupLocations (bucket, endpoint URL, region, etc.)
* snapshotLocations (if using snapshots)
* Verify BackupStorageLocation and SnapshotLocation
* velero backup-location get
* velero snapshot-location get
* Status should be Available, meaning storage config is valid.
==========
質問 # 28
GitOps and MachineConfig - Push MachineConfig to Git
正解：
解説：
See the solution below in Explanation:
Explanation:
Step 1: Make sure the MachineConfig YAML has already been created or modified in the local Git repository.
This Task assumes the file change is ready to be committed.
Step 2: Run the command:
git commit -am "Add MachineConfig for motd" & & git push origin main
Step 3: Verify the commit succeeds and the push goes to the main branch.
The lab output shows:
[main 8d32a1] Add MachineConfig for motd
Detailed explanation:
This Task is part of a GitOps workflow. Instead of manually applying changes directly to the cluster, the desired configuration is stored in Git, and a GitOps controller such as Argo CD synchronizes the cluster to match the repository state. The command commits all tracked modified files with the message Add MachineConfig for motd and then pushes the change to the main branch. In this model, Git becomes the source of truth. A MachineConfig is typically used to manage node-level operating system configuration in OpenShift, so pushing it through GitOps ensures the change is auditable, repeatable, and reconciled declaratively. If the commit does not include the intended YAML, the synchronization mechanism will not apply the desired change.
質問 # 29
Configure log forwarding to an external endpoint
Task Information : Configure Cluster Logging to forward application logs to an external output using ClusterLogForwarder.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Verify logging namespace and resources
* oc get ns openshift-logging
* oc -n openshift-logging get clusterlogforwarder
* ClusterLogForwarder configures pipelines and outputs.
* Create/Edit ClusterLogForwarder (example structure)
* Define an output (external system) and pipeline selecting application logs.
* Apply via YAML:
* oc -n openshift-logging apply -f clusterlogforwarder.yaml
* Validate collector pods are healthy
* oc -n openshift-logging get pods
* Forwarding relies on collectors (vector/fluentd depending config).
* Generate a test log line
* oc -n openshift-logging run logger --image=busybox --restart=Never -- /bin/sh -c 'echo hello- forwarding; sleep 5'
* This creates a known message to search in the external endpoint.
* Confirm logs arrive at destination
* Use your external system's query/search to confirm hello-forwarding.
質問 # 30
Install OADP Operator and verify Velero components
Task Information : Install the OADP operator and confirm Velero pods/components are running.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Install OADP via Web Console
* Operators # OperatorHub # search OADP / OpenShift API for Data Protection # Install
* Explanation: This operator manages Velero and backup integrations.
* Verify the operator CSV is installed
* oc get csv -A | grep -i -E "oadp|data protection|velero"
* Confirms installation succeeded.
* Verify pods in the OADP namespace (commonly openshift-adp)
* oc get pods -n openshift-adp
* You should see Velero/OADP-related pods in Running state.
質問 # 31
Node Management - Remove Taint on Worker Node
正解：
解説：
See the solution below in Explanation:
Explanation:
Step 1: Log in to the OpenShift web console with an account that has sufficient cluster administrative privileges.
This Task is performed from the GUI, not the CLI. The lab hint explicitly places this under the worker node details page in the console.
Step 2: Navigate to Compute .
This area contains node-level resources, including control plane and worker nodes.
Step 3: Open Nodes .
Here you can view all nodes currently registered in the cluster.
Step 4: Select the required worker node .
Choose the exact worker node referenced by the lab Task SIMULATION .
Step 5: Open the Details tab.
The taint configuration is managed from the selected node's details view.
Step 6: Locate the Taints section and click Edit .
A taint is used to control pod scheduling. If a worker has a taint, pods without matching tolerations may not schedule there.
Step 7: Remove the unwanted taint entry.
Removing the taint makes the worker eligible again for normal scheduling behavior, depending on the rest of the cluster policy.
Step 8: Click Save .
This commits the change so the node is updated and the scheduler can evaluate it without that taint.
質問 # 32
Schedule a recurring backup
Task Information : Create a daily backup schedule for namespace orders at 01:00.
正解：
解説：
See the solution below in Explanation:
Explanation:
* Create the schedule
* velero schedule create orders-daily \
* --schedule "0 1 * * *" \
* --include-namespaces orders \
* --snapshot-volumes
* Cron format: minute hour day month weekday.
* Verify schedule exists
* velero schedule get
* Confirm backups are created by the schedule
* velero backup get | grep orders-daily
* Scheduled backups usually have names derived from the schedule.
質問 # 33
......
正真正銘のベスト資料EX380オンライン練習試験：https://www.goshiken.com/RedHat/EX380-mondaishu.html