EX380 無料問題集「RedHat Red Hat Certified Specialist in OpenShift Automation and Integration」
Backup and Restore - Fix SCC for Restored Application
正解：
See the solution below in Explanation:
Explanation:
Step 1: Identify the application namespace after restore.
The lab shows the namespace as my-app-namespace.
Step 2: Run the SCC assignment command:
oc adm policy add-scc-to-user anyuid -z default -n my-app-namespace
Step 3: Confirm the role binding is applied.
The lab output shows:
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default" Detailed explanation:
After a restore, the application may fail if its pods require a security context not permitted by the default SCC allocation. This command grants the anyuid SCC to the default service account in the my-app-namespace project. The -z default syntax targets the default service account, which many restored workloads use if no custom service account is defined. The anyuid SCC allows containers to run with arbitrary user IDs, which some legacy or prebuilt images require. In OpenShift, SCC mismatches commonly cause pods to remain in pending or crash-related states. Assigning the proper SCC resolves those admission issues so workloads can start successfully. This step is therefore a post-restore operational fix to align security policy with application requirements.
Explanation:
Step 1: Identify the application namespace after restore.
The lab shows the namespace as my-app-namespace.
Step 2: Run the SCC assignment command:
oc adm policy add-scc-to-user anyuid -z default -n my-app-namespace
Step 3: Confirm the role binding is applied.
The lab output shows:
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default" Detailed explanation:
After a restore, the application may fail if its pods require a security context not permitted by the default SCC allocation. This command grants the anyuid SCC to the default service account in the my-app-namespace project. The -z default syntax targets the default service account, which many restored workloads use if no custom service account is defined. The anyuid SCC allows containers to run with arbitrary user IDs, which some legacy or prebuilt images require. In OpenShift, SCC mismatches commonly cause pods to remain in pending or crash-related states. Assigning the proper SCC resolves those admission issues so workloads can start successfully. This step is therefore a post-restore operational fix to align security policy with application requirements.
Silence an alert in Alertmanager
Task Information : Create an Alertmanager silence for a noisy alert for 2 hours, then confirm it's silenced.
Task Information : Create an Alertmanager silence for a noisy alert for 2 hours, then confirm it's silenced.
正解：
See the solution below in Explanation:
Explanation:
* Find the alert name and labels
* Web console: Observe # Alerts # click the alert to view label set.
* Open Alertmanager silences
* Observe # Alerting # Alertmanager # Silences # Create silence
* Explanation: Silences mute alerts matching label filters.
* Create the silence
* Add matcher: alertname = < ALERT_NAME >
* Duration: 2 hours
* Save.
* Verify the alert shows as silenced
* The alert should indicate it is silenced in the UI.
Explanation:
* Find the alert name and labels
* Web console: Observe # Alerts # click the alert to view label set.
* Open Alertmanager silences
* Observe # Alerting # Alertmanager # Silences # Create silence
* Explanation: Silences mute alerts matching label filters.
* Create the silence
* Add matcher: alertname = < ALERT_NAME >
* Duration: 2 hours
* Save.
* Verify the alert shows as silenced
* The alert should indicate it is silenced in the UI.
Backup and Restore - Restore Application from Existing Backup
正解：
See the solution below in Explanation:
Explanation:
Step 1: Make sure Velero is installed and configured in the environment.
The Task SIMULATION assumes an existing backup named backup-app-daily is already present.
Step 2: Run the restore command:
velero restore create --from-backup backup-app-daily
Step 3: Confirm the restore request is submitted.
The lab output shows:
Restore request "backup-app-daily-2024" submitted successfully.
Detailed explanation:
This command instructs Velero to create a restore operation using the existing backup called backup-app- daily. Velero is commonly used to protect Kubernetes and OpenShift resources by backing up object definitions and, when configured, persistent data integrations. The command does not manually recreate resources one by one; instead, it leverages the metadata captured during backup. A successful restore submission means the request has been accepted, not necessarily that every object has already been fully restored. In practical administration, you would often follow this by checking restore status and validating the application namespace, pods, services, routes, and storage bindings. This lab Task SIMULATION focuses specifically on initiating the restore from the named backup source.
Explanation:
Step 1: Make sure Velero is installed and configured in the environment.
The Task SIMULATION assumes an existing backup named backup-app-daily is already present.
Step 2: Run the restore command:
velero restore create --from-backup backup-app-daily
Step 3: Confirm the restore request is submitted.
The lab output shows:
Restore request "backup-app-daily-2024" submitted successfully.
Detailed explanation:
This command instructs Velero to create a restore operation using the existing backup called backup-app- daily. Velero is commonly used to protect Kubernetes and OpenShift resources by backing up object definitions and, when configured, persistent data integrations. The command does not manually recreate resources one by one; instead, it leverages the metadata captured during backup. A successful restore submission means the request has been accepted, not necessarily that every object has already been fully restored. In practical administration, you would often follow this by checking restore status and validating the application namespace, pods, services, routes, and storage bindings. This lab Task SIMULATION focuses specifically on initiating the restore from the named backup source.
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.
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 >
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 >
Kubeconfig Management - Set Credentials in Kubeconfig
正解：
See the solution below in Explanation:
Explanation:
Step 1: Ensure the client certificate and private key files are available.
The lab uses audit.crt and tls.key.
Step 2: Run the command:
oc config set-credentials audit --client-certificate audit.crt --client-key tls.key --embed-certs --kubeconfig audit.config Step 3: Confirm the user entry is written.
The lab output shows:
User "audit" set.
Detailed explanation:
This command creates or updates the audit user entry inside the kubeconfig file audit.config. It points the user to a client certificate and private key, and the --embed-certs option stores certificate material directly inside the kubeconfig rather than only referencing external files. That makes the kubeconfig more portable because it can be moved and used without separately copying the certificate files, provided the embedded content is valid. In certificate-based authentication, the private key proves client possession while the certificate presents the approved identity. If the certificate and key do not match, authentication will fail. This step does not yet define what cluster or namespace the user works against; it only defines the credential identity.
Explanation:
Step 1: Ensure the client certificate and private key files are available.
The lab uses audit.crt and tls.key.
Step 2: Run the command:
oc config set-credentials audit --client-certificate audit.crt --client-key tls.key --embed-certs --kubeconfig audit.config Step 3: Confirm the user entry is written.
The lab output shows:
User "audit" set.
Detailed explanation:
This command creates or updates the audit user entry inside the kubeconfig file audit.config. It points the user to a client certificate and private key, and the --embed-certs option stores certificate material directly inside the kubeconfig rather than only referencing external files. That makes the kubeconfig more portable because it can be moved and used without separately copying the certificate files, provided the embedded content is valid. In certificate-based authentication, the private key proves client possession while the certificate presents the approved identity. If the certificate and key do not match, authentication will fail. This step does not yet define what cluster or namespace the user works against; it only defines the credential identity.