Explanation: Enforcing complex passwords improves account security, reducing the risk of unauthorized access. Grant a group permission to manage all resources within a specific namespace. Validate their access. ee the Solution below. Solution: 1. Create a group and add users: oc adm groups new namespace -admins oc adm groups add -users namespace -admins user1 user2 2. Assign the admin role to the group for a specific namespace: oc adm policy add -role-to-group admin namespace -admins -n dev -namespace 3. Validate access: oc auth can -i create pods -n dev -namespace --as=user1 Explanation: Assigning namespace -specific roles ensures that group members have the necessary permissions without granting excessive privileges cluster -wide. Revoke a user's ability to delete resources within a namespace while retaining other permissions. Validate the restricted access. ee the Solution below. Solution: 1. Create a custom role that excludes delete permissions: oc create role restricted -role --verb=get,list,create,update --resource=pods,services -n dev -namespace 2. Bind the role to the user: oc create rolebinding restricted -binding --role=restricted -role --user=user1 -n dev -namespace
3. Validate restricted access: oc auth can -i delete pods -n dev -namespace --as=user1 Explanation: Custom roles provide granular control over user permissions, allowing precise enforcement of security policies. Set up an OAuth identity provider to integrate with an external authentication service. Validate user login through the external provider. ee the Solution below. Solution: 1. Edit the OAuth configuration to include the external identity provider: apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: external -idp type: OpenID mappingMethod: claim openID: clientID: my-client -id clientSecret: name: my-client -secret claims: preferredUsername: - email name: - name email: - email urls: authorize: https://idp.example.com/authorize token: https://idp.example.com/token userInfo: https://idp.example.com/userinfo 2. Apply the configuration: oc apply -f oauth -config.yaml
Explanation: Deploying across namespaces ensures workload isolation while reusing common configurations. Verification confirms that resources are created and operational. Simulate and troubleshoot a pod network issue where a pod cannot communicate with a service in the same namespace. Provide steps to identify and resolve the problem. ee the Solution below. Solution: 1. Check the pod's DNS resolution: kubectl exec <pod -name> -- nslookup <service -name> 2. Verify service and endpoint configuration: kubectl get svc kubectl describe svc <service -name> kubectl get endpoints 3. Diagnose network policies: kubectl get networkpolicy 4. Resolve by updating or removing problematic network policies. Explanation: Pod network issues can stem from DNS, service misconfigurations, or restrictive network policies. Systematic diagnosis ensures efficient resolution. Implement a pod disruption budget (PDB) to ensure that at least one pod of a deployment is always running during maintenance events. Create a YAML file for the PDB and apply it to a deployment. ee the Solution below. Solution: 1. Create a PDB YAML file pdb.yaml: apiVersion: policy/v1
3. Validate by logging in through the external provider: oc login --token=<external -idp-token> Explanation: Integrating external identity providers centralizes authentication management and supports single sign- on (SSO) capabilities. Audit and review the cluster’s role bindings to identify unnecessary permissions. Remove any unnecessary bindings. ee the Solution below. Solution: 1. List all role bindings in a namespace: oc get rolebindings -n dev -namespace 2. Review a specific binding: oc describe rolebinding <binding -name> -n dev -namespace 3. Remove an unnecessary role binding: oc delete rolebinding <binding -name> -n dev -namespace Explanation: Regular auditing of role bindings ensures that only necessary permissions are granted, reducing security risks and maintaining compliance. Create a project -specific custom role to allow users to only view and list resources. Validate their restricted access. ee the Solution below. Solution: 1. Create a custom view -only role: oc create role view -only --verb=get,list --resource=* -n dev -namespace
2. Bind the role to a user: oc create rolebinding view -only-binding --role=view -only --user=user1 -n dev -namespace 3. Validate restricted access: oc auth can-i create pods -n dev-namespace --as=user1 oc auth can -i list pods -n dev -namespace --as=user1 Explanation: Custom view-only roles limit user access to read-only operations, ensuring they can monitor resources without modifying them. Configure a group with read-only access to all resources in a specific namespace. Validate their access by attempting read and write operations. ee the Solution below. Solution: 1. Create a group: oc adm groups new read -only-group 2. Bind the view role to the group in the namespace: oc adm policy add -role-to-group view read -only-group -n dev -namespace 3. Validate read access: oc auth can -i get pods -n dev -namespace --as=user1 4. Validate write restrictions: oc auth can -i create pods -n dev -namespace --as=user1 Explanation: The view role allows read-only operations, ensuring users can monitor resources without modifying or deleting them. Configure an admin user with permissions to manage roles and bindings for a specific namespace.
Solution: 1. Create a Headless Service YAML file: apiVersion: v1 kind: Service metadata: name: headless -service spec: clusterIP: None selector: app: my-stateful -app ports: - protocol: TCP port: 80 2. Apply the Service and verify DNS resolution: kubectl apply -f headless -service.yaml kubectl exec <pod -name> -- nslookup headless -service Explanation: Headless Services provide direct access to individual pod IPs, which is essential for StatefulSet workloads. Deploy an application using a Kubernetes CronJob that runs every 5 minutes. Validate its execution. ee the Solution below. Solution: 1. Create a CronJob YAML file cronjob.yaml: apiVersion: batch/v1 kind: CronJob metadata: name: my-cronjob spec: schedule: "*/5 * * * *" jobTemplate: spec: template: spec: containers: - name: my -container
